Sign in to follow this  
Followers 0
waterboy

RS5000 - Is there a variable for Rung number?

10 posts in this topic

I have a sequential program that simply goes down the ladder one rung at a time. each following rung depends on teh one above it. I want to add a tag that tells me which rung is currently true. I can MOV a specified value to a register for each rung but if I add a rung in the middle I have to change the value of all the MOV commands that follow. Is there a variable that I can use that is aware of and can insert the rung number that is currently true into a register? Or do Rung numbers only exist in the IDE? Edited by waterboy

Share this post


Link to post
Share on other sites
I looked briefly in the online help but didn't see any system variable that would contain the current rung number. There may be something available in fault handling but that doesn't help in normal operation. As you've already noticed, rung numbers change as programs are edited. The specific rung number doesn't matter as long as the program is written in the right order. I suspect that what you really want to know is which condition is true. In that case simply assign an arbitrary value to each condition and put each value into the MOV instruction on the corresponding rung. When a new condition has to be programmed, just add it at the end of the list or leave gaps in the values to add new entries in order. What do you do with this value - just display it, trigger other logic or drive a multi-state indicator? By the way, you're only the second person in 25 years that I've heard refer to any PLC programming software as an IDE.

Share this post


Link to post
Share on other sites
I had written in ASM in a previous life, and VB now. I suppose I will always be stuck with the PC conventions.

Share this post


Link to post
Share on other sites
You can't get there from here.... It is possible to determine which routine is executing. It's undocumented but some of the additional data that the fault routines return include an object number which indicates the program and routine which can be decoded using GSV calls. The remaining data tells you where within that routine the fault occurred. However, remember what's going on here. Logix 5 is a tokenizer...it stores the program in a PLC-5 as a series of tokens. The PLC-5 is an interpreter. It should be relatively easy to reverse engineer it using the upload/download functions in PCCC although I know of no one who has actually done so. With Logix 5000 though, it's an entirely different matter. Logix 5000 is actually a compiler and Allen Bradley is very clear on this point. It is certainly possible to decompile the code and decode exactly where in the code the problem occurred (in a fault routine for instance). And the code can be downloaded again through the PCCC interface. However, there are two hurdles here to implementing this within the PLC. First, it is still possible to reverse engineer the compiler but the level of difficulty for compiled code vs. tokenized code (considering that most tokenized code looked an awful lot like P-Code back in the early 80's when the PLC-5 came out), but without knowing anything about opcodes or anything else, the level of difficulty for doing so will be substantial. Second, I don't know of any way to execute the required calls through the PCCC interface nor am I aware of any GSV calls that could be used to extract the required code from within the PLC itself to do the decoding there. At best, I can suggest that you purposely introduce code to cause a fault within the subroutine and carefully note the results returned to a fault routine. As I said the return results to the fault routine contain a lot of undocumented data but it definitely does return the object number of the task, program, and routine. There is some additional data that certainly must include the location within the routine since otherwise Logix 5000 would not be able to display the "rung number" in it's fault display. Using this technique you could certainly map at least approximate locations of each rung and do as you desired. But after spending several hours looking at this myself, I can confidently say that whatever the remaining undocumented return values are in a fault routine, the rung number itself is not in it.

Share this post


Link to post
Share on other sites
I really didn't think it was possible but had to ask others who know better. I'm pretty sure this is a logic (or perhaps MSG) race situation between 2 processors and their hardware so disassembling the code probably wouldn't show me anything unexpected. I'll try Mikes random number suggestion, its a start. Thanks to you both for the replies.

Share this post


Link to post
Share on other sites
You can do it with an AOI that executes whether the rung is true or false (L5K V17 or later is required). However, I'm hesitant to provide the solution. I just don't see how knowing a rung number is good programming practice when what we should be interested in is the state of the machine, not the particulars of the program. I'm not sure that even knowing the rung number is going to eliminate problems if you insert a new rung - it still changes the number. If you are comparing it to something later in the program then you still have to change that other code. However, despite my misgivings, I'm including a rudimentary example. I think its asking for trouble though (thats my disclaimer). If I correctly understand your post then its much better to use sound state machine design methods where you don't need to worry about the rung number. For more on sound state machine design methods download the Hugh Jack textbook found on this site. edit: For things like debugging I usually create a series of booleans with descriptive names starting with the "debug_" prefix, eg debug_Function1, where Function1 is descriptive text of the function, debug_LowLevelCutOff for example. Then I use OTE or OTL instructions to set the bit on rungs of interest. Display them in a watch window or search to see which rung set them regardless of where in the program the rung is. RungNumberTrackerExample.ACD Edited by Alaric

Share this post


Link to post
Share on other sites
I have written a piece of code where having the rung number would have a legitimate and very good use. I had a PLC which had a number of different relatively independent systems. These systems were relatively small and having independent Logix PLC's for each one would be cost prohibitive and silly since some of them would be less than a dozen rungs. It was also an operation which was subject to online programming on a regular basis. The basic concept was that each independent system would be in a separate program. In the event of a fault, a user fault handler would check for a "type 4" fault (which indicates a program error such as divide by zero or a timer with a negative value). The fault handler would set the inhibit bit on the offending program thus shutting down ONE system, store the fault data, and then clear the fault so that the remaining systems could continue running. Although the program and even subroutine were easily detected, it is not possible to detect the rung number. So the one additional piece of information that Logix 5000 gives you for troubleshooting is not available from a user level fault routine.

Share this post


Link to post
Share on other sites
Waterboy - you are on the wrong track with this. Your PLC does NOT hold up on a rung waiting for it to become true, ALL the rungs are scanned continuously, and indeed you could have many rungs "true" in one scan of them. The relationship between actual rung number, and the current step of your sequence logic cannot be associated with each other. Think of it this way if Alaric's excellent post confuses you - your "sequence" will have a defined set of "states", or steps, that are defined in the functional description of the sequence. Try to program your "sequence" to shift from one state to the next, depending on the required conditions, not just to enable the next rung. One way to do this is to have a "Step Number" variable, that you can increment in your sequencer logic to move to the next step or state. A common technique for doing this is for each "step" of the sequence to have an OTL of a bit called "Step_On" or similar. Then program a conditional ADD to increment the step-number, and an OTU of the Step_On bit. Edited by daba

Share this post


Link to post
Share on other sites
If you really want sequential execution, maybe SFC would be a better language? This costs extra, so maybe you're stuck with ladder. You can get sample code from RA for step sequencer in ladder Sample code search "sequencer" There's AOIs that let you execute ladder one rung at a time, and transition to the next when you get past the current. You can see if a step faulted and which step you're on, too.

Share this post


Link to post
Share on other sites
http://www.plctalk.net/qanda/showthread.php?t=52654&highlight=WASHING+MACHINE The above link has some logic in it that is probably similar to what Alaric describes.

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