VI stalls when F9 is pressed

[Eric1977]

Could someone take a look at my VI and see why the F9 key sometimes stalls when using Excel? I am using this to aquire data from different devices when the user selects a different hardware device.

I need a second set of eyes to look at it and give me some advice/opinions.

[Hooovahh]

What's with all the property nodes?  Those cause UI thread swapping, when a local variable can be used.  Also is there a reason you decided to not use an event structure?  That way you don't need to poll the keyboard.  That bottom loop of yours has no wait so it will propablly try to read the keyboard multiple thousands of times a second which is a bit taxing on the CPU.

Oh but you're going to love this.  Right click the Get Reading button and go to properties, then Key Navigation tab and under the Toggle choose F9.  Now it will make the button true when you press your button, no need for that whole bottom loop.

As for structure I would have choosen a state machine more of a Queued Message Handler like the JKI State Machine so state reuse could be used a bit more, not that what you did was terrible.

Oh and the UI looks like something from the LabVIEW 8.0 era, I'd give it some attention so it doesn't look so LabVIEW.  In my opinion programs should look like a Windows program, and not look like any one language.

[Eric1977]

---

@Hooovahh wrote:

What's with all the property nodes? Those cause UI thread swapping, when a local variable can be used. I had read somewhere on these forms that those locals cause race issues so I used those.

Also is there a reason you decided to not use an event structure?  That way you don't need to poll the keyboard.  That bottom loop of yours has no wait so it will propablly try to read the keyboard multiple thousands of times a second which is a bit taxing on the CPU. True, but I wanted to capture the F9 key when it was pressed. I had thought I had used a 100ms wait there. Thanks for the heads up.

Oh but you're going to love this.  Right click the Get Reading button and go to properties, then Key Navigation tab and under the Toggle choose F9.  Now it will make the button true when you press your button, no need for that whole bottom loop. I tried that. My users want the cursor to move to the next cell in Excel and the only way to do that would be to pool the keyboard.

As for structure I would have choosen a state machine more of a Queued Message Handler like the JKI State Machine so state reuse could be used a bit more, not that what you did was terrible.

Oh and the UI looks like something from the LabVIEW 8.0 era, I'd give it some attention so it doesn't look so LabVIEW.  In my opinion programs should look like a Windows program, and not look like any one language.

---

[crossrulz]

---

@Eric1977 wrote:

---

@Hooovahh wrote:

What's with all the property nodes? Those cause UI thread swapping, when a local variable can be used. I had read somewhere on these forms that those locals cause race issues so I used those.

---

Guess what. SO DO THE VALUE PROPERTY NODES!!!  In fact, you made things WORSE by using the value property node because the property node does nothing to help with your race conditions (so they do not solve your problem) and they are 1000+x SLOWER due to the thread swapping to the UI thread.  In case you did not know, this is my #1 pet peeve.

[Hooovahh]

Yeah it's how you use Local Variables, Global Variables, and Property Nodes that cause race conditions, not the tools them selves.  Sorry if someone didn't explain that clearly before.

A property node can help force data flow by having error in and out, but the many times it isn't needed.  And when it is a small sequence structure can be used.  That's not what I do every time, because some times I need to read the value of a control, and read some other property.  In these cases I'll resize a property node to do both.  It was going to have to do a thread swap anyway.

I think the 100ms wait in the poll only happens once the logging starts, not when it is waiting for a start condition.

I don't fully understand how using the toggle on button won't meet your needs in regards to Excel behavior.

[crossrulz]

---

Hooovahh wrote:

I don't fully understand how using the toggle on button won't meet your needs in regards to Excel behavior.

---

Maybe because the VI won't have focus, but Excel will?

[Eric1977]

Crossrulz nailed it. If I change the behavior to use the Toggle feature on the button & do nothing else, LV will never see the button press thus not executing the Event Structure since the VI or EXE will never have the focus.

[Hooovahh]

Gotcha, that wasn't clear before.  Capturing keyboard keys, when a LabVIEW window is not active, from within LabVIEW must be done through polling.  Well there is the Windows Messaging Queue but that also requires other information for the call back.

[Eric1977]

I believe I have figured out what my issue is. On our area, about 30 (or more) people are hooked to one WIFI hotspot which appears to everyone that our our network is at a snails pace. Since the program has to place the data in an Excel file out on our file server, it appears to the user that the program quits responding since it is only a state machine. When users leave for the day, the WIFI spot has less load and in turn the program works as intended.

I may have to impliment a queue system to track all the data being transferred no matter how slow the network gets.