Timers inside subroutine

[cirocastro]

Hi everyone!

 

Need a little enlightenment in here... my project works fine if i write it in the "main routine," but then when i try to organize it and break into subroutines it stops working, so i am doing one step at a time to see where i'm messing thing up.

What i found out is the following:

if i am in the "main routine" and have T0 as a 5s timer, connected to an input, it behaves as expected:

input on -> timer decreases from 5s  -> timer reaches 0 -> T0 value=1

after it finishes counting:

T0 value=1-> input off, then on again-> T0=0, current timer value resets to 5s-> timer decreases from 5s etc etc

if i open the input before countdown finishes:

input on-> timer decreases ->input off, then on again->current value resets to 5s and restarts countdown

 

But then, when i have my input calling a subroutine, and the subroutine having the same input connected to the same 5s timer, what happens is:

input on -> timer decreases from 5s  -> timer reaches 0 -> T0 value=1

after it finishes counting:

T0 value=1-> input off, then on again-> T0=1, current timer value DOES NOT resets to 5s-> timer gets stuck with T0=1

if i open the input before countdown finishes:

input on-> timer decreases ->input off, then on again->current value DOES NOT resets to 5s and countdown resumes from where it stopped before input was turned off

 

the return to main routine function is activated by the T0=1 condition, and the *&%#$#%@ part is that when it finishes counting and returns to main, and then my input calls the subroutine again, my timer is already set at 1, and the program bugs.

 

Is this expected? Am i doing something wrong? Do i have to work differently when using subroutines?

 

Hope someone can understand my issue description and can help me =P

 

 

Thanks!

 

 

 

 

[Flex727]

Do NOT do conditional subroutine calls. It is poor programming practice and often causes unexpected results.

[Joe Tauser]

The question of bits being left on and timers not resetting in subroutines comes up often.

Think like the PLC.  And understand the underlying Zen of a timer or bit instruction.

Here's the bottom line - a bit or a timer must be scanned one more time with a Logical FALSE statement in front if it in order to turn it back off.  This is true for most PLC brands.  The mistake beginners make that they have a hard time wrapping their head around is thinking the PLC still looks at the bits in the subroutine even though it's not being called.

If the the subroutine is not being called, everything in it is frozen in the state it was in when you left.  Which means bits are left on and timers are not reset.

As Flex says, conditional subroutine calls can be bad ju-ju.

 

 

Joe T.

 

 

[cirocastro]

Hi Joe and Flex!

 

Thanks a lot for sharing some of your knowledge!

 

I want the machine to do 3 operations, i thought of doing something like: if input 1, call subroutine A; if input 2, call subroutine B, etc etc.

In college we did something just like that, if HMI button 1 pressed, call this routine; if HMI button 2 pressed, call other subroutine... i thought it was a good way of keeping things organized

it didn't worked though, i wrote on my final report i needed more time to debug and the teacher let me go with that

So that's a bad idea then? 

 

So now i am thinking maybe subroutines should be used to make repetitive tasks easier to program, then?

 

Now regarding Joe's reply:

"a bit or a timer must be scanned one more time with a Logical FALSE statement in front if it in order to turn it back off"

and:

"If the the subroutine is not being called, everything in it is frozen in the state it was in when you left.  Which means bits are left on and timers are not reset. "

 

I am failing to see why my timer does not resets when the input toggles.

Once the subroutine is called, the program is scanned inside the subroutine only, right? Then it will do a scan with my input active and timer decreasing, then a scan with my input inactive and stop decreasing the timer, then a scan again with the input active again; isn't this enough to reset it?

 

Actually this is not really relevant to my application since i won't have timer conditions shifting so quickly, its just curiosity ?

 

Is there any good books, or something like it, where i can learn all this tricks without disturbing the most experienced ones? I had PLC classes both in high school and in college and these kind of stuff never was told me before...

 

thanks a lot again!

 

Regards,

 

 

 

 

 

 

 

 

[Flex727]

52 minutes ago, cirocastro said:

Once the subroutine is called, the program is scanned inside the subroutine only, right?

No, no, no! Ladder logic is not like other high level computer languages. In ladder logic, your code should be constructed such that every single ladder rung is executed (once!) on each PLC scan. Instead of thinking that pushing the button will execute a specific subroutine, think in terms of outputs. What do you want to have happen when the button is pressed? Write code for each of the things you want to have happen, taking care to have each Direct Coil only appear once in the program.

53 minutes ago, cirocastro said:

I am failing to see why my timer does not resets when the input toggles.

When the input toggles, your subroutine stops being called. Without the subroutine being called, the timer never sees the input toggle.

1 hour ago, cirocastro said:

So now i am thinking maybe subroutines should be used to make repetitive tasks easier to program, then?

Sometimes, yes. Mostly it's to break the code up into logical chunks that are easier to read and troubleshoot.

[Ausman]

I agree with everything Flex and Joe T are saying, but a further thing to be aware of (with any PLC) is that a simple change of position of a rung or element(s) up or down the ladder can have far reaching impacts on how the program works, due to the impact of something happening in one scan that affects something further down the ladder.

As Joe says, you always have to think like the PLC and work from top to bottom of the ladder, which happens each scan.  Treat them as the dumbest of dumb.  One of the things of good programming practice is being able to break a required result down to each individual step needed to actually achieve what is wanted.  For a human (most!...hmmm....many!...ok then...some of them!) this is simple. For a plc, it needs to know every single step along the way.  And if one of those steps is not in correct order, or gets missed, it won't work as expected.

My wife has great fun teaching kids about instructive texts, which we are pretty much talking about here.  She gets them to write on how to make toast and put jam on it, and then acts out the various submissions.  At first, they all end in a "hang" with everyone having an hilarious time.   Missing knives, plastic bag still on bread in toaster, entire loaf in toaster etc.  There's actually a LOT involved in making toast and jam!  PLCs and instructive texts pretty much go together, even if it is just in the virtual world of your brain.

cheers,

Aus

[Flex727]

14 hours ago, Ausman said:

My wife has great fun teaching kids about instructive texts, which we are pretty much talking about here.  She gets them to write on how to make toast and put jam on it, and then acts out the various submissions.  At first, they all end in a "hang" with everyone having an hilarious time.   Missing knives, plastic bag still on bread in toaster, entire loaf in toaster etc.  There's actually a LOT involved in making toast and jam!  PLCs and instructive texts pretty much go together, even if it is just in the virtual world of your brain.

I love this!

[Flex727]

22 hours ago, cirocastro said:

Is there any good books, or something like it, where i can learn all this tricks without disturbing the most experienced ones?

@cirocastro, check above under "Pages"/"Webinars" to see some great tutorials. Also, browse the Help file - you will learn a lot. @Cara Bereck Levy and others have put a lot of effort into the Help file and it is a great resource. There are also a lot of example programs that came with your VisiLogic installation. Review those to see how to do specific tasks. But most importantly, get a cheap PLC and start experimenting. There is no better way to learn than hands on trial and error.