ONS getting stuck True PLC5/40E

Has anyone experienced a ONS instruction bit getting set true?

Its happened twice in the last 2 weeks to the same bit. The process has been running for years.

The bit address is only used once, and the word is only used for individual bits.

I thought I did - several times, but....

Every time I have had that happen, I have eventually found that it was somwhow used elsewhere (in the program or HMI) or I have found that it was in a routine that was not being constantly scanned.

I have also struggled with my laptop being able to display it properly. Look at the bit in your data table to confirm that it is remaining a "1".

zymie said:

Has anyone experienced a ONS instruction bit getting set true?

Its happened twice in the last 2 weeks to the same bit. The process has been running for years.

The bit address is only used once, and the word is only used for individual bits.

Click to expand...

Can you provide a screenshot of the logic where that particular ONS is getting used, if not the whole program in a zipped file?
That would help people give you a solution/reason more quickly.

Taking a stab in the dark:
Are you referring to the output bit or the ONS storage bit?
I am asking that because the ONS storage bit remains high as long as the Logic before it remains true.

I can't recall seeing that particular issue, but I've had some strange things happen in PLC5s over the years. More than once, I've had timers that wouldn't operate, deleted them, put them back just as they were, and it fixed the problem. I think that online changes fail to compile properly sometimes.

It's always either a misunderstanding of the ONS, a programming error, or an HMI or remote PLC modifying the bit. If it is truly only used one time then you should be able to change the address of the ONS to another bit. Use another bit in an unused word.

The problem of course is that you can't cross-reference if it is happening due to an HMI or remote PLC.

OG

Operaghost said:

It's always either a misunderstanding of the ONS, a programming error, or an HMI or remote PLC modifying the bit. If it is truly only used one time then you should be able to change the address of the ONS to another bit. Use another bit in an unused word.

The problem of course is that you can't cross-reference if it is happening due to an HMI or remote PLC.

OG

Click to expand...

You forgot indirect addressing...classic

Hi

Also mvm , cop and of course the same address used twice in he program.
I have yet to see this problem that it has not been a program error or a new button etc added into the HMi

But there is always a first time

Donnchadh

Donnchadh said:

Hi

Also mvm , cop and of course the same address used twice in he program.
I have yet to see this problem that it has not been a program error or a new button etc added into the HMi

But there is always a first time

Donnchadh

Click to expand...

True: BUT, don't you think that someone would have found it in the last 20 years?

My counter part at work told me he was among the first PLC-5 users to use MSG instructions I believe the story goes, perhaps a certain but documented usage that he claimed altered ladder logic without faulting the PLC. This was immediately fixed as a bug, not something many customers ever saw.

I have never seen a Allen-Bradley PLC in run mode have it's code altered (aside from the multi-step RSLogix5/500/5k Online editor method) or fail in any way other than the sole red LED and complete fault mode all all outputs. And, frequently it will clear it's own memory.

My former employer used hundreds (perhaps 500+) of the PLC-5.

I saw one failure among the 200 or so of them in three departments.

It failed due to a flood that literally drowned 7 machine panels with a waterfall type flood, right through the big square holes were cut out to clear the wiring to the servo drive brake resistors on top with expanded metal covers.

The other six machines using with that setup: A 5/40L +16 slots of AC I/O...came out fine after being dried out and powered up again. I had to reload two of them, and one of them I had to go in serially to revive the DH+ ports which showed to be disabled. (Yes, all of them, but hey, they didn't drown, just turned off).

The only time I ever saw a dry one with a known fresh battery dump it's program was due to a failing power supply that eventually died six months later when the machine dumped its program and went to FAULT status the 2nd time.

The PLC-5 is the Muhammad Ali of PLCs in my book. If that bit changed, it happened for a perfectly explainable reason.

Prior to the PLC-5s, 19 of my machines had the ISSC IPC (310 I think) controller. It could, and did, literally go apeshit mad and show ladder logic with open branches on the CRT:

I am at desk, reading email. Operator enters the lab and says "Hey, Paul, this machine over here is going nuts?"
I am thinking yeah, whatever, and when I ask him what it is doing as I follow him to the door to he floor, he says "going nuts" which kinda pisted me off.

So I go over there, the operator resets the e-stop, and every motor, solenoid valve, indicator light, you name it started randomly going off and on.

This was a big complicated tire assembly machine with lots of screw drives and appliers, conveyors, web handlers, around 500 I/O probably 60 motors.

All of them going wild. I opened the panel door, and the outputs in all three racks LEDs (plc driven) were all flickering like Christmas lights. I Fonzied it once on the big aluminum housing, and it quit, went right back to normal. I found the watchdog module* working and jumpered, so I yanked the jumper, they built a tire. It was fine. I tried to make it fcuk up again for 30 minutes tugging twisting and looking for loose plates...I couldn't make it screw up. I shrugged and said run it. They nicknamed me The Exorcist for the day, and we left it at that.

*The watchdog timer was a capacitor timer powered by the backplane the was reset between scans. This timer took up one slot and was to be installed in the last slot in the parallel I/O bus. If the logic stalled, the timer would open a contact you wired into mid 70's era e-stop strings.

The stuff was old and often flaky and suspect and left jumpered by the floor guys.

Hi

True: BUT, don't you think that someone would have found it in the last 20 years?

This is also ture but I should have stated that maybe someone just changed a bit in mask move compare word from 0 to 1 by mistake or in some words that are used in indirect addressing the last two weeks or so.
If someone had the data tables opened and changed the bit by mistake
If the code could be posted I am sure we could rule out some items and maybe even find it


Donnchadh

Without the code we are just guessing, not finding a solution. However, if it hasn't been a problem for 20 years and now is, then one wild guess is that indirect addressing driven by a parameter or other process variable is the problem. The parameter is out of range, causing the indirect address to access a word it was never intended to access.

Just a guess.

Are there any addresses in your program that are in brackets?
For example MOV N7:0 B3:[N7:10]
If so look at the number stored in the address in brackets. If it matches the word where your ONS storage bit is stored then find out why the value in the bracketed address is out of range.