Reinitialize a slide to default is late

[Aqua-]

Hi,

I've built a code for an XY stage to move in a grid shape according to input parameters. The code worked great, however the other day i fixed a code block and made it more efficient and compact and a bug appeared. This is the description:

I use a horizontal slide with 3 states as a button to execute the same command with a slightly manipulated data, i.e. when the slide points "inverse" multiply the data by -1, then execute movement, when "normal" dont manipulate data, then execute movement. The static is being used like an "off" state, i.e. do not execute command.

Upon executing (right after executing the movement command) I demand the reinitialization of the slider state to default, which is defined as "static". This way, I guarantee the command will be execute only once for each change of state, so it will function as a button.

Up to my fix in the "Move Relative" SubVi this arrangement worked well, however now for some input parameters the Movement command is executing twice or even 3 times before it reinitialize the slide value (or to be more precise because it does not reinitialize the value, it executes 2 or 3 times).

As mentioned, the fix was inside "Move Relative" SubVi, so as far as i see it the only thing that change is run time, as functionality (apart from this bug) is 100% the same.

An example for input parameters that make the bug are:

However more combinations are doing this bug. from a quick check it seems that as long as the velocity is smaller than the distance by a multiple of 5 the bug occurs, if the velocity is greater than that the slide reinitialize well. (5*v <= x  ---- while v is in [mm/sec] and x in [mm]).

I upload the main VI without the SubVi it uses, as they are not the problem + they some of them are complex and cumbersome + they communicate with my machine so you wont be able to test it anyway and see the bug...

So my question is - how do i force the slide to reinitialize before another cycle is being made? i tried to force "reinitialize to default" in any possible place in the frame, and force a "static" value through a "value" property node.

Any help will be very appreciated!

[JÞB]

~~~~oh magic 8-Ball,   is this Noraml behavior?~~~

....."Almost certainly.!"

Sometimes a typographical error can really bite you!  Check your spelling! Normal is not equal to Noraml

