SLC 5/05 S42 timing problem

[ian.smith7]

Hi all
We have a mixer controlled by a SLC 5/05 64K PLC. The rack includes some digital I/O, HSC2, and a RIO scanner. The RIO has some digital I/O and Data transfers to two PowerFlex Inverters.
It is quite common during a mix cycle for the time count to miss seconds. So a timed phase of the mix that counts off 150 seconds actually takes 150s to 200s, in severe cases.
We have traced the problem back to one line of code:

IF S42-NEQ-N7:0 then pulse B3:0/0 AND S42-MOV-N7:0

Most of the time this works fine and B3:0/0 gets a one scan pulse every time S42 changes value. However sometimes the value in S42 can change by 2 in one jump causing only a single pulse of B3:0/0.
This would seem to be a scanning issue but I dont really have clue were to start fault finding for the cause.
Thre are two identical mixers and both suffer from this problem.
any help is appreciated.
Ian

 

[SNK]

Not trying to re-invent the wheel, but is this a turned over piece of OEM equipment, or are you developing the code for release? The reason I ask, is that problems like this don't just appear all of a sudden in released code that functioned properly originally. Is this a known issue with the piece of equipment, and you are looking to fix it?

If this is a "critical" element within your application, and you have known "Scan" issues with that particular code, then maybe you need to consider using the STI function within the Rslogix 500.

If you have a time-sensitive event, this routine can bypass the original not-so-sensitive elements and do a specific routine faster.

Look up the STI (Select Timed Inturrupt)

 

[ian.smith7]

Hi SNK
The Machines were installed about 3years ago by the OEM. There have always been some issues with the machines related we think to this problem. It now seems that the OEM will never get round to putting this right so it is up to us to do it and I have been asked to do what I can.
There is already a STI ladder in the program used to collect energy readings from the Inverter. I have already tried moving the single line of code into this STI but it actually made the problem alot worse.I have also tried a self reseting timer but this did not improve things.
The STI collects power reading from the inverter over the RIO Scanner every 50mS, I think this is far too much could all that data transfer create longer gaps between the logic scans?
The Timing problem also comes and goes sometimes not being apparent for days then sometimes coming and going 3 or 4 times a day.
cheers
Ian

 

[mellis]

It all depends...
An STI running at 50ms may cause havoc with the main scan if it takes too much time. Look at the scan time of the STI, hopefully it is just a few ms.

Would it be possible to post the actual code? Or even a sanitized version of it? (the sanitized version would have to exhibit the same problem of course)

 

[SNK]

is it possible to track the time/s that the RIO failures are occurring?
If you can determine a common element of something happening....what other elements are on the RIO rack?
Maybe the RIO scanner is not the best method of transfer for your process.
Does it "appear" that the timing is missing, or can you actually verify that it is missing with some home-brew code that you can add?
I would add a couple of rungs of data in, and verify that what you see on your HMI is actually indeed happening.

 

[ian.smith7]

Hi
At first we used stop watches to verify the incorrect timing. Then to give us an idea of how bad the problem was we installed an omron timer, set to 30s, controlling a beacon. A 29s PLC timer resets the omron before it times out and flashes the beacon. This made us aware that the problem was worse than we thought because the beacon flashes more than we notice the effect on our process.
We also added "traps" to detect which parts of the program were lagging, We found that s42 keeps perfect time whilst all the logic drops seconds.
We seem to be zeroing in on the STI, I will have a look at slowing it down maybe 100 or 250mS will enough to make a difference. There are two inverters that are controlled over the RIO I will have to check that they respond ok at the slower rate.
We Have tried to track the occurences to find any trends but this has not highlighted anything.
I will probably not get a chance to look at this till monday at work.
Thanks
ian

 

[Ken Roach]

The S:42 system clock should not be relied upon to produce a pulse every second. See RA Knowledgebase Article ID # 15415.

To get an idea of how additive error works, get a stopwatch, close your eyes, and count out seconds aloud "one-Mississippi, two-Mississippi..." until you get to 60 seconds. How close were you to the stopwatch ?

PLC program scan evaluation of a large-increment clock is a poor method of timing.

The way a real Timer instructions work is that the instruction checks the value of the free-running clock (S:4) when it starts and again every time it is evaluated. The increment on the free-running clock is 10 milliseconds.

If it is at all possible, replace the 1-second-pulse Counters with Timers (which are really 10-millisecond counters inside) and you should have far superior timing, especially over the course of long periods like 150 to 200 seconds.

 

[ian.smith7]

Hi Ken
That seems to be very similar to our issue so I will look at using S4.
I had a quick look at the STI timing today and found one mixer set to 10ms interval and the other to 50ms. I will check on monday if the 10ms mixer has the worst problems.
thanks
ian

 

[Ken Roach]

