Can i have the same coil adress in 2 different subroutine while using just 1. RS5000

[Jeff23spl]

With RS5000 and a Clogix, I would like to know if i can work with same coils adresse on 2 different subroutine and just call one at the time?
I mean subroutines from the main program and calling one of the 2 with a no/nc contact to switch.
Will the ''not called'' routine can still affect the status of the coils output in it or the coils only respond to the called logic ?

It would be easy to test this but i don't have the hardware at the moment.

The purpose of doing it would be to live update a huge portion of a program with limited time to download in the plc. And then, being able to revert back to old logic quickly without having to shutdown again.
To make it even more fun, all of this would have to happen thru a remote connection.
thanks

 

[Helliana]

You can use the same coil output as many times as you want, its just the last one to be scanned will be the output. It may not be best practice, and you may get a warning that an OTE with the same address was used more than once, but there is nothing to prevent you from doing it.

 

[rQx]

... but there is nothing to prevent you from doing it.

Other then bad practice?

 

[OkiePC]

For the purpose you describe, I see nothing wrong with this. Once your new program is fully tested I assume you will delete the old one and the rung condition calling the new one. You can actually do all of this without a program download. You can create a new program, paste the new logic into it, and edit online the JSR for the old and new programs...all without interrupting the process. This is a procedure I have followed many times in the past with PLC-5, SLC and Logix5000 controllers.

 

[I_Automation]

I have PLC's (SLC & CLX) programmed for Christmas, Halloween and other lights and displays.

Since the same outlets on the house are used for all of them I have routines that are called for each holiday. Each output used for more than one holiday is only controlled when that holidays lights are active. So, with Halloween coming soon (and the lights starting to go up this weekend) the routine controlling the same output for Christmas is not being scanned and does not affect the output for Halloween.

As far as on a machine I have seen where the Auto, Manual and Service mode controls for a single hoist were programmed in 3 separate routines, each one calling the hoist VFD and brake and monitoring the inputs for On Station, VFD fault, Motor Overload, Travel Limit, etc. independently.

 

[Steve Bailey]

Make sure you have a plan in place for the permanent modification, assuming your change works as expected. All too often quick fixes like you describe end up being permanent. Then your successor has to reverse engineer your code when troubleshooting something a few years from now.

 

[Jeff23spl]

thanks all
Unfortunately, it may end up as a long time temporary measure but it will be well documented and advertised at the calling rung and at top of both routine for any further change....

 

[Jeff23spl]

For the purpose you describe, I see nothing wrong with this. Once your new program is fully tested I assume you will delete the old one and the rung condition calling the new one. You can actually do all of this without a program download. You can create a new program, paste the new logic into it, and edit online the JSR for the old and new programs...all without interrupting the process. This is a procedure I have followed many times in the past with PLC-5, SLC and Logix5000 controllers.

I expect i have no choice to stop for downloading, i need to update hardware also...
But i will keep note that i can add a new file while online editing....i though it would be limited to change just 1 rung at the time...

 

[daba]

You most certainly can have multiple OTEs of the same destination bit address.

The only time this becomes an issue is about whether the multiple instances of the OTEs are actually scanned, so having multiple JSRs, each driving the same OTEs, and providing those JSRs are mutually exclusive, would be OK.

But, IMHO, this is ugly programming, it is so much better to program internal "slave" bits, resolving those with final "OR" logic to drive output bits.

 

[AustralIan]

it is so much better to program internal "slave" bits, resolving those with final "OR" logic to drive output bits.

Output := (Route1_Selected AND Route1_Output) OR (Route2_Selected AND Route2_Output);

 

[parky]

The only problem in using slave bits is that if the slave bit is turned on in the sub routine and the JSR is set to false the slave bit will stay on. a way around that is to use a reset of the bits before the call to the sub, however, if the same bit is used a change in the jump to another sub will override it. The only problem here is if none of the JSR's are active the bit could remain on.

 

[rQx]

I always enable subroutines with a bool, no jumping. Problem solved I think

 

[daba]

The only problem in using slave bits is that if the slave bit is turned on in the sub routine and the JSR is set to false the slave bit will stay on. a way around that is to use a reset of the bits before the call to the sub, however, if the same bit is used a change in the jump to another sub will override it. The only problem here is if none of the JSR's are active the bit could remain on.

The issues are easily resolved by changing the OTEs of slave bits to OTLs, and adding a single OTU of each slave bit at the start of the main program, main routine. Now it won't matter if a SBR gets turned "off".

And if you use bits of a DINT tag as your slaves, you get a group of 32 slave bits than can be reset with a single CLR instruction, instead of 32 individual OTUs.

 

[parky]

Yes I agree Dabba, It's fine using multiple coils providing you make sure you turn them off if a call to a function/sub is false (unless of course you need a bit to stay on). I have done something similar but it was using pointers to select a manual control of pumps/motors, only having limited functionality on a HMI meant using two keys to toggle up/down the valve/motor list so that it could be selected to manual & controlled from the HMI, this required any bits not selected to be set to false, simple really, just set the bits to false before the call to the function or as you said write 0 to a word(s).