PID Sample Rate vs CPU Scan Time

[stgislander]

What is the relationship between the CPU scan time, in this instance an H2-DM1E, and the PID sample rate?

Am I correct in guessing that the scan time must be faster than the sample rate?

Does the number if PID loops come into play?

[franji1]

PID calculation is done on a PLC logic scan (actually when the instruction itself is scanned).  So the PID sample rate will be approximately the PID instruction's sample rate (give or take one PLC scan).

So, yes, the PLC scan time must be faster than the PID sample time.

Analog control is typically slower (e.g. temperatures don't move that fast, valves don't move that quick) than most PLC scans.  If you are trying to do fast closed loop motion control in your 205, I would recommend looking at the Do-more BRX PLC, it has some built-in "registration" type capabilities (AXGEAR, AXFOLLOW, AXCAM, et. al.)

[franji1]

Does the number if PID loops come into play?

Yes, but only from the standpoint of bumping the PLC scan time.  But remember that those PID calculations are only done once every "sample" time, so unless every PID loop is synchronized to go from Manual->Auto on the identical PLC scan, with the same sample time, even if you had 100 PID loops with sample times ranging from 50ms to 200ms, the PID calculation won't hit the overall scan that bad (although any configured analog scaling in the PID instruction is done every PLC scan, but you'd be doing that anyway).

PLC scan time is a completely different issue.  If that ends up being your bottleneck, there are things you can do to help that (e.g. string operations are SLOW, a bunch of bit moves are slow - instead move a bunch of bits on BYTE/WORD/DWORD boundaries if you can, e.g. moving X's to MI memory by doing casts, MEMCOPY X32:SD MI:64:SD copies 32 bits as a single DWORD in one clock cycle vs 32 individual bit copies that are S-L-O-W)

[stgislander]

Thanks for the info.

I'm only running four PID loops for active motion control.  One of the hydraulic cylinders is "chattering" at a certain portion of its stroke.

Assuming it is not injected electrical noise, the things that come into mind as the cause are 1) the PID sample rate, 2) the 12-bit ADC and DAC, or 3) the LERP function that takes the PV of a different PID loop to calculate the SP of this PID loop.  I've always been a little suspect of the LERP function because the cylinder is "quiet" when the SP of the loop is the output of a RampSoak function.

[franji1]

Thanks for the info.

I'm only running four PID loops for active motion control.  One of the hydraulic cylinders is "chattering" at a certain portion of its stroke.

Assuming it is not injected electrical noise, the things that come into mind as the cause are 1) the PID sample rate, 2) the 12-bit ADC and DAC, or 3) the LERP function that takes the PV of a different PID loop to calculate the SP of this PID loop.  I've always been a little suspect of the LERP function because the cylinder is "quiet" when the SP of the loop is the output of a RampSoak function.

Resolution is a big thing, so when the SP is stable and the PV is bouncing above and below, it could be your tuning parameters, but it could also be the resolution of your analog where the response/signal are too bouncy (noise wise).

[stgislander]

Yeah.  One thing I miss with this setup is I have no analog low pass filtering on each PV input.  That and 16-bit ADCs and DACs