Do-More Network with Multiple PLCs

[etElMadr]

I'm considering expanding my existing install by adding an additional remote rack. Not sure whether to use a second PLC or remote expansion module. Scan time is a growing concern, but also also knowing the state of all inputs in the system is critical. What are my options? Is it possible for PLC A to read the state of the inputs on the IO for PLC B? Am I going to need to set-up a communications routine to send Inputs state from PLC B to PLC A?

[franji1]

What is your current scan time?  What are you trying to keep it under?  What precisely is the scan time concern?  Maybe an HSIO could help solve?

You can sometimes optimize your logic to reduce scan time.  Also, there's certain logic operations like copying large number of bits or numerics, or string manipulation that you can optimize.  Usually the "slow" code is isolated - maybe it does not need to be executed every PLC scan, for example (do some work this scan, other work that scan).

If scan time is critical, a 2nd PLC can maintain the original PLC's scan time.  Does the remote I/O control need to be dependent upon the logic in the current PLC, or does the remote I/O control only need its input states (no Cs, no Ds, no Timers).

If it truly is a different control cell altogether and you truly only need the X input states, you could get a 2nd PLC and then write the X input states from the original PLC using a  WX instruction to the remote PLC.  But if the logic between the two is dependent on each other, other than just the X states, you will need to stick with a single PLC with a remote base (BX-DMIO or H2-EBC100 or T1H-EBC100, whatever is your current I/O platform).

If you do go with a 2nd PLC, the latency on the X input state of the original PLC will be slightly slower in the remote PLC (a scan or 2 behind), and even miss some "edges" if the X input states are changing very fast relative to PLC scan time (HSIO may be helpful for processing very fast discrete inputs BTW).

[etElMadr]

Thank you. WX might solve my issue. I don't think input latency will be an issue. In fact, I can probably process inputs on PLC A then just push the result to PLC B.

I can't tell you off the top of my head what my scan times are. Without .TimeSlice, my scan times were exceeding 20ms (see https://forum.hosteng.com/index.php?topic=3540.msg27221#msg27221). No doubt I can optimize my code some, and I haven't updated to 2.9 yet either. The issue I'm dealing with is several very large data sets that need to be scanned frequently. The larger the data sets grow, the less responsive the system becomes. Thankfully, there are no High-Speed Inputs.

By splitting the system into 2 PLCs, I should also be able to move one or two of the data sets which should help even further.   

[franji1]

By splitting the system into 2 PLCs, I should also be able to move one or two of the data sets which should help even further.

That's good.

.TimeSlice is definitely your friend when it comes to iterating large data sets via FOR/NEXT.  I've typically found sweet spots between 300uSec and 1000uSec.  Anything more typically doesn't help much "calendar time" but definitely takes a hit on PLC scan.  Anything less, the little bit of PLC scan time reduction is not worth the elongated calendar time (e.g. 300uSec down to 150uSec causes algorithm to take TWICE AS LONG calendar-time-wise, but only helps the PLC scan by 0.15 miiliseconds, not helpful when you have a 20ms PLC scan).

[ATU]

If you are not already implementing stage programming, it can be quite impactful in optimizing your logic and reducing scan time. Particularly in communications and calculations.