I need a always off bit in I am using rsligix 500 sopftware with a micrologix 1500. In the PLC i am used to it is a V4,V5 for off or on, you just use this adress for the NO,NC coil. What is the bit for AB I have looked in the PDF manual I have but found none so far. here is the example I have in my old PLC type. It Is in an excell file. Thank you

Hello,

I do not recall ever seeing one in any AB PLC. It would be in the status file. I just looked through the manual for a MicroLogix 1000 and an SLC and neither had an always on or always off. ControlLogix might have one but I did not look.

So, just make one. Power rail to a latch coil for on and power rail to an unlatch coil for off. Use any address you want.

Ciao,

Mark

The S:1/2 bit may serve as such, as it is always On when PLC is running.
But I always make one myself, as Mark suggested.

Use an AFI to OTE a bit. During prescan, the bit will be zero. If you use latch/unlatch, there's no gaurantee. Use XIC || XIO (logical OR) onto a latch for the exact same bit (forcing it to always be a one).

In practice, you really don't need these functions with AB PLC's like you do with the others. An AFI will always work as a "fail" or "open" condition. A shorted branch (insert a branch with no instructions on it) is perfectly legal as an "always true" condition.

FYI,
No "AFI" instruction in RSLogix500. Its a RSLogix5 and RSLogix5000 thing.

I always program an always false bit at the first rung of Ladder 2. You almost always need it for debugging/testing.

Always false bit
B13:0/0
------------------(OTU)--

Paul I respectfully suggest there are a couple of holes in your statement above.
1. Not all AB PLC's have the AFI - mentioned by others.
2. A shorted branch cannot be commented and the reason for the short can be lost over the years.

My approach is to us the following:
1. A early always scanned rung with an XIC XIO and OTE of the same bit for an always off.
2. A early always scanned rung with an XIO OTL of the same bit for an always on.
3. A set of Debug Bits, INTS, Counters and Timers. These are commented or named Debug_???? depending on the AB platform. It is generally understood that Debug Tags can be deleted without adverse response of the program.

Isn't there a NOP bit? No operation? i thought that was the always false it in rs500

Forgot about that one. I rarely encounter this problem. In my shop we only have one SLC. The others are PLC-5, Micrologix, or CLX. The SLC is running canned software from a burner vendor. We do NOT to make any changes (liability/warranty issues).



I wasn't aware that any processor except the CLX had "instruction" level comments. You really can't document a universal "fail" bit either except to call it a "fail" bit. Since at the moment the PLC-5's outnumber the others by roughly a 10:1 margin, we didn't adopt any other commenting methods. I also realize that RS-Logix has a nasty habit of losing the ordering on your comments if they aren't attached to particular bits (if program is modified but not saved) but we've survived.



We didn't label the debugging stuff separately. Hadn't thought about doing that. But one issue with those is the fact that it's sort of like jumper wires...they always get made permanent over time. So we have incorporated PLC code into the "safety" rules. Jumper wires, shorted branches, forces, and AFI's used for temporary purposes are treated just like jumpers...they are OK for troubleshooting and debugging. But if you end your shift with them still in place, they get logged and go on the work order list as a safety item. When we plan/schedule work orders, safety items always take priority over everything else on the list. This gets the "debugging" code swept from the system as quickly as feasibly possible.

The exceptions are those things that are there for a purpose other than debugging/troubleshooting code.

Otherwise it has a tendency to fester there for years and gets lost over time, as previously mentioned.

And yes, I do sweeps once in a while to verify that we're still following the rules because it took a while to change the culture.

I prefer to avoid the use of always on and always off bits as a permanent part of a program. The program can be structured so that they are not necessary.

For debugging purposes set aside a word in which no bits are addressed by any OTE, OTL, OTU, or any word write instructions, and set the desired value of the bit using the file data monitor or bit toggle when an addressed input function is selected in the ladder. This way you can easily change the value of the bits while you perform your debugging to quickly enable/disable functions without editing/re-assembling the program. As long as no write instruction addresses the bits it will remain at whatever value you set it at.

After the program is debugged, remove these bits from the program.




We require jumper permits for any force or software jumper that is installed, same as for wires. No permit is required for as long as the tech is in front of the machine, but if he leaves, he has to submit a permit. The permits are "self-authorizing" that is the tech himself is the determining and authorizing authority, this way its not a restriction, but a means of documenting to make sure that it gets cleaned up afterwards. If they desire to make the change permanent then the jumper permit is reviewed and the change is approved/rejected by engineering.


One way to keep a program is 'clean' is to make sure that there are zero permanent forces and that there are not permanent always on/always off bits as a matter of policy. Then if one does appear then you know that an undocumented change to jumper something that was once functional has occurred.

I agree with one exception. I like to have all my outputs grouped together and in order. It makes for easier troubleshooting. So if I have a spare output I will use an AFI bit with the output as a place marker.

Thanks for all the input, I needed to do the removal of a sequence in the machine and did it on wensday, I just used a output bit tied to the power rails and adressed it as a XIC I think or what i would call a NC or B type contact. When I get some time I will try the other sugestions you sent. I am making a trainer out of an old machine God knows I need it, I think you need to be real smart to do the AB stuff, man the Toyopuc is easy one cable + 2 adaptors for servo drive and very old PLC, one software for all PLC's. How much of the american market do you think AB has. I am enjoying learing it, it seems like all the job ads refer ot AB. I think I will like it when I get used to it. Thanks againg for all the help

These terms are very dangerous. You do NOT want to mix PLC and relay logic terms. This is a fatal mistake because it causes nothing but confusion for electricians. One of the worst blunders of PLC's was in naming the bit instructions. XIO means "Is it zero?" and XIC means "Is it a one?" Don't treat them as true/false or closed/open or any other meaning that has anything to do with the "real world" or just when you think you understand it, it will throw you for a loop.



AB has roughly 85% of the American market last I knew. The next closest competitors are predictably Omron and Siemens. Siemens has a large market share in Europe but nothing like the U.S., and some of that influence is felt in the U.S. Omron at one time was the king of the "small" PLC's for stand-alone equipment and holds a niche there.

AB now has a majority market in the world. They surpassed Siemens this past year. I wonder if it has something to do the with litigation Siemens went through.

AB used to be primarily a Digital Logic company, with the likes of DeltaV taking the process end. AB has now begun a thrust into Process control (even though PLC's could do process before, they weren't sold as a 'process' system like DeltaV is [like renaming prunes to dried plums and sales go up]) which seems to have picked up some business also.

Oh and the NOP I mentioned earlier is an output coil, not a contact. Funny thing is, the only way to get it is to manually type it in the rung or instruction. It isn't selectable from the instruction set and there is nothing about it in the help. At least that is for an ML1500.

HMM? see picture below.

Does it verify?

See my picture above, no it doesn't

Post your .RSS file.

I guess my memory failed me... It doesn't verify.

This is a rule I apply to any PLC I am working on. No matter the brand. When I was on the plant side and not the OEM side I would keep these data blocks in the program and have them labeled as Debug.
I would elve them in the program so I could search for them later. All of the other programers would pick from here if they had to do a tempoary fix. This way others could find them

Now on the OEM side of the fence I delete them as soon as I have the project completed so I can just do a program compare and see if my customer has been maki9ng any changes.