RSLogix , Jump to Subroutine instruction

Hi folks,

I have got a logic prob I haven't been able to solve by myself so I wanted to ask you...

Does it exist any way to set a bit up to true for when a subroutine ends its execution?

I think this question should be more easily understood after seeing the attached piece of code I post here.

Thanks once again,

Ok first I really dont like conditional jumps unless REALLY necessary and very few times is it REALLY necessary. In addition I cant stand latches. Both situations cause more problems than they usually solve. Of course there are exceptions.

With those disclaimers and just taking your answer at face value, why not just branch around the xic and the jsr with an xio also addressed to 'a' and an OTU addressed to 'c'? If you need 'd' to be evaluated also, then add it in the branch also. Make sense?

So why not just remove 'a' as a condition to do the JSR and add it as a condition in the first rung in 'other'? Also maybe use a seal in circuit and get rid of the latches unless you need the condition to be preserved during a powerdown or change to program mode.

keeping the plc program simple = functionality

Russell

Thanks Rusell,

First of all I must say that I agree you about the use of latching/unlatching. Other programmers, the "Seniors" in the same company I work for, have already warned me about the disadvantages of using the latch/unlatch as rule of thumb, but the fact is that just after having experienced some reverses caused by "destructive bits" (OTE's not setting to true when they should do it, and things like that...) I have decided to bet for the latching/unlatching strategy by now.

About the JSR : I'm trying to keep my routines the more well-arranged possible. This means, I'm using the JSR's for toggling between several control ways of a same process. Every "control way" is associated to a routine and so forth , there must be a way to toggle the controlled execution for them. That's why I'm using the conditional jumps to subroutines.
I upload the code again with the changes you have proposed. Now it works fine!

I don’t like latches either. Instead of using a latch use a standard OTE and then to make sure it is active use an XIC with the address of the OTE.

There are a couple ways to get the latch functionality without using the OTL command.

Having a bunch of latch instructions in a program makes it difficult to troubleshoot quickly.

Here is a simpler example that I came up with.

Ok, now I feel like I have done you a disservice. Yes what I said will work, but please don’t do it that way! I answered you to help you understand how the logic you had worked. Check out kittydog's program. The JSR is still used to break the program into modules, but it scans continuously. Use the JSR to make your program modular. If nothing else, your simple example shows how easy it is to get confused and for something to go wrong in the program. I have stressed on this board and others about keeping it simple for your poor guy that will have to troubleshoot it. I should have added that it also needs to be simple because your brain may not be at 100% at 3am in the morning surrounded by the plant manager and other supervisors wondering why the system is down (ha, like the plant manager is going to be there at 3am). Please check out kittydog's program.



Also you mentioned something that made me pause.

the fact is that just after having experienced some reverses caused by "destructive bits" (OTE's not setting to true when they should do it, and things like that...) I have decided to bet for the latching/unlatching strategy by now.

Click to expand...

Ouch. Then there is a bigger underlying problem that you need to address before loading your program up with a bunch of latches which will make your program a troubleshooting nightmare. I think you would do well to check out Ron Beaufort's videos to better understand how the AB and RSLogix works. They are on youtube and on our site. We also have additional videos on our site that may help you get past your problem with OTE's. Additionally, you may want to post those programs and get a better understanding of why things didnt work as you expected.

Hope all this helps. I do not want to see you get started down the wrong direction.

Russell

Thank you both Kittydog42 and PLCMentor for your very valuable advices. Unfortunately I won't have the time enough to implement them as tonight I must hurry up with the programming (tomorrow our supervisor wants to see real results after all these last weeks that I've devoted to the development of this my first project)...

But in general lines the way your tips point out is clearly agreeable : keeping the plc program simple = functionality

So why to choose a modular programming line? Mainly because I'm specialized in a very concrete field of automation : water and sewage treatment plants...and all of them are quite alike. We have a general algorithm which works fine with the different kind of PLC's we work with, but still I'd like to customize it, or somehow "optimize" it over the basis of the particular strong points that each PLC offers, (let's say Siemens, AB...). For instance, when performing this project I've got to learn a lot about the complex wide range of possibilities (and therefore flexibility) which the PIDE block instructions does offer.

