New features wanted!! Apply here!

[BobO]

  * 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.

Do-more is far more complex than DL, and creating stages as global block memory was going to create a level of complexity that was unmanageable. Making stages struct fields solved many problems, but introduced a few others. We do have plans for a Stage Manager whose sole purpose is renumbering and reordering stages. I think this issue will go away when we add that.

  * 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.

That's a known issue and should be fixed in 2.1.

  * I can't enable or disable a stage while in Data View.

We can look at adding a stage set/reset option to the Data View. It's not a memory operation per se (which is why it isn't there), but I guess from a user's perspective that's really academic.

It is possible to do it now from the Project Browser. Right click on the stage, select Debug Code-Block, and then Enable/Disable Stage. I'm thinking we have a case to add it to the right-click menu on the stage itself.

  *  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.

That's there. Struct fields are iterated with Ctrl-Shift-Enter.

[franji1]

  *  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.

Use Ctrl+Shift+Enter to advance to the next field, which in this case is the next Stage bit

[DanC]

Would it be possible to  directly communicate to an SQL server?
TDS protocol is what would be needed, then add some instructions for setup to do the login and data transactions.
This would eliminate the need for a network attached server and associated software to bridge the PLC/PC gap.
With the awesome abilities of the Do-more, this would open some new doors.

[BobO]

Would it be possible to  directly communicate to an SQL server?
TDS protocol is what would be needed, then add some instructions for setup to do the login and data transactions.
This would eliminate the need for a network attached server and associated software to bridge the PLC/PC gap.
With the awesome abilities of the Do-more, this would open some new doors.

Users have already rolled their own through HTTP, although we might consider building it in once we get further down the BRX road. We're pretty covered up with BRX development for a while, but we definitely want to add protocols once we get some critical things complete.

[DanC]

According to Microsoft,the HTTP endpoints are not supported after version 2012 of SQL Server.
We are running 2014 company wide.

[deep6ixed]

Just got the BRX and Love it,  but I have a suggestion for a new string command

MStoHMS  Would convert the Microseconds on a on a timer structure to a sting as "Hours:Minutes:Seconds",  right now I just do a bunch of math and then convert it, would be nice to just have one command to do it.

[BobO]

Just got the BRX and Love it,  but I have a suggestion for a new string command

MStoHMS  Would convert the Microseconds on a on a timer structure to a sting as "Hours:Minutes:Seconds",  right now I just do a bunch of math and then convert it, would be nice to just have one command to do it.

It's kinda already there. FmtTmr() will convert a ms timer accumulator into a smart time value. It isn't exactly what you want, but it's close.

[franji1]

Just got the BRX and Love it,  but I have a suggestion for a new string command

MStoHMS  Would convert the Microseconds on a on a timer structure to a sting as "Hours:Minutes:Seconds",  right now I just do a bunch of math and then convert it, would be nice to just have one command to do it.

Already there.  Look at FmtTMR() function in the String Scripting Language Reference Help topic DmD0168

Usage: FmtTMR(value element, smart or full (optional, smart default), sec or tenths or hundredths or thousandths (optional, thousandths default))

[deep6ixed]

Now I feel Dumb, Ill have a look at it.

[BobO]

Now I feel Dumb, Ill have a look at it.

No need to feel dumb. I cannot tell you the number of times I have forgotten what's in Do-more...and I'm on the development team.

[skeller]

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

I see MQTT has been discussed fairly recently.  Has there been any additional developments?
I came here specifically to see if Host was working on MQTT for their PLCs.  I see that AutomationDirect/Host Engineerings knock-off competitor in Iowa has a PLC that supports MQTT, at least Publish only. 

I think MQTT has become somewhat of a "defacto" standard for non-real time data transfer between devices and information systems across the web.  Keep in mind that some applications are not even using the PLC for control but for monitoring.  In my experience, the "IoT" world has little to offer in the way of actual hardware for industrial interfacing (4-20ma, high voltage I/O, etc.).  Even finding platforms that support 24V I/O can be challenging.  Security is always an issue, especially for inbound data.  However, I think it limits the usefulness by having only Publish capability.  (Although Publish is better than nothing.)  I think Subscribe should be made available as well but with all the necessary warnings about security.  MQTT can be used over TLS and there is some provision for username/password to access a broker.  In the end, let the developer determine if inbound data is enabled or not.

My use case would be primarily monitoring of remote systems with very limited control.  Probably more filtering and scaling of inputs than any hard control.  The remote systems would be connected using cellular gateways with centralized cloud server to handle alarm SMS/Email messaging and hosting monitoring dashboards.


My only other wish would be a "C" style programing language instead of ladder logic.  I know its probably unlikely but one can dream, can't they? 



 

[BobO]

I see MQTT has been discussed fairly recently.  Has there been any additional developments?

It is a high priority. It isn't developed yet, but our goal is to support it for DmD 2.2. Most of our software releases at this point are driven by hardware schedules, but the major DmD 2.2 features that we want is TLS email support and MQTT. TLS email is basically complete, and we hope to start MQTT soon, but there is still considerable H/W work ongoing. Our goal is to support both publish and subscribe.

TLS is *heavy*. We are supporting it for email (at great pain) but are not planning to do so for MQTT in the controller. We are kicking around the idea of doing an enhanced ECOM module that would add some TLS features, including MQTT and an encrypted programming connection.

My only other wish would be a "C" style programing language instead of ladder logic.  I know its probably unlikely but one can dream, can't they? 

Yeah...probably not. We have kicked around the idea of adding something like LUA, but there are real concerns that support would be a nightmare.

[skeller]

TLS is *heavy*. We are supporting it for email (at great pain) but are not planning to do so for MQTT in the controller. We are kicking around the idea of doing an enhanced ECOM module that would add some TLS features, including MQTT and an encrypted programming connection.

Yes, I agree TLS is pretty "heavy".  We certainly don't want it affecting the real-time performance of the control loop.  I think standard MQTT will be a good start.  A broker on the network edge can handle the TLS/SSL to an external broker if absolutely necessary.

I like the idea of an enhanced ECOM.  Maybe a full Linux machine?  There are many SiP options available now that would allow it to fit even in the D05/06 chassis.  Check out http://tinyurl.com/y957dm3k, full 1Ghz TI Sitara Cortex-A8,512MB RAM, 2-200Mhz 32bit RISC processors in a 21mm x 21mm BGA package.  It would certainly handle all the TLS/SSL needs and much more.   (I would really like to see a Linux CPU but now I know I am really dreaming.         Which BTW I still have over 20 WINPLC's STILL running.  )

Thanks for all the great products!  I will keep my eye out for upcoming software releases. 
   

[BobO]

We certainly don't want it affecting the real-time performance of the control loop.

I won't go into the magic under the covers, but it does work with a minimum bump. The TLS handshake isn't going to be fast by any measurement, but I'm fine with that for sporadic emails from a PLC. Not so much for something like MQTT.

Not sure what the platform would be for an advanced ECOM, but I would certainly expect it to be running some form of OS or RTOS...TBD.

I love the idea of having two Ethernet ports...one external and one internal...to be able to do things like run a standard MQTT broker to the internal port, and then it do TLS-based client to the external port. I could see it becoming a great tool to bridge the factory to the outside world. Not a full VPN, but a tool to provide a few specific functions helpful to PLC customers.

[bobrenfrow]

I would like to see a "Keep Window on Top" feature implemented. Where you could keep the simulator and/or the Data window open on top of the Ladder window. I use this feature frequently with RSLogix. It's a great tool, especially while working online.