Events not working in executable

[cscansin]

I use an MVC style model when creating my programs. Everything runs as expected on my main computer. However, when I build the executable, there are issues with certain buttons that need to have another event occur in order for the initial button pressed to work. (I.e. Press next button(boolean) increment counter) It does not increment the first time, following clicks due increment the number.

if I hit the button to run the main program within the exectuable, it will not work until another even is completed.  

To me it seems as if the program isn't acknowleding the event occuring, is this a possible issue? 

Programs with event based loops have worked before on the same sations and the program works pre-compile.

Any help on debugging this would be very appreciated.

Is there a known issue with compiling  programs/executables that use parrel event driven loops? 

[altenbach]

You probably need to show us your code (or a simplified version of it).

(I suspect a subtle race condition that gets exposed when the code gets recompiled (with debugging disabled, etc.) into the executable.)

[crossrulz]

---

altenbach wrote:

(I suspect a subtle race condition that gets exposed when the code gets recompiled (with debugging disabled, etc.) into the executable.)

---

This was my first thought as well.  I have ran into some interesting ones over the years and going to an executable often makes it show up.

[nathand]

Can you share any simplified code that demonstrates the issue, or at least a screenshot or two of your code? Have you tried enabling remote debugging, and connecting to the running executable, to see what's happening?

I haven't seen any reports here of a known issue with events working in the development environment but not in an executable. I think it's more likely there's a bug in your code, but LabVIEW bugs do pop up from time to time.

[cscansin]

Hey all,

Here is a screenshot of the simplified top level vi.

I can't think of race condition but who knows?

When I enable remote debugging will I be able to see the block diagrams of the executable on a computer that only has the runtime engine installed?

Thanks!

[nathand]

Why are you using the "reinitialize to default" method, rather than a latching action on the control?

Can you match up your description of the problem with the parts of the code/screenshot where you think the problem is occurring?

---

cscansin wrote:

When I enable remote debugging will I be able to see the block diagrams of the executable on a computer that only has the runtime engine installed?

---

Yes - you will be able to see the block diagram on the computer that is running the debugger/development environment. You need to compile the application with debugging enabled so that the block diagrams will not be removed.

[cscansin]

Attached is the top level vi. Sending a screenshot for the full run function is too complicated. THe first screenshot shows the jist of how the program works including the run vi.

The events I am having this problem repeatedly occure on the other machine are:

Pressing the next button which is a simple increment of the control using a property node, it does not increment the first time. It does however increment all succeeding clicks.

Pressing the run button, which goes through the main vi containing all the setup and measurement information. This works as long as another button tied to an event is clicked after the first run occurs.

All buttons work the pre pressing run the first time. Sorry if the explanation is not clear.

I would love to be able to remotely debug the program but I don't seem to understand how to access the block diagrams after creating the executable with remote debug enabled and wait for debugger to launch checked.

[nathand]

Can't open your VI at the moment (still on LabVIEW 2012 here) and I'm puzzled at one part of your screenshot - I don't see the selection value for the interior case structure?

Also, why so much use of the Reinitialize to Default method? Have you considered a latching boolean action?

For the remote debugger, start by running the compiled application on your development computer and connect to that. Once you get that figured out, it's easier to do remotely. Start up your application, then in the LabVIEW development environment, under the Operate menu, choose Debug Application or Shared Library. Enter the IP address or hostname of the machine running the compiled application (on your local machine, you can enter "localhost"). When you do that, do you see the compiled application available to be debugged?

[cscansin]

Awesome I have the remote debugger working. The remote debug explanation is much clearer than I wanted to read anywhere else. For some reason I could never make the connection (In my head) that you look for debug in the developer computer.

I found the error and it had to do with an instrument compliance error due to slightly different versions of instruments being used. 

The error would sit in the instrument and would be propegated through the program anytime the instrument was called up. It is cleared after any other event is clicked because it sets a case that will not go into that instrument immediately and the instrument when called upon any other time is initialized once more, thus clearing the error.

Thanks for the help! 

Side notes:

- The selection value was string based and came through the queue every time an event was clicked a specific string would be sent

- I'll consider using a latching boolean action with the mouse up event in order to have only 1 event being created and the control being initialized to default. (The pass and fail reinitialize to defaults are indicators. I could also use a property node to set the values to false.) 

Why no love for the reinitialize to default method?

[nathand]

---

@cscansin wrote:

- I'll consider using a latching boolean action with the mouse up event in order to have only 1 event being created and the control being initialized to default. (The pass and fail reinitialize to defaults are indicators. I could also use a property node to set the values to false.) 

Why no love for the reinitialize to default method?

---

You should use the latching action with a Value Change event, not a Mouse Up event (it appears that you are using a Value Change event already). You'll get only one event; the reset action of the latching control does not cause an event.

If you can't use a latching action, and you just need to set the value back to False, use a local variable. For setting the value of a control, a local variable is slightly more efficient than a property node. For an indicator, the best option is of course a wire. I'm not a fan of "Reinitialize to Default" because it seems like a complicated way of doing something that a latching action does automatically. Also, if the default value is changed, you'll wonder why your code isn't doing what you expect. I prefer to set the control to the value I want explicitly.