Duplicate destructive bit RS5000, jsr switching?

Hi all,

Is anything wrong with the hypothetical logic attached?

We make a machines that can have 1 of 2 air valve stacks. I would like the person who initially tests the machine to turn on a bit on a configuration screen that decides whether it will run the valve stack new or valve stack old routine.
Valve1 and Valve 2 are aliased to real world solenoids. Switch1, switch2, and Pushbutton1 are aliased to inputs as well.
Seems to work but am I missing something? I get that it could be possible to run the incorrect valve stack program and possibly turn on the valve under the incorrect conditions but it can't physically harm the machine or operator.

Jimbob

I'd be more inclined to write your logic to make use of that config bit in each affected rung and leave it all in one unconditional routine, especially if that example in your picture is all there is that's different.

Combine the logic into one subroutine and unconditionally call it.

OK, being the kind of guy I am, I will answer the question directly as asked.

No, there is nothing functionally wrong with the logic as it is presented. Both outputs are explicitly controlled in both routines and the routines are mutually exclusive. As a result the outputs can't remain in an indeterminate state. Granted, it may be confusing to some but there is nothing functionally wrong with it.

Keith

JSR switching

Thanks for all the replies. I understand this may not be a good way to go about programming something like this, but it is interesting knowing it does work as intended.

I do see a problem,

when you call a subroutine, it executes that subroutine. turn on an output, it will turn on until its told to turn off.
if the output #1 is on in one subroutine, and you switch to the other subroutine, output #1 is still on, you have bypassed the logic to turn it off.
and then switching back to that routine may cause unexpected results twhen the program scans that subroutine again.

maybe I am missing something, I don't work with logix 5000 that much.
if I am wrong, someone please correct me.

james

James, in the general sense you are correct. When a subroutine is no longer scanned the information inside of it is left in the state it was in on the last scan of the subroutine unless acted on by another piece of code.

However, in this specific case there is no problem. One of the two subroutines has to run since their call is conditioned by complementary states of the same bit. One of them has to be running. In addition, both subroutines directly control the same "outputs" so the "outputs" are never out of direct control of some logic.

So generally you are correct but in this specific case that is handled.

Keith

Still a bad idea

Agreed, Keith.

Of course, if someone comes along later, and adds something (a valve, a timer) to one routine but not the other, then James' complaint is valid.

This is why this is such bad practice. It'll work for the guy who wrote and delivered it, but will not withstand the test of time.

It's more of a GUIDELINE....

Rockwell gives only a warning for duplicate destructive tags, because some programmers (for whatever reason) feel a need to do what you've demonstrated.

I once ran into this code for a one-button flip-flop:

   PB      CHANGE   LIGHT     LIGHT

---| |---+---|/|-----|/|---+---(L)

         |                 |

         |                 |  CHANGE

         |                 +---( )

         |

         |  CHANGE  LIGHT     LIGHT

         +---|/|-----| |---+---(U)

         |                 |

         |                 |  CHANGE

         |                 +---( )

         |

         |                    CHANGE

         +---------------------( )

The duplicate coils of "CHANGE" allowed the code to only be executed on the leading edge of the press of the PB, and prevent the light from being changed on a subsequent branch after it had been acted on.

The software will complain about it, but the PLC will execute it just fine.

kamenges,

thank you for pointing this out.
I was pointing out a general case and to help others from possibly getting in a bad habit / bad programming practice.
as pointed out, this works when the system is delivered, but will it stand all the future program modifications made by others.
james

I genuinely do not like the verification to throw up any Errors (obviously), or Warnings. 0, 0 is what I want to see.

Having said that, working on a rail maintenance depot control system I had to set up "virtual trains" to test the various routes and wheel switch counting logic (yes, very old-fashioned, but it was built about 14 years ago....).

I used an Add-On instruction that would cater for up to 12 wheel-switches, but not all routes had 12 on the route, so I used "WS_Dummy" BOOL as a placeholder where there wasn't a physical wheel switch. No need to go into any more detail, but using and re-using WS_Dummy as the output parameters of multiple AOI's causes "Duplicate Destructive Bit" warnings, all 78 of them.

I don't want to remove the simulation routine, in case I have to take it back to simulation in the future, so it is just defeated from execution. The cure for the warnings would be to change WS_Dummy from a single BOOL to a BOOL Array tag, and just keep enumerating the next bit in the Add-On parameters, but that would be a PITA to change now ....

Had I written the original software I would have built simulation into it from day 1, but here I had to bolt it on the side.

Knowledge is power and understanding how things work is powerful.

I think it is ALWAYS important to clearly and definitely separate what can be done from what should be done in every post we make. If we mix those two together all it will do is confuse someone.

Specifically in this example, to say it CAN'T be done the way it is done because, for all the indicated reasons, it SHOULDN'T be done runs the risk of making the larger question of how data is updated by a subroutine call very confusing.

I am in full agreement with the idea that just because something can be done doesn't mean it should be done. I also agree that we should all be willing to speak up about methods and structures that might be a bad idea for any number of reasons. But I also believe we should all be ready to truthfully and accurately answer any question that is asked in a purely technical manner and be VERY clear about what is an answer to the question asked and what is a personal opinion.

Keith