I am programming a subroutine in Directsoft 5. The subroutine activates an output. When exiting the subroutine, the output sometimes remains on. It depends on when you press the switch to turn the output on or off, but this is in another subroutine. So if I turn off the switch and don't execute the subroutine, the output stays on. I have tried the RSTI command in Directsoft 5 but to no avail. Can anyone help point me in the right direction? Thank you.
Eng-Tips is the largest engineering community on the Internet
Intelligent Work Forums for Engineering Professionals
Directsoft 5 Subroutine
- Thread starter AraS.
- Start date
It's all about scan order. I'm not familiar with that system, but you just have to make sure the rung is evaluated with the condition you want to capture before the subroutine exits.
Brad Waybright
The more you know, the more you know you don't know.
Brad Waybright
The more you know, the more you know you don't know.
AraS; You do realize that one of the most important point about Automation Direct is their free and very helpful technical support?
Keith Cress
kcress -
Keith Cress
kcress -
Hysteresis1
Agricultural
A coil will only turn on or off when its rung is run in the program.
If a coil only appears in a specific subroutine and you stop running that subroutine, the rung will not be scanned and the coil will not turn on or off.
If you are simply using a subroutine to organize your program, then it is best practice NOT to put any contacts in the rung that calls the subroutine from your main program. That way your coils will always turn on and off since the subroutine will always run every scan.
If you want to have logic controlling whether your subroutine runs, you need to have a set of mutually excusive subroutines than cover every logical state of the contacts controlling whether or not the subroutines are being run. Each subroutine then needs to have logic controlling the same coils. This ensures that one of the subroutines will always be run, and the coils will always have code controlling them each scan. eg. subroutine 1 runs when a contact X1 is true, subroutine 2 runs when contact X1 is false - each subroutine contains different code controlling for turning on and off coil Y1. In each case you will never be left with "hanging" coils stuck in the last state you left them in.
If a coil only appears in a specific subroutine and you stop running that subroutine, the rung will not be scanned and the coil will not turn on or off.
If you are simply using a subroutine to organize your program, then it is best practice NOT to put any contacts in the rung that calls the subroutine from your main program. That way your coils will always turn on and off since the subroutine will always run every scan.
If you want to have logic controlling whether your subroutine runs, you need to have a set of mutually excusive subroutines than cover every logical state of the contacts controlling whether or not the subroutines are being run. Each subroutine then needs to have logic controlling the same coils. This ensures that one of the subroutines will always be run, and the coils will always have code controlling them each scan. eg. subroutine 1 runs when a contact X1 is true, subroutine 2 runs when contact X1 is false - each subroutine contains different code controlling for turning on and off coil Y1. In each case you will never be left with "hanging" coils stuck in the last state you left them in.
Welcome to Eng-tips Hysteresis1.
Do you write a lot of PLC code?
Keith Cress
kcress -
Do you write a lot of PLC code?
Keith Cress
kcress -
Hysteresis1
Agricultural
Yes, a fair bit.
Is there a better way of handling AraS.'s issue than my suggestion?
Is there a better way of handling AraS.'s issue than my suggestion?
Not that I can see. If you're willing to put output statements in a subroutine then I'd agree that the subroutine needs to run every scan.
I always stick all my outputs at the very end after bold RED markings [!]---OUTPUT STATEMENTS---[/!].
Of course you can have conditionals that deal directly with output statements that could trip you up badly if they were sequestered out in subroutines too.
Just really have to be aware. It took me a while to get down PLC scan logic after decades of embedded controller C code. Now as I write ladder logic little spasms of 'hey this line is after/before that other line so check that!' pop into my awareness.
Keith Cress
kcress -
I always stick all my outputs at the very end after bold RED markings [!]---OUTPUT STATEMENTS---[/!].
Of course you can have conditionals that deal directly with output statements that could trip you up badly if they were sequestered out in subroutines too.
Just really have to be aware. It took me a while to get down PLC scan logic after decades of embedded controller C code. Now as I write ladder logic little spasms of 'hey this line is after/before that other line so check that!' pop into my awareness.
Keith Cress
kcress -
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question