Sign in to follow this  
Followers 0
Boss2553

always on or off bit?

20 posts in this topic

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 v4_v5.xls

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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. Edited by Sergei Troizky

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
FYI, No "AFI" instruction in RSLogix500. Its a RSLogix5 and RSLogix5000 thing.

Share this post


Link to post
Share on other sites
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)--

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Isn't there a NOP bit? No operation? i thought that was the always false it in rs500

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. Edited by Alaric

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. Edited by IamJon

Share this post


Link to post
Share on other sites
HMM? see picture below.

Share this post


Link to post
Share on other sites
Does it verify?

Share this post


Link to post
Share on other sites
See my picture above, no it doesn't

Share this post


Link to post
Share on other sites
Post your .RSS file.

Share this post


Link to post
Share on other sites
I guess my memory failed me... It doesn't verify.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0