(I didn't even open the attachment)

[Aqua-]

---

@JÞB wrote:

~~~~oh magic 8-Ball,   is this Noraml behavior?~~~

....."Almost certainly.!"

Sometimes a typographical error can really bite you!  Check your spelling! Normal is not equal to Noraml

(I didn't even open the attachment)

---

Im out of the office for today, but not sure what you suggesting...

The movement works fine, my code does not use explicitly the case "Normal" in the case structure, but rather a 0,1,-1.

Do you see the reason why the command execute twice before reinitializing or are you just having a go at my typos?

[JÞB]

---

@Aqua- wrote:

---

@JÞB wrote:

~~~~oh magic 8-Ball,   is this Noraml behavior?~~~

....."Almost certainly.!"

Sometimes a typographical error can really bite you!  Check your spelling! Normal is not equal to Noraml

(I didn't even open the attachment)

---

Im out of the office for today, but not sure what you suggesting...

The movement works fine, my code does not use explicitly the case "Normal" in the case structure, but rather a 0,1,-1.

Do you see the reason why the command execute twice before reinitializing or are you just having a go at my typos?

---

I really think that you need to inspect that typographical error in the Enum!  The hints are that it worked until code was improved and reiniit itself is almost certainly not to blame.  ( you already ruled that out but, possibly blinded yourself with a fantasy that the property node has a latency) 

Outside of the typo, perhaps there is a local or global variable that is causing a race condition but, my money's on the typo since, the race condition was not likely introduced by modifications to the subvi. 

I really am fairly good at dissecting points where errors can cause code to go off track.  Especially the insidious ones that bring up loss of  sleep and hair.

[Aqua-]

---

@JÞB wrote:

---

@Aqua- wrote:

---

@JÞB wrote:

~~~~oh magic 8-Ball,   is this Noraml behavior?~~~

....."Almost certainly.!"

Sometimes a typographical error can really bite you!  Check your spelling! Normal is not equal to Noraml

(I didn't even open the attachment)

---

Im out of the office for today, but not sure what you suggesting...

The movement works fine, my code does not use explicitly the case "Normal" in the case structure, but rather a 0,1,-1.

Do you see the reason why the command execute twice before reinitializing or are you just having a go at my typos?

---

I really think that you need to inspect that typographical error in the Enum!  The hints are that it worked until code was improved and reiniit itself is almost certainly not to blame.  ( you already ruled that out but, possibly blinded yourself with a fantasy that the property node has a latency) 

Outside of the typo, perhaps there is a local or global variable that is causing a race condition but, my money's on the typo since, the race condition was not likely introduced by modifications to the subvi. 

I really am fairly good at dissecting points where errors can cause code to go off track.  Especially the insidious ones that bring up loss of  sleep and hair.

---

I will definitely inspect that and will come back and mark your answer as a solution if it will fix the problem, but 99% that it isn't, as no explicit use of the string state are being made.

I didnt say, but i followed the code in 2 manners - break point and the dynamic run (the light bulb in the code toolbar), both had a 100% success with no bugs at all. The movement executed only once. And so i suspect that somehow the command is doing a whole cycle without reinitializing the slide.

I do agree that it is probably neither from the SubVi that i fixed nor the actual reinitialize node, but for some reason the movement is happening twice before the reset is happening.

Besides the first press of the button does well, i.e. it moves exactly as ordered, it's all other presses that has the bug.

A few more tests that i haven't mentioned:

1) i threw a value property node before the case structure, between the movement and the reset node, and after the reset node - the first one was synchronous with my original slider, the last one was constantly on "static", but the middle one was functioning well the first run, but with an unwanted extra movement on any other run (as mentioned before).

2) in my original program i have a perallel loop that might race for resources, but in the concise SubVi that i sent here to demonstrate the bug same unwanted occurs without the perallel loop.

3) i moved the reset node to the beginning of the frame, before the case structures. Practically what happens is that the second one presses the slide it resets to "static", however the double execution still stands.

I really tried everything i was able to think of with no avail.

Hopefully your superpower works this as well, but seriously if you have the time I'll appreciate if you just have a quick look. Meanwhile tomorrow i will check it out.

Cheers

[JÞB]

That read value property node is another possible way of introducing an insidious race condition.

Are you familiar with the Defer Front Panel updates method?

Updating front panel values is not quite as simple as reading and writing...there is a transfer buffer that holds some values.  It takes some "Strange" context switching between execution contexts to create trouble. 

I'd consider that unlikely... but you seem just smart too get into this type of situation. 

I still recommend getting the typographical error fixed first.  Then I might even try to get data service to my laptop.   (Yes,  with COVID19, I am restricted to an Android and have no IDE Handy)but,  your post intrigues me. 

Read the LabVIEW help on defer FP updates.   Keep posting back!

[Aqua-]

---

@JÞB wrote:

That read value property node is another possible way of introducing an insidious race condition.

Are you familiar with the Defer Front Panel updates method?

Updating front panel values is not quite as simple as reading and writing...there is a transfer buffer that holds some values.  It takes some "Strange" context switching between execution contexts to create trouble. 

I'd consider that unlikely... but you seem just smart too get into this type of situation. 

I still recommend getting the typographical error fixed first.  Then I might even try to get data service to my laptop.   (Yes,  with COVID19, I am restricted to an Android and have no IDE Handy)but,  your post intrigues me. 

Read the LabVIEW help on defer FP updates.   Keep posting back!

---

Thanks for the help jay.

I will correct the typo for sure, and if only to avoid embarrassment. 😄

Never heard of the "defer panel updates", but will read of it as soon as possible.

I will keep posting and update, however it is somewhat a side project at the moment so the updates might not be so frequent, hopefully the post wont disappear under a flood of new questions.

Stay safe and entertained 😉

[Darin.K]

Buttons have a built-in capability that your slider will be lacking: latching.  With a button, you can easily achieve a single transition per button press (or release).  Your slider-switch is not going behave like that out-of-the-box.  Instead, it will keep trying to achieve a certain value as long as the mouse button is down.  What is happening in your code is that you move the slider to say 'inverse', if the motion is fast enough, the reinitialization occurs while the mouse button is still down, and the value immediately reverts to 'inverse'.  Once the user releases the mouse button, the reinitialization finally 'sticks'.  This is why it seems to work normally when the motion step takes long enough and is buggy when the motion is quick.

You are going to have to change something to get this to work the way you want.  You could use buttons (one for normal and one for inverse).  If you really want a slider you are going to have to add a delay (quick and dirty, not 100% effective) or use an event structure to try to fake it (many corner cases here to consider).

[Aqua-]

---

@Darin.K wrote:

Buttons have a built-in capability that your slider will be lacking: latching.  With a button, you can easily achieve a single transition per button press (or release).  Your slider-switch is not going behave like that out-of-the-box.  Instead, it will keep trying to achieve a certain value as long as the mouse button is down.  What is happening in your code is that you move the slider to say 'inverse', if the motion is fast enough, the reinitialization occurs while the mouse button is still down, and the value immediately reverts to 'inverse'.  Once the user releases the mouse button, the reinitialization finally 'sticks'.  This is why it seems to work normally when the motion step takes long enough and is buggy when the motion is quick.

You are going to have to change something to get this to work the way you want.  You could use buttons (one for normal and one for inverse).  If you really want a slider you are going to have to add a delay (quick and dirty, not 100% effective) or use an event structure to try to fake it (many corner cases here to consider).

---

Hi darin thanks for replying.

What you are saying is interesting, but the reality is quite the contrary.

When ithe movement is fast, i.e. when i insert a movement of 10mm with a velocity of 10mm/sec the bug is gone. The problem occurs when the motion is slow, i.e. movement of 10mm with velocity 1mm/sec.

What you are saying about the button make sense to me, i wonder if the "double click" is what make the problem.

I use the slid to make my code more compact. If i use 2 regular buttons i have to duplicate the whole chunk of code for relative movement just for that, and this is something i dont like to do. I like the idea of a 3 way button/switch cause its more intuitive, and TBH i work with a witeless mouse 3-4 meters from the computer so it's easier to see.

Is it really that difficult to make a 3 way button? Why there is not such a default option in the program? I'be seen so many requests in this forum for such functionality.

[Yamaeda]

I don't know how fast "reinitialize" is, I'd use a Value property node instead. That way I know it'll happen on the next UI update.