MicroLogix 1400 timing issue

[Christoph]

All
Using a MicroLogix 1400. Not a huge program doing an auto stop function
based on a calculated roll diameter Using encoder feedback for unwind rpm
and machine speed in FPM. There is a small Panelview for operator inputs.
They can enter the accel decel speeds for ramps in FPM/S. I calculate a increment value and do a subtract of that value from the current setpoint.
every 10 milliseconds from the done bit of a free running timer. it has a time base of .001 and a preset of 10. My done bit is only triggering the sub block about half of what it should in a 10 second period during testing.
processor scan time highest was 6.3 ms.
Is the MicroLogix not capable of this?

Best Regards

 

[drbitboy]

I guess it depends how much other activity the MicroLogix 1400 is doing. I rarely see a scan time longer that 1-2ms with my 1100, but then I am just playing around with simple programs.

P.S.

That sounds like a TON or TOF timer, not a free-running timer; did you mean self-triggering repeating timer? If it is a timer, then you may be losing one scan to do the repeat; how do you have it coded?

10ms is 100 ticks of the 10kHz free-running clock, in INT S:4. 128 ticks (12.8ms) could be triggered the rising edge of bit 6 of S:4; that might be a better choice for this; even if the scan times are long and there is a little chaos, it will likely never miss any of the steps.

I did some testing on my 1100 of repeating timers, cf. here; it may give you some ideas.

 

[Christoph]

It is a TON with the done bit resetting it. I will try what you suggested tomorrow.

 

[Ken Moore]

You could also keep your timer, but make the time longer, say 50 ms, then when accum >20 do logic, subtract 10 from accum. You don't lose a scan for the reset.

I don't remember if you can do a timed interrupt on the ML1400 if you are using high speed counter. A timed interrupt would be best.

 

[Aardwizz]

It is a TON with the done bit resetting it.

Like drbitboy said, there will be a scan when ACC > PRE, setting the DN bit. if the accumulated scan times was a little longer than the preset (e.g., if each scan time was 6.3 msec exactly, after 15 scans, the ACC is 94.5 msec; on the 16th scan, the ACC hits 100.8 msec), you lose counting that extra time (0.8 msec in this example, but you could conceivable lose almost a full scan if the ACC hit 99 msec on the previous one).

On the next scan, the DN bit is true, setting the timer back to zero. But you've lost timing this scan.

Next scan, with the DN bit now false, the timer is now enabled, and you start counting from 0. You've also not counted this scan either.

When I've built "free-running timers" like to time specific things, I don't use the dn bit, or any bit to reset the TON. I just over-populate the PRE (with 32767). When the ACC > 100 msec, I set an internal "Done" bit (not TON.DN), and subtract 100 from the ACC (which effectively makes the "Done" bit a pulse/oneshot: it won't be true next scan as long as scan time is less than my interval. If there was any roll-over (103 msec), that's preserved, as the TON is still counting, starting at 3 msec and will add whatever time has elapsed on its next scan.

Much more accurate this way, and allows me to set pulse intervals different from the S:4 bits.

 

[Operaghost]

This went longer than I intended, and others have posted replies since I started. But what the heck, I wrote it all out. Might as well post it.

Timers are not terribly accurate and really should not be used for precision timing needs. To be clear, these TON/TOF timers aren't really timers. They only update their accumulator once per scan based on how much time has elapsed since the previous scan.

As an example, let's say you have a program that scans through all of your code once every six milliseconds. Rock solid repeatable. Always six milliseconds every single time.

Now let's say your 10-millisecond timer instruction (we'll say TON) is all the way at the end of the logic. At the end of the first scan, the accumulator will read 6ms and a new scan will start.

On the second scan, by the time we reach the TON another 6ms will have passed. Your 10ms timer will have actually timed for 12ms before it turns on it's done bit. Now some PLC systems will cap the accumulator so it does not display a number greater than the preset. But that doesn't change the fact that 12ms have passed, not 10.

The timer does not stop at 10ms because the scan hasn't reached that rung yet to tell it to stop. We are at the mercy of the scan reaching our rung after the timer accumulator reaches our setpoint, but hopefully not too long after. Imagine if that scan time was 9ms instead of 6ms. Your 10ms timer would turn on it's done bit at 18ms.

Now potentially an even bigger concern when trying to do precise timing is how you reset the timer. The most common "free-running timer" would be like the graphic included. Although as drbitboy mentions, this is really a "self-triggering repeating timer".

Here is the catch for this example. Follow this sequence of events

• End of scan one Timer rung is true. Timing starts
• End of scan two Timer rung is true. Timing continues. 6ms elapsed
• End of scan three Timer stopped and DN bit has energized. 12ms elapsed
• End of scan four. Timer rung is now false causing the timer to reset. 18ms elapsed
• End of scan five Timer restarts. 24ms elapsed

