Visilogic : XB Rising Edge failure (UPDATED)

[Sideway]

Hi everyone,

For sake of clarity, i decided to update this post, in a more compendious way, with a much simpler routine, going straight to the point.

I have summarized the problem within the subroutine attached to this post (version used : VisiLogic 9.4.0)

To describe it briefly :

This routines executes well the first time i go through it. However, if i go Scan by Scan (using the OnLine debug mode), a problem occurs when i loop through my routine twice : XB23 (which is effectively 'Reset' at the end of the subroutine), does turn ON if i press #8 on my PLC, but XB23 Rising edge does not occur.

However, if i go through my routine, reset my XB23 at the end of it, then i wait 1 scan cycle, then retry my routine, it works properly.

May you explain what is going on ?

Cheers,

Sideway.

 

 

 

TEST ROUTINE.vlp

[Isakovic]

Can't say much from your program. It seems when you press #8 on keypad your program increments MI18 to value 3 (net 1 to net 4). When you press #9 on keypad MI18 is incremented to 4 and XB23 resets.

On 2/4/2022 at 6:27 PM, Sideway said:

However, if i go through my routine, reset my XB23 at the end of it, then i wait 1 scan cycle, then retry my routine, it works properly.

You mean reset it manually? I'm not sure what is the exact problem. One scan cycle lag shouldn't be a problem for control by pressing buttons.

If this is a question about inner workings of transition contacts, if they can change state during the scan cycle or are only updated once per scan, I would also like to know.

[Sideway]

Hello Isakovic !

At first sight, the program "should" work as you said (this is what i thought as well) ! I mean, i created this easy routine just to demonstrate the issue i had.

And the issue, as you said again, is about how transition contacts are perceived from one scan cycle to another.

I added some SB press keys just to be able to simulate my issue manually, when running in DEBUG mode, one scan at a time.

When you do this, you may realize that the routine is working effectively only ONCE. When i go through another loop (i.e. when my MI goes back to 0 and XB resets), if i press "8" then the value 1 loads into MI but the XB rising edge is not seen and the program blocks.

 

[Isakovic]

Ok, I recreated the problem in V430.

- Set XB23 in first scan (I held F1 pressed and clicked once "Single Cycle"), reset in second scan (I held F2 and clicked once "Single Cycle" ) and it works normally. Wait one idle scan then repeat and it works normally again. If you don't wait one idle scan and set XB23 in third scan program doesn't recognize transition contact. If you use normal NO contact program works fine again.

I can't explain this, I wish someone with more in depth knowledge of Visions could tells us how transition works behind the scenes. I guess lesson here is that transition contacts shouldn't be used when bits they reflect are changed from scan to scan.

testsubr V430.vlp

[Ausman]

I haven't looked at the vlp, but my thinking is that the whole point of transitions is changing state from one scan to the next.  All the help info refers to "scans"...which I read as complete scans.

So for the transition to work properly, it has to change state again on the next scan.  The one after that it will work again.  Perhaps I've missed something crucial, relating this to what you're saying Isakovic.

On another note, I'd seriously be asking "why" there would be use of a transition for something required to happen so quickly.  A variety of methods would do it without a transition, to change a state and get it back to the original on the second scan, ready to start again on the 3rd.

cheers, Aus

[Isakovic]

20 hours ago, Ausman said:

I haven't looked at the vlp, but my thinking is that the whole point of transitions is changing state from one scan to the next.  All the help info refers to "scans"...which I read as complete scans.

Yes help doesn't go into much depth. I did some more tests. Just out of curiosity, can't really say I know stuff if I'm not sure about fundamentals.

This program works as expected, both in main and in routine. It sets it on odd, resets on even scan number. Computer works.

Next program doesn't recognize transition. It is in a subroutine called from transition contact for F1 button. I would manually reset XB23 after setting it with F1 button. It does recognize normal contact.

Next program is the same (should behave the same) in main and it does recognize transition as well as normal contact. XB23 is again resetted manually.

I guess when using transition subroutines should be taken into account. Subroutine has to "see" bit change for transition to work inside of it. Am I right here? But also shouldn't transition be updated as soon as change happens not at the end of scan.

Next two programs recognize transition in the middle of execution.

Sorry for the curtain of pictures. As Aus said it's unlikely to run into these issues when doing normal, standard, nonexotic programs. But it would be great if someone who knows this stuff under the hood could explain it.

[Sideway]

22 hours ago, Ausman said:

On another note, I'd seriously be asking "why" there would be use of a transition for something required to happen so quickly. 

Hi everyone, thank you for your replies.

The whole story is that i created a small program, split in two subroutines... And the goal was to send new XYZ coordinates to my drives after the last point had been reached.

The purpose of my XB was :

XB rises = load my position buffer into the drive and wait for the motors to reach target".

When target reached, XB would reset and i would load new coordinates in my position buffer. Then i ask for XB SET again to load buffer into drive.

Everything was working fine for the 1st point launched in the drive, but the program was blocking abruptly when asking for the 2nd point to be sent. And this was due to the weird rising edge failure i just shown.

Cheers,

Sideway.