RSL5000 ONS instruction

Hi Guys,

In some of my ladder logic in a program I wrote I have used several ONS instructions. None are tagged the same so there is no issue with crossing. Anyway part of my program operates an ONS which then resets several counters. This section of ladder logic is run by the system approximately 30 times per day 6 days per week and this issue has crept up just twice in the last 10 days. (The system has been live for approximately 3 weeks now). What appears to be happening is the ONS seems to activate but not reset so the next time the section of ladder is operated it won't activate. It is extremely important for this not to happen as the whole system cannot carry on until the counters are reset.

When I looked at the ladder logic I realised that I didn't have any real need for the ONs instruction so I've removed it now and time will tell if this solves the problem.

My question is this; can a ONS 'stick' for no apparent reason? Or even can the processor miss the scan the ONS was supposed to operate on?

Any advice would be a great help for future programming. I have found that ONS instructions tend to be a little hit and miss with RSL5000.

I can't say I've ever had a ONS misbehave. A couple of things come to mind:

1) Is the routine always being scanned? Or is there a condition that disables it from being scanned?

2) Is the coil for the bit that resets it in a different task than your ONS and reset?

My thoughts are that maybe the logic that controls the bit ahead of the ONS is in a different routine or task and it the routine with the reset isn't being scanned when your reset command is coming on. Or if it's in a different task, the bit isn't on long enough for the reset task to see it.

we can give you detailed help with this - IF you can post your entire project file (.ACD) ...

you'll have to zip it first - forum rule ... if it's still too big even after zipping, try doing a File Save As operation - and set the file type for .L5K ... that format is usually much smaller in size ... you'll still have to zip it to post though - same forum rule ...

we'll still try to help even if you can't post the entire project file - but we'll mostly be just speculating about what might be causing your problem ...

Do you have this encased in an MSR ?

If you don't trust the ONS, write your own:

Line 1:
XIC Input XIO Bit1 OTE Bit2

Line 2:
XIC Input OTE Bit1

Bit1 will only let Bit2 come on as a OneShot when your input comes on, this is what I use on systems that don't have a OneShot or InputRising.

JonAW said:

This section of ladder logic is run by the system approximately 30 times per day 6 days per week

Click to expand...

I'm guessing without actually seeing the code, but this is a big clue right here.

ONS is a computer instruction, it is not a device. Unless the ONS instruction is executed on a particular address then the contents of the address will NOT change. So if for example, you have a ONS instruction on a rung in a periodic task (or a conditional subroutine) and every time that rung executes the input condition to the ONS instruction is the same, then the computer instruction is not going to modify the contents of its storage bit, and it doesn't matter how many times the input conditions may have changed during the times when the rung was not executing, because it is a computer instruction, not a device.

Well put.

TConnolly said:

I'm guessing without actually seeing the code, but this is a big clue right here.

ONS is a computer instruction, it is not a device. Unless the ONS instruction is executed on a particular address then the contents of the address will NOT change. So if for example, you have a ONS instruction on a rung in a periodic task (or a conditional subroutine) and every time that rung executes the input condition to the ONS instruction is the same, then the computer instruction is not going to modify the contents of its storage bit, and it doesn't matter how many times the input conditions may have changed during the times when the rung was not executing, because it is a computer instruction, not a device.

Click to expand...

Thanks for all the replies, I don't think my explanation was very clear so I'll attempt to clarify. Unfortunately company policy will not allow me to put the program online. And I've left the programming laptop at home! doh.

The ONS instructions are not in a periodic routine. They are in a routine which is scanned as normal. What I meant to say is the customer operates his weighing system approximately 30 times per day. The plc is scanning the instructions all the time.

The XIC bit in front of the ONS are operated on another routine. I am monitoring an auto start bit for a motor, when this is made the ONS instruction operates to clear process counters. The motor normally runs for approx. 4 minutes at a time without stopping. When it stops it will not be required for another 5-10 minutes. The motor does not start and stop continuously at all. I am not activating a reset for the ONS, I am relying on the opening of the XIC instruction to reset the instruction. I have 3 sets of the same logic with different tag names performing identical functions on 3 motors and all 3 did the same thing at the same time. Normally this logic works perfectly fine which is why I'm finding it difficult to understand what is going on.

Is it possible there could have been an interruption for some reason that would have prevented the plc from resetting the counters? I personally feel this is unlikely as each motor runs at different intervals. At no time can all three run together.

I'm just wondering if anyone else has had issues with unreliability of ONS instructions? If not then it must be an issue with my sequencing or programming somewhere.

The only times I can recall having issues with counters and resets
is when the resets have not been either before all instruction used
to operate the counter or after all instruction used to operate the counters

They should not be in the middle

The counter resets are at the bottom of all the counter operation commands so I don't think this is the issue.

OK, I've finally got to the bottom of this one. It turns out my ONS are working fine. It was the operator inserting too low a value into the system which caused it to get trapped in a procedure.

Basically the system normally works in tonnes, the usual value being 4000kgs but the operator accidentally entered 4 kgs causing the program to jump through it's sequence without actually putting anything into the weigher. As the weigher was still classed as being empty, it would not discharge trapping the sequence of events. Something I didn't account for when programming but is easy to rectify. When no-one else seemed to be having any issues I knew it had to be on my side.

Thanks for all the help guys.

Jonny