Screen jumps and lost commands

[yyh2]

Hey,

When I order a "screen jump" through the ladder, some commands/nets that are before the jump might not get executed.
specifically P type contacts, right now its an HMI button being pressed.
I'm working around it for some time now but it's starting to get really annoying.
why is it happening?
I mean... I get that the PLC is "Busy" loading the screen, but the command is not just delayed, which is ok for me.
rather… its lost. it's not executing. The PLC is skipping it (i verified it a few times to make sure, the net simply isn’t "read").

Any explanations and workarounds will be greatly appreciated.
Yam

(SM43-J-RA22)

[Joe Tauser]

Can you upload your program?

Joe T.

[DanT]

Hi;

    If you have Subroutines linked to the Screens, then these will stop running when you change to another screen.

  Subroutines only run when called.  ( Oline mode  can fool you into thinking they are running beacuse of the Red Power Line.   Add an  INC  MI or XI  to the power rail   in Net 1  and it will couunt when the subroutine is active)

 

DanT

[Gabriel Franco]

I´m not sure what you mean.

As a reference, I use this method.

[yyh2]

I think I figured at least some of it out.
I was calling the jump from the ladder and the "links & jumps" tab in the same time, by the same operand.
its seems that this tab takes precedence over the ladder execution (Bug ?).
it fixed the current problem.
but this thing happened to me so many times lately, that i suspect maybe its not the only reason (I doubt I did this double call every time , I mean…I do have a long rap sheet of stupid programming , but come on…)

Joe,
The project is a commercial product so I will get in trouble posting it here, I can give the relevant screenshots.
I've attached an example of it.
the P contact "MB83" is linked to an HMI button that is changing the screen to the next step.
when you press it I want the program to:
1. Load time to a timer (net 10).
2. Read the parameters for the next step (net 11).
3. Copy a vector (program name to main display, net 12).
4. And only then load the next screen (net 13).

Dan T,
no I don’t use conditional subroutine calls, I was listening very carefully to the forum experts.
its mentioned here like every 10 threads, and for good reason.
All the sub's are called every scan.

Thank you all for your help.

[Fernando Castro]

11 hours ago, yyh2 said:

Hey,

When I order a "screen jump" through the ladder, some commands/nets that are before the jump might not get executed.
specifically P type contacts, right now its an HMI button being pressed.
I'm working around it for some time now but it's starting to get really annoying.
why is it happening?
I mean... I get that the PLC is "Busy" loading the screen, but the command is not just delayed, which is ok for me.
rather… its lost. it's not executing. The PLC is skipping it (i verified it a few times to make sure, the net simply isn’t "read").

Any explanations and workarounds will be greatly appreciated.
Yam

(SM43-J-RA22)

kind of need to see your code but most likely you are doing something wrong, or missing some key concepts of ladder logic:

look for "Program Sequencing: Modules, Subroutines, Labels & Jumps" in the help file.

but here are some key concepts that may be where your issue is:

