Subroutines

[Arberhaziri]

I'm struggling with subroutines and understanding the exact way how they works. 
I'm willing to controll some outputs with  buttons but only when that display is activated . I'm using "is displayed operand " which calls a subroutine where the code for controlling output is .
In that subroutine I turn on an Output with set coil when one button in that display is activated , but what happens if I go out from that display ? I'm not sure but I think the  OUTPUT will be low , but what happens with set coil ? Is it going to be  "reset" ? , or is it going to remain "SET"?
Also I want to ask about "Choose "On unload" Subroutine" , how can we use it ?

[Flex727]

7 hours ago, Arberhaziri said:

but what happens if I go out from that display ? I'm not sure but I think the  OUTPUT will be low , but what happens with set coil ? Is it going to be  "reset" ? , or is it going to remain "SET"?

What you are asking is why it is bad programming practice to have a subroutine called conditionally. Write your code such that every subroutine is called on every scan.

To answer your question, any coil will remain in the last state it was in the last time it was executed.

It sounds like you are WAY over-complicating your program. Unless there is a lot more going on than what you describe, you probably don't need a subroutine at all. Also, why do you need the "is displayed" operand for this? If the HMI screen is not being displayed, then you can't press the button. Why do you feel you need the extra check to make sure the screen is being displayed?

[Arberhaziri]

12 minutes ago, Flex727 said:

 

It sounds like you are WAY over-complicating your program. Unless there is a lot more going on than what you describe, you probably don't need a subroutine at all. Also, why do you need the "is displayed" operand for this? If the HMI screen is not being displayed, then you can't press the button. Why do you feel you need the extra check to make sure the screen is being displayed?

In fact my program is a bit more complicated , the description was for understanding how subroutine work. 
The reason I need subroutine in this case is that I have a bunch of code which  turns some Outputs ON and OFF automatically depending  from conditions and I want the code to be separated in groups  . Those Outputs can be controlled manually in another display .So  I want to block the possibility for those outputs to be controlled manually while they are being controlled automatically . 
And yes you are right , sometimes I  complicate things as I am new in programming 
Also is it better to create a subroutine and to call that bunch of code only when needed (in this case the code to be read only when I turn AUTOMATIC MODE  ON) , or the code to be read all the time ? , is it better not to let microcontroller read unnecessarily?

[Flex727]

If you want a button to be inactive during certain times, use the "Disable mode" function, but your solution doesn't solve the problem you're stating. Since you can only push the button when you're on a certain screen and the only check you're performing is to check to see if you are on that screen, then you aren't accomplishing anything.

[Flex727]

12 minutes ago, Arberhaziri said:

Also is it better to create a subroutine and to call that bunch of code only when needed (in this case the code to be read only when I turn AUTOMATIC MODE  ON) , or the code to be read all the time ? , is it better not to let microcontroller read unnecessarily?

The PLC doesn't care whether the code runs or not. The poor programming practice is due to the fact that conditional subroutines can often execute in ways you don't expect (for instance, coils being left in limbo). There is no reason to do it that way.

Ladder logic is not the same as regular computer programming and should not be treated that way. Except for very unusual circumstances, the only purpose for subroutines (in ladder logic) is to break your code up into manageable chunks. Every line (ladder rung) in the entire program should be executed on every scan. This avoids unexpected behavior and ensures that you don't trigger the Watchdog Timer.

Bear in mind, I am giving my opinion on best programming practice. Other experienced programmers may have a slightly different opinion and there is no absolute right or wrong here. I am providing the benefit of my experience and skill which you may accept or ignore.

[Joe Tauser]

18 minutes ago, Flex727 said:

coils being left in limbo

This is exactly what happens and the biggest mistake beginners make.  They assume that if the subroutine isn't being called anymore that any coils and/or timers in that subroutine get reset.

They do NOT.  They are left in whatever state they were in the last time the subroutine is called.

Every one of my programs contains a subroutine called "Outputs", which is called continuously.  All my outputs are listed in numerical order which makes them easy to find.  Code for each output from other parts of the program comes together here - for example:

 

Also, if you're new, stay away from Display controlled subroutines.  Unless you've got a whole bunch of things that have to happen specific to a display, use the "Display Active" bit along with rising an falling edge transitional contacts is an always-called subroutine called "Display Controls" (also one I always have).   Separate the logic for each display with network comments.

The point of all this is the more subroutines you have, the more confusing your code will be, even to you.  Try thinking about looking at this code six months from now and remembering what you did.

Joe T.

[Flex727]

9 hours ago, Arberhaziri said:

Also I want to ask about "Choose "On unload" Subroutine" , how can we use it ?

I neglected to answer this question. This option does create a conditional subroutine which is why I never use it. There may be a specific need for it that I haven't encountered which is the reason Unitronics included it. I rarely use any of the "display controls" and prefer to create all my HMI calls in ladder. The only exception to that would be PLCs with physical buttons that need to be associated with different screens in different ways.

I just now see Joe's response, which I totally agree with. With his single subroutine for Outputs (and Inputs, perhaps in a different subroutine) he is creating I/O "buffering. This is excellent programming practice which allows for easy code revision, easier testing, and reduced confusion at a later date.

[Arberhaziri]

Thank you very much from both of you . 
I created a great connection from all you said . 
In my case  I think the best way to stop the user to get in display where the  outputs are controlled manually is to "disable " that button which opens that display . The outputs are controlled automatically  in another display and unless there is an error which resets the bit (I use a bit called "START AUTO" to keep the process  controlled automatically), it remains to control the process . So I can use that bit (START AUTO) to "disable" the button that opens the display to control my outputs manually.

It means that I do not want the user to open that display while "START AUTO" bit is ON.
 

[Flex727]

3 hours ago, Arberhaziri said:

I think the best way to stop the user to get in display where the  outputs are controlled manually is to "disable " that button which opens that display . 

Sounds right to me!

[Ausman]

Joe & Flex have given great advice here.  I would like to add some comments, and reference particular help files.

The most sophisticated plc I use is the 130 series.  I have never had a need for touch screens, I only have knowledge of manual keypads.  Using subs linked to screens for manual keypads is fraught with hazard, due to the fact that screens take a number of scans to load.  It is also very easy to get an unexpected action because a button push might over-run into the next screen.  There is much in the Help files about this sort of issue, but it is scattered around a bit.  I strongly suggest that anyone new to Vision spends some time looking carefully at:

How Keypad Entry Variables Work

Program Sequencing: Modules, Subroutines, Labels & Jumps.  In particular the  image box near the bottom that is headed "Runs HMI Program" and the notes within.

Take really good note of how the use of certain system bits lets you control things much better.

On the comment "disable " that button which opens that display, that's the best way!   There is one proviso though, the ONLY time I might have such a thing in a program that is accessible to the user, is if the machine may need careful manual control in an Emergency Stop situation.   It is all well and good for a machine to have an emergency stop, but it's NO good if someone is trapped by the "Stop" situation that could be easily cured by very careful manual control of part of the machine that would otherwise be very difficult to do.  Humans will always find a way of getting around the most stringent safety systems, often with bad (for the human) results.

cheers, Aus

[TozoM8]

My practice is that I run all the subroutines all the time. When the automatic is running it disables the button that could call the screen that has all the manual buttons. When I am on the manual buttons screen and any of the manual controls are on it disables the back button from the manual screen.