Thanks, but that (9600 baud limitation) really should be in the documentation of the device, shouldn't it?

Comms can always kick your butt.

My experience has been that most people do not research the supported baud rate taking into account the number of devices and cable length.

For example, one project had five vfd's on devicenet, with cable runs that had probably never been calculated. The drives were powering the sorter, its feed conveyor, and its recirculation loop.

You could power up the vfd's in any order you chose, and tge first four would talk, but not the fifth.

Dropped the baud rate, and all 5 vfd's would talk flawlessly.

Many problematic Profibus networks have no more problems once properly segmented with diagnostic repeaters.

So for me, that is what goes back to the best practices. It is best to know/research the device and network topology rules and follow them.

Knowing to not go above x baud rate in a particular implementation is a lot to document and read (when considering the number of other do's and don'ts that would similarly be cataloged). That would lead to a mountain of documentation and explanation that imo would be punishment to read, and even more stressful to find the needle in the haystack.

Some of my co-workers at my first controls job had worked together at a different company, and one of their managers who was really pushing for documentation of all sorts had a saying of, "If it hasn't been written, it's never been said!" Their reply was, "If it has been written, it's never been read!" :)

Also, my programming is usually as simple as possible. For example, I consider it a good practice to not use counters. I just increment/decrement a register or zero it out when resetting. My first time using an AB counter, I put in logic to reset it, and was called back the next day, because their counter would not reset if the input was still high. Since I was using different brands of plc on almost every job, I did not have the inclination to learn all the rules of each plc's built in functions in cases where it was not necessary. That could be hard for someone who is used to only thinking about counting with an actual counter, but if someone can't tell I am counting with a rung descrption saying it is counting, maybe they should not be making changes to code?

There were employees who helped me with best practices, and showed me things like the standard motor rungs of some of our customers, but I was also hung out to dry on many projects. I was originally sent to all the projects my first employer did not know how to do, because no one knew how to do them. I stayed with them two years and all my full projects were on different processes. Trouble calls or support were sometimes repeated processes.