Controls freeze after event is handled

[CT_Almax]

Hello all:

I have a problem I can't find the solution to. I am running a VI which controls Keithley power supply and also Omega DP32PT temperature controller. My goal is to let the user of the VI to be able to operate either of the instruments or turn on the feedback loop to keep temperature under control. But my problem starts at the power supply control. I can run it, read and write to it the currents and/or voltages, all goes well. However, every time I try to change the mode of operation or the slew rate, all controls freeze, but the current and voltage is being read from the device all right. I can even run the feedback loop and control temperature. But this is all I can do.

I tried to run the VI written by Tektronix, and it works without freezing. However, when I put almost the same code to my VI--it freezes the controls as described. I am out of any ideas why this happens. I attached two VIs for the comparison. please, let me know what is wrong here.

[cbutcher]

In the example, the Event Structure locks the VI until the event handling is finished - in your code you have unchecked that box. Normally I wouldn't have thought that would cause any locking, but I wonder if the time taken by the VIs called (the config VIs) is causing problems with the timeout case running too quickly after.

[billko]

I've never been a fan of putting "real" code in the timeout case.  By "real" I mean code that is more than acknowledging the timeout and doing something related to it.  In this case, all that "check this and that" code that you have would go in a parallel loop.  What if it never times out?

[altenbach · Accepted solution]

You have several event structures, another one is hidden in a different case.

What is the purpose of all these "key repeat" events? Many do lock the front panel, so if you would trigger one that is handled by the other event structure, the front panel will lock up forever because the event cannot be handled due to dataflow problems.

[CT_Almax]

I did not quite understand what you meant by "key repeat" events. I have only timeout and value change events, as far as I can see. All cases in my code handle the presence or absence of the devices: if no device is detected, program simply tells user so and closes, if only power supply is detected, one case structure is executed, if only temperature controller is found, false case inside the inner false case is executed. So it is not possible for different case structures to be executed during the same run.

What puzzles me is that I can change voltage and current level as many times as I want and front panel never locks itself. Why other controls lock it is beyond me.

[CT_Almax]

Some more information: I tried to remove one event, which is present in another case structure, to make sure it shows up only once in whole program. It did not help: front panel controls still freeze.

[CT_Almax]

Thank you, altenbach!

It really was the case of event handling present in another case! I would never have guessed that a case structure, which never executes, can still lock front panel forever. I removed all extra event handlers and everything is now working without freezing the controls. However, I encountered a behavior, which looks like this: sometimes when I change of of slew rates, it causes the voltage waveform graph to start updating itself at a blazing speed, as if there is a race condition. Where shall I look to eliminate such behavior? Is it possible that another case structure, which has parallel loops communicating with each other, causes this? What is the best way to prevent this from happening, because I can't eliminate those loops, I need them.

I hope this would be the last issue.

Thank you in advance!

[altenbach]

---

@CT_Almax wrote:

However, I encountered a behavior, which looks like this: sometimes when I change of of slew rates, it causes the voltage waveform graph to start updating itself at a blazing speed, as if there is a race condition. Where shall I look to eliminate such behavior? Is it possible that another case structure, which has parallel loops communicating with each other, causes this? What is the best way to prevent this from happening, because I can't eliminate those loops, I need them.

---

Well, one of the things is that you events are triggered by "key repeat", so if you hold down a control, there will be many "key repeat" events after a short delay, and they will all be added to the event queue. You also have fast timeout events.

We cannot troubleshoot something like this from words alone, so please attach your newest code and tell us which indicator shows that problem.

[CT_Almax]

Here is it. I tried to troubleshoot it myself, but did not succeed. I tried these things:

increase timing to 250 ms;

limit number of events in queue for voltage/current slew rate change to 1;

move code out of timing event;

put 250 ms wait time in main loop.

Any suggestions will be welcomed. Thank you in advance for your help.

[altenbach]

This thing is just a mess. For example if the outermost case structure is FALSE (and the innermost loop quickly terminates due to the comparison), you are constantly queuing up events (via val(sgnl) property nodes!), but that event structure is located in the TRUE case and can never be reached, ever!

Virtually all you value property nodes should be replaced by local variables for better performance.