DMLoader Feature Requests

[FAHOutdoors]

Trying to test the viability of using the DMLoader to update PLCs remotely over a VPN and a remote access router and came across some problems.

It doesn't appear that you can make, manage and save ethernet connections like you can in Do More Designer. This would be handy as I write to the same IP addresses at different physical locations most of the time.  Ideally it would just share the connections I'd already made and configured in Do More.

It doesn't seem to handle a bad connection well at all or retry. I am connected to a test setup remotely over my wifi to a remote access router sitting at my desk writing a relatively small program with the DMLoader. Even in this absolute best case scenario, it would only write 2/6 times successfully, and fail the rest with "comm error -201:32774 writing program to PLC" or when writing documentation. Also the connect page required me to hit "Test Link to continue..." several times before it ever would connect. Implementing the above suggestion with allowing us to make manage and save connections or sharing the connections  with Do More Designer would seemingly fix this problem too. I have some projects that are so large and locations with bad enough connections that I have to max out my retries and timeout timers in the connections to ensure I successfully write a program in do more designer.

And on the subject of the DMLoader, in the export page where I'm given options before generating a DMLoader image I'd like to be able to remove documentation and rung annotation before generating the DLI to protect certain information and reduce size of the file for fastest download possible remotely.

[BobO]

Trying to test the viability of using the DMLoader to update PLCs remotely over a VPN and a remote access router and came across some problems.

It doesn't appear that you can make, manage and save ethernet connections like you can in Do More Designer. This would be handy as I write to the same IP addresses at different physical locations most of the time.  Ideally it would just share the connections I'd already made and configured in Do More.

It doesn't seem to handle a bad connection well at all or retry. I am connected to a test setup remotely over my wifi to a remote access router sitting at my desk writing a relatively small program with the DMLoader. Even in this absolute best case scenario, it would only write 2/6 times successfully, and fail the rest with "comm error -201:32774 writing program to PLC" or when writing documentation. Also the connect page required me to hit "Test Link to continue..." several times before it ever would connect. Implementing the above suggestion with allowing us to make manage and save connections or sharing the connections  with Do More Designer would seemingly fix this problem too. I have some projects that are so large and locations with bad enough connections that I have to max out my retries and timeout timers in the connections to ensure I successfully write a program in do more designer.

And on the subject of the DMLoader, in the export page where I'm given options before generating a DMLoader image I'd like to be able to remove documentation and rung annotation before generating the DLI to protect certain information and reduce size of the file for fastest download possible remotely.

DMLoader really wasn't intended to work along side DmD, but rather as a standalone utility for when DmD isn't appropriate, like on a manufacturing floor or a customer site. Not really sure how we would approach that since sharing data was never the intent.

I'm not sure why it would be less reliable than DmD, the underlying comm code is the same, but timeouts and retries may be different and that's probably the difference. We could look at making that settable.

There are things stored with documentation that are required for properly reloading the program. We have discussed making it possible to do a "download only/cannot be read up" version of the program, but to this point we haven't done so.

[FAHOutdoors]

That all makes sense, I only suggested sharing the connections as I thought that might be easy. If not just a way to save and manage connections would be handy.

Writing the program remotely in DMD has nearly 100% success rate, I need to increase retries and timeout times only for the largest projects or the worst connections. In DML it was closer to 20% for some reason, despite DML taking less time to write than DMD. I can test anything out you want me to.

Specifically I just want to remove rung comments, I misspoke when I called it rung annotation. Anything to reduce file size would be nice though for some of the bigger projects, there is the option to remove either rung comments, rung/address anotation, and/or element documentation when exporting a .txt file but none for a .DMI.

[BobO]

That all makes sense, I only suggested sharing the connections as I thought that might be easy. If not just a way to save and manage connections would be handy.

Writing the program remotely in DMD has nearly 100% success rate, I need to increase retries and timeout times only for the largest projects or the worst connections. In DML it was closer to 20% for some reason, despite DML taking less time to write than DMD. I can test anything out you want me to.

Specifically I just want to remove rung comments, I misspoke when I called it rung annotation. Anything to reduce file size would be nice though for some of the bigger projects, there is the option to remove either rung comments, rung/address anotation, and/or element documentation when exporting a .txt file but none for a .DMI.

Looks like the default DMLoader timeout is 100ms and the retries are 3. I believe DmD defaults are 250ms and 3. I'll raise it and build a custom DMLoader. You can try it and see if that improves it to match DmD.

[JeffS]

So will the slightly longer timeout become standard? Or will the timeouts be editable?

One additional issue I run into is that if you use the DM loader to load firmware using an ethernet connection, nearly 100% of the time the ethernet IP is reset to 255.255.255.255 and you have to use netedit to fix the IP quickly before the DM loader times out waiting for the OS to start.  I say nearly, because occasionally it doesn't reset and completes without any intervention with netedit.  Is the resetting ethernet settings on firmware update an intended result?

