New features wanted!! Apply here!

[BobO]

This feels like trying to explain what kind of monster I am afraid might be under the bed.

I just tried again and still am not comfortable with it. It feels cryptic and the whole "close what I am doing and reload a previous state", especially when I am not sure what exactly that state is, feels like signing a pact with...

Usually a quick Ctrl-Z to fix the blunder I just made is my goto. Especially with troubleshooting/debugging something where I have probably bounced around trying things means I do not want to leap back in time, I want to take small backsteps through the edits. If I undo one too many, I at least know pretty much where it was (and redo is handy there.)

I am not very methodical in how I think - I always turned in my outlines after the essay was finished in school. It's pretty much too late to change now, nor do I particularly want to.

Fair enough.

Had DirectSoft been written in the last 10 years, I'm sure the underlying design would be a bit different, but the foundation was laid in 1992. While vast swaths of it have been re-written, in some cases more than once, the fundamental approaching to editing, storing, compiling, etc, hasn't changed that much over the years. It is very much a desire of ours to finally bite the bullet and recreate the editor with the mousing and edit journaling features everyone wants, but we simply haven't had the horses or time to do so. BRX was *huge* for us, both in how heavy a lift it was and hopefully in how it enables the next wave of growth that will allow us to take on some of these issues.

[plcnut]

Regarding the undo feature: Many times I am only wanting to undo something minor, but when I hit CTRL Z I get the popup with a list of different backups to revert to, but I don't know how much is actually going to be undone, and so I opt to manually undo it.

[HB_GUY]

What about adding some of the IoT protocols like MQTT or the like?

In time, sure. Pretty covered up now with the new platform, but once it's done we'll be looking at other things to do.

I just figured I throw this back out into the mix now that the new platform has been released. (It would be nice to have on the no-IO units for sure)

[BobO]

What about adding some of the IoT protocols like MQTT or the like?

In time, sure. Pretty covered up now with the new platform, but once it's done we'll be looking at other things to do.

I just figured I throw this back out into the mix now that the new platform has been released. (It would be nice to have on the no-IO units for sure)

Was just looking into this. Seems pretty easy. How common is this now?

[HB_GUY]

IBM claims "MQTT is the de-facto standard and ISO standard for messaging protocols"
Using the opensource mosquitto MQTT broker, and some javascript it is very easy to create nice web based dashboards.

Also, every IOT dashboard provider online expects you to send messages using MQTT in either plain text or JSON format.

[BobO]

IBM claims "MQTT is the de-facto standard and ISO standard for messaging protocols"
Using the opensource mosquitto MQTT broker, and some javascript it is very easy to create nice web based dashboards.

Also, every IOT dashboard provider online expects you to send messages using MQTT in either plain text or JSON format.

Cool. It's an awesome standard developed by some really smart people.

I'm sympathetic and we are very interested in pursuing this, but, I want to make sure that there is something specific to talk to if we add it. So my question remains: From a device support standpoint, with specific emphasis on how a PLC would use it, how common is it and how much stuff is deployed on or near the factory floor that supports MQTT?

Host has invested a tremendous amount of engineering resources pursuing stuff in markets that never materialized, and that's not a great way to build a business. We are starting to get requests for it, I just want to make sure we don't fall into the same trap again.

Another question: The client side is pretty obvious, but what form does the broker normally take and what would you see acting as a broker in a factory environment?

[jgreenewv]

Another question: The client side is pretty obvious, but what form does the broker normally take and what would you see acting as a broker in a factory environment?

Ignition has MQTT modules developed by Cirrus Link.  Not sure how much usage they're getting, but I've seen various ads pushing MQTT/IIOT functionality.  I've also seen articles/blog posts/etc. that sound like some of the other players are working on solutions in this sector. 

[BobO]

I see the obvious benefit of the PLC being able to send and receive data from systems upstream, and I think that by itself may be enough to justify development. When I hear the word 'sensor', however, my mind immediately goes to control, and I start seeing the PLC as a subscriber of lower level data. That may prove to be a valid use over time, but my guess is that MQTT would be more useful reaching up the chain, rather than side-to-side or down.