From the time our timer started one timing sequence until it starts the next one ends up being 24ms. Not very accurate for a 10ms timer.

There are of course things that can help bring this margin down. Faster scan of the program, using the DN bit with a RES. And let the timer run as long as it can before resetting. These make the margin of error smaller, but they don't eliminate that error.

OG

 

[drbitboy]

when i've built "free-running timers" like to time specific things, i don't use the dn bit, or any bit to reset the ton. I just over-populate the pre (with 32767). When the acc > 100 msec, i set an internal "done" bit (not ton.dn), and subtract 100 from the acc (which effectively makes the "done" bit a pulse/oneshot: It won't be true next scan as long as scan time is less than my interval. If there was any roll-over (103 msec), that's preserved, as the ton is still counting, starting at 3 msec and will add whatever time has elapsed on its next scan.

Much more accurate this way, and allows me to set pulse intervals different from the s:4 bits.

you could also keep your timer, but make the time longer, say 50 ms, then when accum >20 do logic, subtract 10 from accum. You don't lose a scan for the reset.

The same thing can be implemented with S:35, basically building a custom 10kHz, 0.1ms-resolution* timer by replacing a TON instruction with an ADD instruction.:

ADD accum S:35 accum
GRT accum 99 BST SUB accum 100 accum NXB OTE oneshot_10ms BND

accum is an INT; oneshot_10ms is a BOOL that will be true for one scan every 10ms, on average.

That said, the difference between 10ms and 12.8ms for this purpose is negligible, so the rising edge of bit 6 of S:4 would be adequate.

* we don't see 0.1ms resolution, of course, but the mean time between rising edges of the oneshot_10ms bit will be 10ms to an accuracy better than 0.1ms.

Going back to the OP, simply changing the 10ms timer to 100ms timer will drop the incidence of missed events from half to a sixteenth or so, the ramp slope will be off by 6%, which few will notice; empirically find the best setting somewhere between 94ms and 99ms and it will mimic perfection.

 

[Firejo]

I would experiment with a couple of things (I’ve never done a timing application needing that level of timing control on a MicroLogix, so these are just ideas that I’d play around with).
First, when the timer is done, use the done bit to latch another bit. Put this on a branch of the rung the timer is on so it happens (almost) instantly. Then keep it latched until all the other rungs that need to see that the timer is done then unlatch it.
Not knowing how the logic is laid out, if you’re resetting the timer as soon as it’s done, don’t. Reset the timer at the end of the scan.
Last, I like the idea of setting the timer to run longer than needed and using a comparison instruction to set a bit at the 10ms mark. Once everything that needs to know the timer is done knows the timer is done you can then reset the timer which will let go of the bit set by the comparison instruction.

 

[OkiePC]

This is the perfect situation where you should take advantage of the STI (Selectable Timed Interrupt). If you create a new ladder file and designate it as the STI file (Look at the Function Files, STI tab). Set the time to 10ms and it will run reliably at 10ms. In that file, simply examine the condition under which the counter should be incrementing, and increment it.

You don't want to program a JSR to this ladder file, it will run every interval as long as its enable bit is set ( STI:0/UIE ). You could simply have the enable bit driven by the logic in one of the normal routines and only have a single ADD instruction inside the STI. Just do the compare math and manipulation of the enable bit outside of the STI routine.

Having an STI routine that runs this frequently is going to cause the overall scan time of the PLC to become more irregular, but minimizing the amount of code in the STI will minimize the magnitude of any scan time spikes which are only likely to cause other problems in rare cases.

I use STI routines in Micrologix for things like totalizers where I want frequent and very regular updates that need to maintain accuracy over a long period of time. I typically run them at 1000 millisecond intervals, but in one case I ran it at 100ms where I had a flow rate that could vary quite a bit within a single second. I have not used one set for 10ms but would have every expectation that it would work just fine.

 

[Christoph]

Thanks all for the great information!

 

[Christoph]

tried the STI this morning. works but the scan rate at the bottom of the setup
file seems to have no effect on timing? I have it enabled and auto start turned on.
My file executes but too fast and changing the time has no effect.

 

[Operaghost]

Keep in mind that the STI function is the timer. The Setpoint field defines the interval. It is like the PRE on your timer. No other timer should be programmed.

For your Program File Number make sure this is the LAD file to be executed. This should not be 2 which is your main ladder file. This should be a number from 3 to 255.

Then, in your STI routine, program the logic that you want executed at each interval (10ms I assume). Think of the STI function as being similar to the DN bit on your timer. What would you trigger when the timer finishes? Note that the logic in this routine will only execute one time and then it will return to LAD2 until the next interval.

OG

 

[Christoph]

It was on me this time since I used an existing ladder file I forgot to delete the
JSR in the main program ladder. All is well the STI works perfectly.