As novice programmer I'd say I'm going through a beginning stage of discovering, analyzing, understanding of new devices I hadn't ever worked before with ( I just did a quick vocational traning on Siemens PLC's, a year ago, and now I've straighly jumped to AB, and I feel quite comfortable with it)

Anyway, another topic..It's been really frustrating to me during this initial testing stage to find constanly problems because of that annoying "Warning: Duplicate Destructive Bit Reference Detected"...so that's when I moved to the latch/unlatching ...This was because of a deficient knowledge on some basic concepts. I've been dragging untill now those "small" mistakes which finally have turned into a big snow ball "in the going down" and , right now, I run out of time to change my initial program into a decent piece of code. It's a pity but with everything which I've got to learn I hope to make a more professional work for my next project. Being a self-learner on PLC's is the hard way, no doubt of it.

Anyway, this big speech arrives at its end ) ...have to go on with the programming again. A hard working night is waiting for me!

Thanks again to both!

Anyway, another topic..It's been really frustrating to me during this initial testing stage to find constanly problems because of that annoying "Warning: Duplicate Destructive Bit Reference Detected"...so that's when I moved to the latch/unlatching ...This was because of a deficient knowledge on some basic concepts. I've been dragging untill now those "small" mistakes which finally have turned into a big snow ball "in the going down" and , right now, I run out of time to change my initial program into a decent piece of code. It's a pity but with everything which I've got to learn I hope to make a more professional work for my next project. Being a self-learner on PLC's is the hard way, no doubt of it.

Click to expand...

The reason that you are getting this message is because you reference a coil in more than one location. You need to optimize your code to only activate a coil in only one place. An easy way to do this is to use multiple XIO and XIC bits in parallel on the single coil. The software will let you do it, but it will be confusing to you when it looks like it should activate in one place, yet it doesn't due to the multiple locations.

The reason that you are getting this message is because you reference a coil in more than one location. You need to optimize your code to only activate a coil in only one place. An easy way to do this is to use multiple XIO and XIC bits in parallel on the single coil. The software will let you do it, but it will be confusing to you when it looks like it should activate in one place, yet it doesn't due to the multiple locations. Today 10:09 PM

Click to expand...

I've done that way and now my code is finally clean up. But it has became less intuitive. I try to explain this: I had broken the program into several subroutines, assigning each to the several working modes, so those coils were being repeated in each routine, but, of course, being energized under different conditions which were locked up among them: the same coil couldn't ever be executed twice, in two subroutines at a same time becase even the execution of those subroutines couldn't happen simultaneously ( I had locked them up too by using of the JSR instruction, setting it conditionally, as I explained in the beginning of this thread).

It was a very well-arranged system, BUT, in order to avoid the presence of duplicated destructive bits, I have had to take all the coils out to a new subroutine,specificlly for assigning it to them.

just another doubt

Hi folks,

I come again to you with a very newbie question: It has happened that whilst online with the PLC I've saved the program and its associated state for the variables in it, so their values have been stored, uploaded to my code. Is this action reversible? any way to restore the original "virgin" state for my project tags?

Ruben:
I was just wondering if you have ever using an event task, this way inside the task you can use a latch or a pointer, so you know when you task have finished what it is supposed to do.
I did it in the past when designing a flying cutoff, i needed to know when my shear was all the way down, and this happens inside the event task.

saludos,

william

Event task

Hola William,

No, I hadn't ever heard of the event tasks but seems quite interesting...As soon as I have the time for it I will go into the RSLogix online documentation and get acquainted about its use. Thanks for the tip!

thanks alot