[HB_GUY]

Here are some of my thoughts.
There seems to be a push in the industrial arena talking about IIOT.

The ability for a remote PLC to push metrics to a IOT dashboard for anywhere access from any device with a web browser.
Many of these dashboards/brokers are Free/Low cost.

You can also setup a local broker for free! https://mosquitto.org/

Local dashboards for shop floor.

Any device that can display a web browser can be used as a billboard.

I really like MQTT support because it is open source. It makes is really easy to build solutions that do not cost an arm and a leg.

[BobO]

Reading more. Liking it. PLC side is simple. Also seeing a possible factory floor friendly broker appliance with dual Ethernet...one up and one down...to keep internal and external networks segregated. Lots of potential there for a product that brings this to the floor without requiring IT expertise, as well as providing MQTT access to things which don't have it.

[HB_GUY]

... Also seeing a possible factory floor friendly broker appliance with dual Ethernet...

There are a number of open source linux systems (OpenWRT, LEDE) that have been in the market for quite some time and have strong communities and a huge package management system.
I am currently running one of these with OpenWRT on a GL-inet router https://www.gl-inet.com/product/gl-ar300m/ as a MQTT broker, and will be starting on a perl modbus module to basically do that same thing.
Obviously you at Host could do a much better job at this, I only mention this as a quick and easy way to setup a proof of concept or prototype.

[BobO]

Obviously you at Host could do a much better job at this, I only mention this as a quick and easy way to setup a proof of concept or prototype.

I wouldn't say better, I would say more appropriate to the target venue and more specific to the need.

We were kicking around the idea of adding a PLC programming remote access portal too. Basically from DmD you would build the comm link to target the portal, and it would translate from a secure TCP-based connection to the unsecured UDP-based world of our products. I don't think it would be too hard to do and would be a very clean solution to a problem that people fight with constantly, but there are concerns of liability due to security exposure. I share the concern, but it bugs me to no end that I can't make life better for 99.99% of my customers because of the 0.01% chance of trouble...while I know that folks are taking far bigger risks because of the lack of good solutions.

[HB_GUY]

Obviously you at Host could do a much better job at this, I only mention this as a quick and easy way to setup a proof of concept or prototype.

I wouldn't say better, I would say more appropriate to the target venue and more specific to the need.

We were kicking around the idea of adding a PLC programming remote access portal too. Basically from DmD you would build the comm link to target the portal, and it would translate from a secure TCP-based connection to the unsecured UDP-based world of our products. I don't think it would be too hard to do and would be a very clean solution to a problem that people fight with constantly, but there are concerns of liability due to security exposure. I share the concern, but it bugs me to no end that I can't make life better for 99.99% of my customers because of the 0.01% chance of trouble...while I know that folks are taking far bigger risks because of the lack of good solutions.

This is really interesting, I currently use eWON devices to have remote reprogramming and remote control access to the machines.
In such a "portal", would there be the ability to pull logs from the DoMore? What about other devices like the cMore?

[henke]

Will the new PLC have support for DNP3 Master / Slave?

Sorry, no.  I'm not familiar with DNP3.  What types of applications would a PLC be useful as a DNP3 Master?  What types of applications would it be useful as a DNP3 Slave?

What is the physical layer for DNP3?  Is it RS-232? 422? 485? Ethernet?

I realize that this is a super old post Franji1 but I'm bumping it due to the recent realization that DNP3 is the go-to in the Water Treatment and Power Distribution industries. This is simply due to the fact that it can buffer in the case of flaky Ethernet (radio) links. Has there been any development happening in this area since '09?

[mark.troutner]

I would really like to see some enhancements to Stage. For instance:
  * I can't renumber blocks of stages in Documentation Editor using Ctrl R like I can with X,Y,C,V, etc elements. It's really painful to renumber stages one at a time.
  * While in the Documentation Editor, stages are not listed numerically, they'll be in an alphabetical order such as S0, S10, S100, S11, S30 then S4, etc.
  * I can't enable or disable a stage while in Data View.
  *  I can't copy stages in Data View using Ctrl Enter, so again you have to type in the name of every stage value that you want.