[JeffS]

Have you had a chance to look at this yet?

Thanks

[BobO]

So will the slightly longer timeout become standard? Or will the timeouts be editable?

Longer is standard. Timeouts need to be long enough for typical network conditions. Shorter is generally just about keeping things responsive during bad network conditions. For a utility like this where we less concerned about tuning for a flaky network, we tend toward "make it long enough and keep it simple".

One additional issue I run into is that if you use the DM loader to load firmware using an ethernet connection, nearly 100% of the time the ethernet IP is reset to 255.255.255.255 and you have to use netedit to fix the IP quickly before the DM loader times out waiting for the OS to start.  I say nearly, because occasionally it doesn't reset and completes without any intervention with netedit.  Is the resetting ethernet settings on firmware update an intended result?

I haven't observed this and not sure how it could happen randomly. I can think of one thing that might make it look that way.

On the Clear PLC Memory page we used to select "All" by default and we had a rash of folks certain we were losing our IP settings. What was happening was they were clearing the PLC, not realizing that the IP address in RAM would keep the PLC talking until the next power cycle, after which it looked like we lost the IP. The solution was enable everything except the System Settings by default. All complaints about lost IP addresses stopped. If you have done a Clear PLC from DmD with All selected it would keep talking until the firmware reboot forced a reload from the cleared flash.

Another possibility would be a SETIP instruction that's changing it from the program, but don't think that would match your symptom.

If you can give me more to work with I can try again to dupe it.

[BobO]

And let me elaborate a bit. Timeouts are about handling the expected response time and delays due to network topology and load. They should be set to the longest reasonable time that accounts for latency, topology, and load, but longer (in the interest of being more stable) just tends to reduce responsiveness in spotty conditions. So, longer timeouts are to deal with slower networks, without regard for packet loss, while shorter allows us to be more responsive to packet loss, without regard to network speed. The best single answer is long enough to cover worst case latency, and no longer, with enough retries to deal with expected packet loss. At 250ms, you are way beyond normal latencies in most modern networks, and 3 retries is plenty to handle reasonable packet loss. If 250ms/3 isn't a good setting, I would argue that you are flirting with disaster trying to update the PLC with this tool. I have zero doubt that some radio environments could challenge those settings...but...should you really be trying to update the firmware of your controller with a network that laggy or flaky? And are we really doing you a favor encouraging you to increase timeout and retries until it "works"?

I know...the needs of the field are different than our ivory development towers...but...sometimes "no" is a better answer than encouraging people to do things you know are likely to be problematic.

/end BobO's Guide to Timeouts and Retries

 

[JeffS]

Thanks for your responses Bob!

Regarding timeouts, I was considering this utility for doing software updates over a remote cellular connection.  It is not uncommon to have 250+ ms pings on these connections, specially if they are rural and located on the opposite side of the planet. If it isn't too much trouble, would making the timeout user adjustable be feasible?  This way it uses the standard timeout unless the user changes it.   

You were correct about the IP address resetting.  In my testing I was wiping the PLC, but not power cycling it before preforming the update.  This then does the reboot and loses the IP address as you mention.  If I wipe, power cycle, set the IP the subsequent update completes successfully.  I can also just not erase the IP settings when clearing the PLC and that works as well. Thanks for the insight.

[rlp122]

Ugh cellular.  One thing to be especially aware of with cellular modems is that they will bundle packets and burst them all at once.  A lot of devices have trouble with this approach as you can get buffer over-runs which obviously results in lost packets and retries.  Offhand I don't know that any cell modem that lets you turn off this "feature".

Just throwing this out there as a bit of additional info in case you keep having issues.

[BobO]

Ugh cellular.  One thing to be especially aware of with cellular modems is that they will bundle packets and burst them all at once.  A lot of devices have trouble with this approach as you can get buffer over-runs which obviously results in lost packets and retries.  Offhand I don't know that any cell modem that lets you turn off this "feature".

Just throwing this out there as a bit of additional info in case you keep having issues.

Since our protocol sends a single request and waits for the response or times out before sending the next, it shouldn't be a problem...but...caveat emptor.

[BobO]

Thanks for your responses Bob!

Regarding timeouts, I was considering this utility for doing software updates over a remote cellular connection.  It is not uncommon to have 250+ ms pings on these connections, specially if they are rural and located on the opposite side of the planet. If it isn't too much trouble, would making the timeout user adjustable be feasible?  This way it uses the standard timeout unless the user changes it.   

You were correct about the IP address resetting.  In my testing I was wiping the PLC, but not power cycling it before preforming the update.  This then does the reboot and loses the IP address as you mention.  If I wipe, power cycle, set the IP the subsequent update completes successfully.  I can also just not erase the IP settings when clearing the PLC and that works as well. Thanks for the insight.

For reasons I won't bore you with, it is very painful to make it settable via UI, but I can pretty easily do a workaround via INI file. I'll email you something shortly.