Advanced Control: Don't Use PLC Timers When..

[Peter Nachtwey]

sampling data.
I will probably use this in a magazine article.

 

[drbitboy]

In A-B-ville, timed Interrupts are better than timers, but they still run long, the same as timers. Using an internal clock, if available, is the only reliable method to get a mean period that is correct.

 

[5618]

Here's a technique to maintain an accurate period over time. (As accurate as the system clock) There's still scan time variation. This example is running in a continuous task with about 7mS intervals. Just be certain not to get a negative .ACC or processor lights you want green turn to red.

 

[VAN]

sampling data.
I will probably use this in a magazine article.

I might be missing the point, but most applications 99/101ms is negligible. As others have pointed out, using the continuous count with subtracting time and eventually subtracting magnitudes will run for years.

What application is this for?

You mentioned using encoders, I don't recall using an encoder for anything but position. So, why wouldn't you use the simulated master as the source for your measurements (assuming 99/101ms makes a huge difference)?

 

[cardosocea]

I might be missing the point, but most applications 99/101ms is negligible.

Not Peter, but his paper stated "If the timed interrupt is set for 100ms the interrupts may occur at intervals of 99ms or 101ms", not the timers.

I haven't had a chance to look into this on newer PLC's, but on PLC5 (for example), the TON would overshoot by 5ms easily. The TON is also very dependent on the cycle time of the entire PLC program where in the very worst case scenario the timer can be off by just about the entire cycle time of the program.

 

[I_Automation]

I us 5618's method, but usually test it for accuracy and end up changing the compare values to 98 or 99 for 1/10 seconds.

Going for a 1 seconds pulse is usually good enough and can be tweaked finer, say 987.

 

[drbitboy]

High accuracy, which as noted by VAN is rarely needed, requires building a custom timer.

I did some experiments with MicroLogix 1100, here; plots of the results are here. Each method has four images: the algorithm implementation (no suffix, just the name e.g. cascading_timers.png); cumulative frequency (suffix _cumfreq.png); frequency histogram, which would ideally have a Gaussian or normal character (suffix _freq.png); plot of time vs. samples (_plot.png; this is missing for some methods).

The target period was 2s, or 20k pulses of the Micro's free-running clock, which clock was used in the measurement. The exception was bit 14 of the free-running clock, the target for which was 1.6384s by nature of the method. The accuracy of the oscillator is typically outside the control of anyone and so outside the scope of these tests and this thread, and could be calibrated for in any case.


The parameter relevant to this thread is the mean, which is at the top of every plot. The Timed Interrupt is not bad, it runs long by less than a quarter of a ms, certainly better accuracy than almost any application would need:

But running a custom algorithm using an internal oscillator is better than that by more than two orders of magnitude:

 

[geniusintraining]

For the stuff I write.... sometime that hour is fine.

But I do like reading and learning from Peter

 

[rupej]

I might be missing the point, but most applications 99/101ms is negligible. As others have pointed out, using the continuous count with subtracting time and eventually subtracting magnitudes will run for years.

What application is this for?

We've had to use these methods when accumulating volume flow over a long period of time from an analog signal from a flow meter, as one example.

 

[Peter Nachtwey]

In A-B-ville, timed Interrupts are better than timers, but they still run long, the same as timers. Using an internal clock, if available, is the only reliable method to get a mean period that is correct.

Yes, sometimes they will run long if the interrupt occurs during house keeping time where the interrupts are turned off but the next interrupt is still generated by hardware so the next interval will be shorter.
The hardware will generated interrupts and even intervals so the there will be no accumulated error when it comes to time.


@5618, that will keep the intervals relatively constant. It is still best to use timed interrupts.




@VAN, I understand +/- 1 ms out of 100 isn't that but I don't care. I always try to use the best technique/algorithm. In my pdf I use 10ms updates where +/- 1ms is a killer when it comes to calculating speed or flow rates.


I wrote this because I already had a Mathcad example done and I saw another thread about measuring the frequency. I also needed a topic for an article. I am running out of ideas.


In practice we use a FPGA to read the data every 1 millisecond on the nana second. This reduces sample jitter to near zero. I always encourage my customers to use the highest resolution feedback possible because this aids in computing the estimated position, velocity and acceleration. Calculating the estimated acceleration is critical in motion control. The argument that few applications require this precision doesn't matter when you are making a product that must work for any application.

 

[drbitboy]

The hardware will generated interrupts and even intervals so the there will be no accumulated error when it comes to time.

Based on hard evidence I can't agree; I am sure that is what is supposed to happen, but in reality it does not, as the github repo documents my physical experiments. It is definitely not the case in the MicroLogix 1xxx line (or at least with my 1100, serial number ...')), but that does not say anything about other PLCs. In any case it would be difficult to measure to that level of precision in higher-end A-B hardware, as I don't see easy access to a 10kHz free-running counter or equivalent (I think either SLC or PLC-5 may have it).

 

[Peter Nachtwey]

Based on hard evidence I can't agree; I am sure that is what is supposed to happen, but in reality it does not, as the github repo documents my physical experiments. It is definitely not the case in the MicroLogix 1xxx line (or at least with my 1100, serial number ...')), but that does not say anything about other PLCs. In any case it would be difficult to measure to that level of precision in higher-end A-B hardware, as I don't see easy access to a 10kHz free-running counter or equivalent (I think either SLC or PLC-5 may have it).

Where is your hard evidence?
What micro controller are you talking about that can't generate interrupts are consistent intervals.
SHOW US!





Most micro controllers have a couple of timer/counters. The 80186 had 3. The had a register that would increment at some fraction of the CPU clock rate. This was usually programmable. There was also another register that could be loaded with a value that would cause the timer/counter to generate an interrupt and reset the incrementing counter. This would happen without software intervention once it was started so interrupt would be generated and a regular rate. I have examples for the 80186 that we used on our old RMC100. It needed to generate interrupts 1024 times a second or every 976 micro seconds. There could be no variation or the motion would not be smooth.

 

[drbitboy]

Where is your hard evidence?
What micro controller are you talking about that can't generate interrupts are consistent intervals.
SHOW US!

ALREADY DID IT THIS MORNING!



see post #7 in this thread.

 

[mk42]

Where is your hard evidence?
What micro controller are you talking about that can't generate interrupts are consistent intervals.
SHOW US!

He said quite clearly that it was a micrologix 1100, and the data is linked further up the thread. However, I don't think it addresses the timed interrupt method under discussion.



https://www.plctalk.net/qanda/showthread.php?p=859756#poststop

 

[drbitboy]

... However, I don't think it addresses the timed interrupt method under discussion.

Quite possible:

• maybe the free-running clock is non-linear in time;
• maybe STI (Selectable Timed Interrupt) in MicroLogix 1xxx is not the same kind of timed interrupt being discussed here;

Here is the code.