• ladder logic is sequential, but cyclical so the "position" of a transition contact to launch a screen shouldn't matter because if the transition contact occurs after the "load screen" function happens. it will be detected on the next cycle. Unless you had some entire logic that happens in-between (I.E. a Set, and its respective Reset happening immediately some rungs after the Set but before the thing that you want to trigger on transition).
• Sub routines needs to be on execution to change something (everything inside a sub routine won't change if it is not being executed, the operands maintain previous values).
• And I recommend trying to avoid executing sub routines inside HMI Links and Jumps. mainly because it is easy to forget that you had something in there but also because of the previous point (It is kind of buried and if you do a lot of export import you may miss something).

so, If you are using this to transition between screens: 

better change it for this other methodology:

 

 

And don't forget to place UI sub routine in your main function!

[yyh2]

Fernando, thank you for your replay.
you posted yours while my replay was pending.
Read it and you will see that i complay with your advice.

[Flex727]

6 hours ago, yyh2 said:

 

There is nothing wrong with this. It should work perfectly every time. In my nearly 15 years of full-time experience using VisiLogic I've never encountered a software bug such as you describe.

Also, I concur with @Fernando Castro - use ladder for HMI screen calls, not the Links & Jumps tab on the HMI screen. The primary purpose for that tab is for non-touchscreen PLC models that might need different physical buttons, or a specific subset of physical buttons, to make HMI screen calls from various specific screens.

[yyh2]

Hey Flex,

As I said, maybe it's just the links&jumps menu with the ladder call combined, we'll have to see in the future.
It happened to me like 8 times in the last software im working on, and i managed to work around it by changing the ladder order ( mixing nets 10-11-12 in the example).
The Visilogic version is 9.8.86 if it matters.

P.S
As you can observe I'm being very strict about separating command into numerous rungs instead of one huge rung( it will work most of the time, but not all).
its mainly due to your comments on the forum's history, emphasizing the importance every time.
Thanks 👍 

[Fernando Castro]

7 hours ago, yyh2 said:

I think I figured at least some of it out.
I was calling the jump from the ladder and the "links & jumps" tab in the same time, by the same operand.
its seems that this tab takes precedence over the ladder execution (Bug ?).
it fixed the current problem.

 I wouldn't say it is a bug but I've  been there 😅. Once I had a timer that was ticking twice as fast because I had a sub running while the screen was being displayed and also in the ladder logic.

 

7 hours ago, yyh2 said:

 

I don't know for sure if this is the case, but I feel like there is a Non 0 chance that the scan cycle is evaluating rung 13 when the transition is detected (I hope you are not using Idle or anything else that could delay the execution of the next cycle). I'll do everything in the same row one followed by the other and I'll use auxiliary contacts.

 

 

BTW, why are you using DW as timer preset? timer values can fit in ML. and you have more of those available, just a thought.

[Fernando Castro]

19 minutes ago, yyh2 said:

its mainly due to your comments on the forum's history, emphasizing the importance every time.

Its not like you can not do multiple functions in the same line its more like multiple "parallel" conditions in the same rung.

this Is not a good practice:

 

but It works. I think the issue is that the compiler may not execute the logic conditions in the same order as they are coded. technically those 3 has the same priority. and if your third "branch" depends on the status of an operand in the first branch it may not be updated since that is the same rung.

 

but left to right there is no doubt on which one is executed first.

 

[yyh2]

Fernando, Thank you for you detailed answer.

I'm referring to it as a "bug" because it loses the instruction/command.
in your situation you called it twice, it’s a different thing (frustrating non the less).
in my case, if I called the screen twice, no big deal, but the troublesome part is that it loses the neighboring net.
if it's only the double call, it's not an urgent fix anyway, just knowing that here and on the help files is OK (i still suspect though that the "call screen from the L&J menu + multiple P contacts" even without double call, is a scenario the system dislikes). 

Your ladder suggestion -
your solution for a more predictable sequence is a good idea to keep in mind.
in an absence of a solution I would definitely use it, but if we can learn how to avoid it, its better.
First of all since I wrote the entire program this way 😁
And second, because simpler logic with less set/reset coils as can be, is always my preferred way (a programming sixed sense that was reinforced by Joe Tauser's "Bit Banging" speech way back in the forum), if I can only work with the P contacts and trust them, it's the simplest solution.

DW as a timer  -
I have 4 program times and ML 1,2,3,4 were already used, so I assigned them DW 1,2,3,4 for clarity, no special cause, no other DW were used in the program.


Multiple commands in a rung  -
the argument against it was that it can compile not exactly the way you planned.
there is a saying here that "Visilogic don’t charge you by the number of  rungs", so split long rungs into simpler ones.

I do have some of them with 6 commands in a row, but they are "simpler" commands.
parts of the idea for separating them was to diagnose whether "messy" compiling was the  reason for missing the net.
It didn’t even occur to me to try parallel stuff.

[Fernando Castro]

2 hours ago, yyh2 said:

Fernando, Thank you for you detailed answer.

I'm referring to it as a "bug" because it loses the instruction/command.
in your situation you called it twice, it’s a different thing (frustrating non the less).
in my case, if I called the screen twice, no big deal, but the troublesome part is that it loses the neighboring net.
if it's only the double call, it's not an urgent fix anyway, just knowing that here and on the help files is OK (i still suspect though that the "call screen from the L&J menu + multiple P contacts" even without double call, is a scenario the system dislikes). 

Your ladder suggestion -
your solution for a more predictable sequence is a good idea to keep in mind.
in an absence of a solution I would definitely use it, but if we can learn how to avoid it, its better.
First of all since I wrote the entire program this way 😁
And second, because simpler logic with less set/reset coils as can be, is always my preferred way (a programming sixed sense that was reinforced by Joe Tauser's "Bit Banging" speech way back in the forum), if I can only work with the P contacts and trust them, it's the simplest solution.

DW as a timer  -
I have 4 program times and ML 1,2,3,4 were already used, so I assigned them DW 1,2,3,4 for clarity, no special cause, no other DW were used in the program.


Multiple commands in a rung  -
the argument against it was that it can compile not exactly the way you planned.
there is a saying here that "Visilogic don’t charge you by the number of  rungs", so split long rungs into simpler ones.

I do have some of them with 6 commands in a row, but they are "simpler" commands.
parts of the idea for separating them was to diagnose whether "messy" compiling was the  reason for missing the net.
It didn’t even occur to me to try parallel stuff.

I get what you are saying but even if each rung takes a given number of ms to be executed, if you use same positive transition in multiple rungss followed one by another you could trigger anyone of those conditions first then in the next cycle the one the previous rung. I'mnot saying that is 100% the case but having all those functions in the same row guarantees which one is executed first, you could also do it all on the first one and remove that auxiliar MB , I just dont like to add more functions after a coil or set/reset (on most ladder logic programs that is usually the end of the rung). However the auxiliar contact also guarantees the completion of the functions before allowing it to be triggered again. 

In my experience on ladder logic you should not assume that conditions will be triggered in the order of the rungs, It is like an electric circuit and everythingis happening at the same time, you need to use logic conditions to force the order if the order is relevant to the specific task you are trying to accomplish.

That's how I do my logic.

[Flex727]

10 hours ago, Fernando Castro said:

In my experience on ladder logic you should not assume that conditions will be triggered in the order of the rungs,

I think you absolutely can assume that. The PLC executes each ladder rung fully before moving to the next rung. This is one of the basic principles of ladder logic and fundamentally why you shouldn't have multiple parallel logic threads in a single rung.

One thing I frequently do is combine multiple, very simple, related, but not dependent logic threads using SB 1. Something like this:

Here I have 6 related items that have no mutual dependency that are very simple. Combining them this way makes for much easier to read code and simplifies comment documentation. Yes, the logic and code would work without the SB 1, but I think good programming practice should be carried out universally.

 

10 hours ago, Fernando Castro said:

It is like an electric circuit and everythingis happening at the same time,

This is true for physical outputs since they are not physically activated until the entire scan is completed.

 

13 hours ago, yyh2 said:

I have 4 program times and ML 1,2,3,4 were already used, so I assigned them DW 1,2,3,4 for clarity

Addressing in a meaningful way is good programming practice. In this instance, I would use ML 11, 12, 13, 14 or ML 101, 102, 103, 104. But, as I always also say - the PLC doesn't care.

[Fernando Castro]

29 minutes ago, Flex727 said:

I think you absolutely can assume that. The PLC executes each ladder rung fully before moving to the next rung. This is one of the basic principles of ladder logic and fundamentally why you shouldn't have multiple parallel logic threads in a single rung.

yes, that is correct. but my argument was that there was small chance that you trigger the bit while the scan was evaluating rung 13, then on the next cycle it would evaluate 10, then 11, then 12.

however, I tried to prove this theory using some jumps and labels trying to force the routine to end immediately after first occurrence of transition bit like this:

 

 

But seems that you are correct, my first assumption was wrong (the chance of executing rungs in this order 13,10,11,12 instead of 10,11,12,13).

 

 

[Flex727]

15 minutes ago, Fernando Castro said:

yes, that is correct. but my argument was that there was small chance that you trigger the bit while the scan was evaluating rung 13, then on the next cycle it would evaluate 10, then 11, then 12.

however, I tried to prove this theory using some jumps and labels trying to force the routine to end immediately after first occurrence of transition bit like this:

I was talking off the top of my head, but you actually experimentally determined the facts. I'm impressed.