Second-Order Control

[dash]

<<Does the counter card compute velocity or does the PLC compute the velocity based on a time difference and two positions?>>

The counter card computes the frequency which is then converted to linear velocity based on roll diameter. So to me the answer is that the frequency card computes velocity.

Unfortunatly the high speed counter card is only able to use a single channel when it is in rate mode (so 1000PPR is max). Also the roll is actually 40inches (our test stand uses a 20inch roll). The high speed counter card is dealing with less than 3 counts for a 1MPH error (it's calculation window is set to 20ms). After discussing with the customer the previous system was much less aggressive than what we have. So our next course of action is to increase the time window of the high speed counter card (HSE) to around 100ms and also extend the update rate of the PID to 150ms.

Most of the test stands we are involved in are for durability testing which requires very aggessive tuning of the loops. This system is more for measuring steady state temperatures, flows, etc so the stability and velocity tracking are more important.

The MO2AE motion card is not really an option with this setup, which uses a MO8SE SERCOS motion card.

Thanks for talking with me on this,

Darren

 

[rdrast]

Does the counter card compute velocity or does the PLC compute the velocity based on a time difference and two positions? If the time difference is not known accurately then the compute velocity will not be calculated accurately.

Using a PLC to read high speed counters and the compute the speed is also a shakey practice. I know it is done all the time but that doesn't make it right. The question I have is what guarantees the sample times don't vary. A variation of just a few microseconds can have a large effect on the computed velocity.

Consider a 1756-M02AE. It has feed forwards that would help.

Peter, the 1756 HSC's can generate very accurate rates, on all channels with a bit of care. I generally put my rate calculators in a 100msec periodic task, and every task take both the count (HSC:I.PresentValue) AND the module timestamp (HSC:I.CSTTimeStamp).

Doing a subtraction from the last scan gets the delta count, as well as the delta time in microseconds of the actual counter module sample.

Using those to determine pulses/second has proven over and over to be many more times accurate than just using the sample delta and the task time.

 

[dash]

That may be an easy way to increase our resolution and use the encoder 4X mode, along with extending out our update rates.

Thanks,

Darren