Please tell us what your experience has been with Do-more...

[Dean]

I might hide a little easter egg in my latest projects comments, see how carefully it actually gets checked. My boss will probably find it, If it catches his funny bone, he might just sign off and pass it along. He likes the old turboencabulator joke.

[franji1]

It's human nature.  The closer physical proximity is to something, the higher probability that the association and relationship will be understood.  If detailed design documentation is locked away in some office somewhere away from the PLC, MAYBE somebody will utilize it.

It'll be amazing, say in 2035, when you will be able to connect to a 20 year old Do-more PLC, where the PC where the original project existed along with any print-outs are sitting in some trash heap for 15 years.  Regardless of the location of the DISK project, the Element Documentation and Rung Comments will be uploaded along with the control logic.  And then even better, when the documentation explains why the program controls the system on a rung-by-rung basis, and not just re-iterating what the instructions do.

I started a new topic entitled Good PLC Program Documentation for us to comment about this.

[Controls Guy]

At one point in my career I was put in charge of some junior programmers.  They thought 5 lines of commenting was sufficient for a few hundred lines of code.  That was when I started doing what Dean's boss does.  "Give me the program when you think you are done with it", you'll get it back if I can't tell what the program does by reading the comments.   Program quality improved significantly after that.

Right, and that feels like about the appropriate level or a reasonable goal for how many and how verbose to make comments: so that another controls engineer can read it.  Or, even not a controls engineer.  I'm sure the mechanical engineer for the equipment, or the EE, if separate from the controls guy, or even a controls tech, should be able to figure it out from comments.

So I'm not arguing against documenting per se (although I try to get the code to do a lot of it for me via good synonyms, named constants, and point descriptions), but rather questioning whether IN the PLC program is the optimal location for storing a description intended for non-technical people.

[deep6ixed]

When it comes to troubleshooting and documentation, I've stuck with the KISS principle.  I keep the code as simple as I can.  With the options of Tasks and Programs, this makes it so easy.

Program documentation is a great idea and I always comment and explain my code in the ladder logic.

For the non technical people in our shop and the maintenance personnel, we started installing HMI's anywhere we use a PLC.  The small cost investment pays back dividends when it comes to downtime.  All of our screens will show inputs / outputs (labeled to what they are) in addition to the readouts that the machine uses.  All of our larger 8" displays have a big HELP button for operators and maintenance, it gives a flow chart to show what is missing from the sequence to run the machine.
 

[Controls Guy]

Yeah, HMI's a BIG help in downtime troubleshooting.  I do the same thing you do with the I/O.  Another cool thing with some of the newer HMI's is that you can store good quality video, so you can shoot and put in multimedia lessons on how to operate the HMI and how to run the machine, in addition to hosting text and graphic help files there.

[plcnut]

Feature request:
Could you make it so that the mouse scroll wheel will scroll the ladder tabs left and right when I'm hovered over them (Just like Firefox browser)?

Also, The Paste function and the Accept function take laboriously long in a large program (45571/65536). Could you look into any optimizations to make this quicker?

Thank you!

[BobO]

Feature request:
Could you make it so that the mouse scroll wheel will scroll the ladder tabs left and right when I'm hovered over them (Just like Firefox browser)?

Also, The Paste function and the Accept function take laboriously long in a large program (45571/65536). Could you look into any optimizations to make this quicker?

Thank you!

Define "laboriously long"...

[plcnut]

Define "laboriously long"...

For a paste: 2.5 seconds+ for a single rung. For F8 It is 1-1.5 seconds+ per rung. It doesn't sound like much when I'm sitting here typing this, but when I'm making major edits for an upgrade project, it eats a lot of time...

[BobO]

There is zero doubt in my mind that some of this could be optimized. Right now we are eyeballs deep in coding new poorly optimized features , but maybe we can take a look at that before we launch the next version. A new case Mark?

[franji1]

Already in there, but there isn't much room for "optimization".  It's usually a diminishing returns - a ton of work and added complexity to get it from 1.5 seconds down to 1.2 seconds (for example).

I looked at this once before and it's one of those issues where big programs with lots of stuff require lots of processing.  I will definitely look at it.

[plcnut]

Thanks guys. I wasn't trying to push things, but wasn't even sure if you were aware of the issues that are only evident in larger projects.
Do-more rocks!

[BobO]

Thanks guys. I wasn't trying to push things, but wasn't even sure if you were aware of the issues that are only evident in larger projects.
Do-more rocks!

Not trying to push things?!? Isn't that sorta, kinda, totally your MO?

[plcnut]

I certainly push the hardware and software, I just don't mean to push you!

[franji1]

For F8 It is 1-1.5 seconds+ per rung.

Just found some debug code that is in production.  Once we eliminate that, this should help F8-Accept.

[plcnut]

Just found some debug code that is in production.  Once we eliminate that, this should help F8-Accept.

Cool beans!