AB PLC 5/20e

Hello...Im baffled about a problem that has developed in the past week in a system Im working on that has an AB plc5/20 communicating with a plc5/40 via blue hose. I use a message command from the plc 5/20 that writes one word of data from an I:1 file (AC input) to a binary file in the plc5/40. The input represents one cycle of a Roots Meter Gas totalizer (one cycle represents x SCFH). When the bit goes true it hold true for about a minute or so. The bit in the 5/40 used to follow it perfectly until recently. Now it seems when the original ac input goes true and holds, the corresponding bit in the 5/40 goes on and off, many times, thus generating a false gas usage total. Ive checked for redundant address, msg commands, etc...cant find reason for this to start. Any ideas out there?

I'm going to assume you've checked for loose wires onthe input card, etc.

Most often this behavior indicates the bit in the binary file is being overwritten. Either something else in the program uses the same address or else communications from another PLC or operator interface is writing to the same address. This is sometimes hard to find because the adress in question is hidden in the middle of a block of data being copied or communicated.

must type faster ... must type faster ...

darn ... while I was typing away, Tom beat me to it ... but I hate to waste all of this so I’m going to post it anyway ... maybe the repetition will be beneficial ...

Greetings jrs2563,

this is just a wild guess based on what you’ve posted:

something else (PROBABLY located in the PLC-5/40’s program) might be overwriting the binary word ...

recommended plan of attack for troubleshooting:

temporarily change the “write-to” address in the message command to aim it at a new UNUSED binary word in the PLC-5/40 ... see if the bit settles down ...

or MAYBE the actual input in the PLC-5/20 really and truly IS turning off and on (you know that you can’t always trust the ON/OFF status on the screen display) ...

so temporarily change the “write-from” address in the message command to take the data from a new UNUSED binary word (specifically not an “I:” Input word) in the PLC-5/20’s memory ... see if the bit settles down ...

let’s suppose that the last step above DOES settle the binary bit down ... but you can’t come up with any logical reason for the actual “I:” input bit to be going on and off ... here’s a REALLY long shot to look for ... suppose that someone has entered a typographical addressing error on an OTE (Output Energize) instruction ... and instead of “controlling” something like “O:123/0” they’re “controlling” your input bit “I:123/0” ... again that’s a bona fide LONG SHOT ... but I HAVE seen it happen once or twice ... basically that type of error will hijack the ON/OFF status of the input bit and cause it to act erratically ...

another thing that could be causing the binary bit in the PLC-5/40 to jump around is an HMI ... sometimes (rarely but it DOES happen) the HMI programmer makes a typographical error and hijacks (and therefore controls) a bit in the PLC ...

and just for completeness ... based on what you’ve posted, I do NOT think that this next one has anything to do with your current problem ... but do you realize that in a PLC-5, the MSG (Message) instruction is an “asynchronous” instruction? ... that means that even though the MSG rung might be EXECUTED right !NOW! in the processor’s scan, the actual transfer of information between the PLCs might not occur until some time !LATER! in the scan ... how much later usually depends on network traffic, etc. ... once again, I don’t think that this has anything at all to do with your problem ... but ... it MIGHT be something to think about if nothing else turns up ...

finally ... is there any reason why you can’t zip your .RSP files and post them on the forum? ... we’d be glad to take a look at them for you ...

Ok, Thanks Tom & Ron...back to work today...I will try what you guys said! Jim

i/o behaving strangely in a PLC5 chassis ?

Power down the chassis.
Remove and insert the module in question a number of times.
Power up again.

This has cleared up a few PLC5 i/o problems for me in the past.
I believe there is a design fault in the connector between the module and the chassis.

ok...here is how it went today, fellow PLCers...I changed the "target" binary word from B3:2 to B3:4. Everything is working
just fine now. Why I incurred the problem with B3:2 I still haven't been able to figure out. Can't find any evidence of another word walking over it...but obviously there has to be some of that. It's kind of a lengthy set of rungs...about 210 or something like that. I'm sure I'll find out the original cause evemtually. In any case, thanks alot for all your help you guys. It is very appreciated. Jim Schroll