Take a little step back.

I recommend against taking that Knowledgebase document literally, because the S:4 free-running clock is really a free-running counter, counting 10 millisecond increments.

"Great!", you may think. "I'll just use 100 ten-millisecond increments from S:4."

I have seen a lot of programs that try to use individual bits of S:4 to do that, but that doesn't usually work because each bit represents a binary multiple of 10 milliseconds, not a decimal multiple of 10 milliseconds.

If you were to use, for example, bit address S:4/7 to generate a pulse bit, the pulse would come on every 1.28 seconds because 2 ^ 7 = 128. Not a big deal if you need to flash a beacon, but not suitable if you need to count seconds.

If you were performing a science experiment, you could copy the S:4 word to a storage register when the timing interval began, then add the number of 10 millisecond increments you want to measure, and compare the current value of S:4 to that larger value every scan. Don't forget to account for rollover of the clock.

You probably don't want to do all that, which is why the instruction set includes the TON and TOF instructions. Re-write the counter logic to use actual timers instead.

 

[Ken Roach]

The STI also seems like a very strange way to measure energy consumption on a drive, especially one connected to a RIO scanner.

What exact parameter is this program reading from the drive, and what are they doing with it ?

 

[ian.smith7]

Hi Ken
I Had a similar discussion about s4 with a colleague at work and we came to the same conclusion about s4 bits. The Things is that we think the method used (Comparing s42 to itself and detecting a change) should be accurate enough for our purpose. The issue we think is the scan time taking over a second to complete since the logic seems to miss the change of one full second in s42, therefore creating only one pulse for the passing of two seconds. Unless that is the whole point of the article you linked to???!!.
For 80% of production time the s42 method is perfect but when the time starts to drift out of synch it may last 10 mixes (about 30mins) getting slowly worse then fading until the time is perfect again or it may last 2 or three hours affecting only one mixer or both to different degrees. So we Have focused on the scan time problem as the cause, and are looking to fix that.
The mix can be controlled using set points of time (Say 150s) or energy (XX KWh/Kg). The parameter grabbed from the PF700 inverter is (parameter 6?) instantaneous power at the inverter output terminals. This then totalised and converted to KWh/Kg using a calculation based on the number of samples per second (as set by the STI time period). Now since this is also a time based setpoint it is also afected by the timing issue and is obviously an incorrect measurement when seconds are dropped. Also we are aware that Parameter 6 is not Torque power (parameter 7?) which is a better indicator of energy input to the product (another unresolved OEM discussion point).
cheers
ian

 

[monkeyhead]

Ouch... Scan times at over 1 second? Is the program just that huge or do you have a ton of unassembled edits? That in itself should be a concern.

Anyway, like Ken Suggested, if you re-work the logic a little bit to use a timer and it's associated 'state' bits (enabled, timer timing, and timer down/done), you should be able to make this logic much more reliable.

Is there a reason you're stuck on using the free running clocks, S:4 bits? Seems like they're causing you more headache then they are worth.

You could also set up a timed interrupt for this logic. This way even with a ridiculous scan times, you can be sure that the logic is run on a set interval.

 

[Ken Roach]

The scan time of the controller can be determined with certainty from the Status file, in the Scan Times tab.

You're assuming the System Clock is perfect and that your program scan is too long. The point of that Knowledgebase article is that the System Clock is not perfect at the 1 second level because of how it gets updated in the operating system.

Heck, the MicroLogix 1100 only updates the System Clock every 2 seconds... it never displays an odd value for Seconds !

Use the System Clock the same way you would use a clock hanging over the kitchen table; for determining when it's time to go to work, or how long since you put the lasagna in the oven.

Since you're using one of the large-memory SLC-5/05 controllers, I realize the system program may be large and it might appear to be a daunting task to convert it from using Counters of 1-second pulses to using real Timer instructions.

But it's worth it. You get the opportunity to make your system work correctly, plus the fundamental satisfaction of using the right tool for the job.

 

[ian.smith7]

I'm not sure if you have read this topic all the way through but I have already said that we have tried unsuccessfully to replace the s42 comparison code with a 0.01ms x100 self resetting timer and it did not work any better. Am I missing something about the way you intend the timer to be used?
The s42 comparision is used only once in the program to create a one shot bit. This then drive other bits in the program that are used to drive various elements. So it is only a single line of code that needs to be replaced.
ian

 

[504bloke]

I'm not sure if you have read this topic all the way through but I have already said that we have tried unsuccessfully to replace the s42 comparison code with a 0.01ms x100 self resetting timer and it did not work any better. Am I missing something about the way you intend the timer to be used?
The s42 comparision is used only once in the program to create a one shot bit. This then drive other bits in the program that are used to drive various elements. So it is only a single line of code that needs to be replaced.
ian

Can you post your program ?