rung jumping

Help:

I know this may sound stupid but I need help using rsl500 W/ a 1200

processor in that if a condition exists I need to jump over a line of logic and resume operation.

Thx in Advance.

In your RSLogix 500 software go to the help button on the top then select the SLC Instruction Help Button. This will open a label of instructions. Select the JMP label. This will instruct you how to use this function to jump through the program to different locations.

Did this quickly, feel free to play, and anyone else feel free to pick holes

LowerySJ said:

Help:

I know this may sound stupid but I need help using rsl500 W/ a 1200

processor in that if a condition exists I need to jump over a line of logic and resume operation.

Thx in Advance.

Click to expand...

If you're just trying to "jump over" a single rung, why not just negate your jump condition and make it a contact within the rung.

The JMP leaves the output on the jumped rung in the same state as it's last scan. Placing the condition as a negate would turn off the output. Two very different results. We don't know which is intended.

504bloke said:

Did this quickly, feel free to play, and anyone else feel free to pick holes

Click to expand...

OK, 504bloke, this has holes everywhere

Just a note of caution. Jump and GoTo statements, although sometimes useful, are considered bad practice by myself and some other programmers. It is very easy to end up with "spaghetti code" that is very difficult to follow and to debug.

A more preferred technique is to put the code in question in a subroutine and use logic to call or not call this subroutine as required. Although it may not appear to be much different, this makes life much easier for the guy troubleshooting the program later on.

If you feel a jump is the way to go, document the heck out of it and use with caution.

Tom Jenkins said:

Just a note of caution. Jump and GoTo statements, although sometimes useful, are considered bad practice by myself and some other programmers. It is very easy to end up with "spaghetti code" that is very difficult to follow and to debug.

A more preferred technique is to put the code in question in a subroutine and use logic to call or not call this subroutine as required. Although it may not appear to be much different, this makes life much easier for the guy troubleshooting the program later on.

If you feel a jump is the way to go, document the heck out of it and use with caution.

Click to expand...

So true Tom

I have Never yet used a Jump or Goto, i guess there will always be a first time for everything!

I just answered the question

geniusintraining said:

OK, 504bloke, this has holes everywhere

Click to expand...

Damn, i must need glasses, getting old i suppose!

There is nothing wrong with JMP (or SKP). I use then regularly to enter new code - on-line. The code-change might take a day or two... depends on the extent of the change and, of course, the clock.

As in any case, careful planning and careful use are paramount in coding of any kind (new coding or code changes).

And, being the bloody heretic that I am (that is, unorthodox by some standards), I actually duplicate outputs in the new code that are already being used in the existing code! OH MY GOD!!! BLASPHEME!!! BLASPHEME!!! BURN HIM AT THE STAKE!!! BURN HIM TWICE!!! FOR GOD'S SAKE, BURN HIM THREE TIMES!!!

Of course, I'm an on-site, resident, programmer. I can afford to take my time to do what really needs to be done. After all, I have a day-to-day vested interest in keeping the operators happy!

OEMs make a "canned program", and that's that! The operators are left sucking hind-tit! It is what it is... good luck!

As an on-site programmer I can watch the process, day-in and day-out, and see what the operators need before the operators know that they might like this or that! I'm so far ahead of them in terms of what the difference is between what they want and what is possible, I NEVER get any "Gee, what if..." input from them!

The production crews that are working these days (except for the long-term Foremen) haven't got a clue that production has been improved 84%! And that was accomplished, by some moron (namely, me), sitting on-site, watching the process, day-in and day-out, detecting issues before the production crew even had the slightest idea that there might be any issues at all.

This is the value of an on-site guy that is intimately familiar with the process and the actual production requirements!

Then there is the idea of using JMP/LBL to act exactly as a subroutine would work! The only difference is that the code within the "faux-subroutine" is entirely accessible, for any length of time, during run-time, without causing any operational issues!

Too many programmers think that PLC programs must only be fixed and rigid in their construct and execution. Of course, this is indeed the case for an OEM program (unless there is a conscientious on-site programmer available). Aside from the OEM situation, too many on-site programmers simply don't recognize that, for those PLCs that allow real on-line programming, the process can be a living, changing, growing, and continuously maturing, process!

With respect to my process, I have more changes in-mind that will bring the process well beyond a 100% improvement! It's all done by looking at the process from the operator's point of view and looking at what is possible.

If you make/keep the operators happy, you can't help but make/keep management happy! This is based, of course, on the assumption that all operators want to look good before their bosses! Sounds like reasonable logic to me.

And finally, for an on-site programmer, using JMP/LBL, only as necessary, to reach Corporate goals, sounds entirely reasonable to me.

Once an OEM program shows up on my site (and yes, we do take them on), the OEM can go to... the lake, the ocean, or wherever he can float his high-dollar boat.

I have to say, I disagree very much with the very rigid, very orthodox, PLC-programming philosophy! Whether you like it or not, we are dealing with logic and computers!

With respect to process controls, if you can think it... it can be!

The AB platform allows you to edit and test edits. I have no need to duplicate outputs to test code, nor would I want to. I do not need to enter new code using Jmp Lbl. If I needed Jmp Lbl I would use it. I don't. The poster is using AB, there are better ways of coding than Jmp Lbl on AB machines.

We have about 12 people that have to troubleshoot from time to time. I am being fairly inconsiderate if I use code that is more difficult to follow. Keep it simple.

We do use subroutines to organize and streamline code. All subroutines can be edited online there is no problem there. I find it a LOT harder to work with code that is all in one routine, let alone filled with Jmp Lbl instructions. Yes, it is not rocket science it can be done. But why?

If your platform supports subroutines that allow online edits then use them. They are easier to follow period. I realize that scantime is effected by them slightly. I am spoiled we run CLX. Scantime is never a problem.

I know I I kind of got off topic, sorry. I have a strong dislike for JMP, LBL, and MCR instructions.

If a person chooses to code using Jmp Lbl that is there choice. If you are serving customers internal or external I think you are making life more difficult for everyone now and in the future.


RSL

I have a project using RSL500 using processor 1200C in which I need to keep an output energized anytime the PLC controller is active, on line and functioning properly. In case of controller failure or power outage, the output needs to de-energize.

Can anyone send some light with this???

Thanks in advance.
I have a project using RSL500 using processor 1200C in which I need to keep an output energized anytime the PLC controller is active, on line and functioning properly. In case of controller failure or power outage, the output needs to de-energize.

Can anyone send some light with this???

Thanks in advance.

Like this? just put it in lad2, or am I reading your Q wrong

I use Direct Soft with stage programming and many jump instructions and no sub-routines.
I find it very simple to follow and debug.
Could jumping around stages be considered to be similar to using sub-routines?

Jumping around Stages is the same as using SKIP or JUMP or GOTO.

If you have to find a similarity between Subroutines and something in Stage Programming, it would be the fact that a particular Stage Module is active and doing something.

If not active, then that would be like not calling a subroutine.

And by the way, if you look at the basic concept behind Stage Programming, you should be able to see that the Stage Programming model can be developed in Ladder, in any PLC.

Likewise, the Subroutine Concept can be developed in Ladder, in any PLC, without creating or calling a single Subroutine!