hi all,

Just want some advice really.....

I have in the past controlled quite a few control loops over networks, MB+, eth i/p, MBTCP but have a slightly more critical application where this control is needed. I have a beckhoff PLC peer to peer with a modicon quantum (984 ladder) and have a process variable being read in the beckhoff and being transferred to the quantum over MBTCP. The quantum has the PID loop.

The process is a sugar slurry feed into a separator through the control valve (the MV) and torque (being read from the separator shaft) the PV.

There is no issue that this will work OK but really wanting some feedback on control loops over comms. All comments welcome.

 

> There is no issue that this will work OK

Well actually, yes, there is

> but really wanting some feedback on control loops over comms.

Generally speaking - a bad idea. For 2 reasons.

Unlike an IO bus like profibus or direct IO to your PLC, Your comms Between the 2PLCs are asynchronous. That means your IO is not updated on the same PLC scan as the PID scan. And if your communications scan rate is slow, then you are adding a significant deadtime to your control loop.

Your signals status is not being transferred. What happens if your input signal fails? Will your PID keep winding up or down waiting for a change in MV that will never come because your signal failed or your comms broke?

Yes, having the MV in a different controller to the PID loop does indeed SEEM to work OK, And maybe for this loop near enough is good enough. But in reality there can be significant problems with variable dead times and abnormal state handling. You're almost certainly NOT getting the best performance out of your control loop and you did say that this was a critical loop.

Having IO signals for the same control loop spread across different controllers is generally a very bad idea and should be avoided if at all possible. Problems like this can be very difficult to deal with when it comes time to optimise the plant for best performance.

Rob
www(.)lymac.co.nz

 

While essentially agreeing with Rob's point, the reality is we don't know enough about the application. If your loop needs to update every seven minutes, fine. If it needs to update every 7 milliseconds, or worse every 50 micro-seconds, you've got a problem. I recently did a motion control application with an external encoder that was not synchronized to the PID loop. I also couldn't get the encoder value any faster than a non-guaranteed 2ms update rate. It worked pretty well. I'd have certainly preferred to have the encoder synched to everything else, and the loop isn't perfect, but the system is working just fine.

This is one of those cases where I think empirical evidence is going to be the only way to figure out the answer.

-James Ingraham
Sage Automation, Inc.

 

Hi

You should take care to take into account what happens if the link is down. But this is not specific to ethernet.

This may be a fine solution depending on the time constants of your pid loop.