05-02-2014 12:48 AM
Ah, sorry. Here is the latest code.
05-02-2014 06:49 AM
Put the Event Structure inside of the loop. You should also create cases for the value change of the channel buttons.
And change those channel buttons to be actual buttons instead of the LEDs. The look like indicators when you leave them as LEDs.
05-02-2014 07:57 AM
I just love it when you need to tell somebody something at least 3 times because they didn't seem to pay attention the first two times you told them.
05-02-2014 09:00 AM
@RavensFan wrote:
I just love it when you need to tell somebody something at least 3 times because they didn't seem to pay attention the first two times you told them.
Maybe they just need to hear it from somebody else. That has happened to me many times. I tell somebody to do A so many times and they refuse until somebody else comes along and says "why don't you just do A?" Can't help but linking to my first post when that happens.
05-02-2014 09:05 AM
I like how in message 9 they claim they solved their problem, when obviously the most recent code is hardly any different than the original, and still shows there is no way that the event structure can execute more than once which was one of the main original problems.
05-02-2014 02:28 PM
Hi,
My code actually does work the way it was intended now. When I place the event structure inside of the while loop it does not grey out the channel controls in real time like I want and instead only gays them out after the event has been executed. I never said I wanted the event structure to execute multiple times in a row if that is what you are thinking. I wanted to be able to change the channel configuration, click the trigger, and have the event execute and update the output. It does do that.
I am still unsure why you keep suggesting to place the event structure inside of the while loop when I have done that multiple times with no success.
05-02-2014 08:32 PM - edited 05-02-2014 08:37 PM
Because in message 7 you said:
@tbergen1 wrote:
I am able to grey out the channel controls in real time with this method, but I'm only ever able to execute the event once.
You can only execute an event once because when you press the Run button, once you finally get to where that event can execute, it will execute once and your code will end. (Unless you restart your VI. And please don't tell me you've been using the Run Continuously button.)
The event structure belongs in the while loop so that it can execute more than one time when you run your VI. The code to disable the controls belong in the event case if you don't want them to be disabled until the event executes.
If stuff is not executing in the correct order for you, then the problem is that you don't have your data flow set correctly to control the order of execution.
05-02-2014 09:35 PM
Could I ask what is wrong with using the Run Continuously button? I believe I solved the problem finally. I didn't understand what you were talking about with regards to including the event inside of a while loop as I used Run Continuously instead of just Run. I got it to work correctly with Run by using two while loops and stopping the execution of the one encompassing the controls to allow the event to execute with the updated information. I attached the VI if anybody wants to take a look.
05-02-2014 09:55 PM
Run Continuously is the same thing as hitting the Run button over and over and over again. Constantly restarting a VI. It is really only meant to help debug a VI. Let's say you have a subVI that performs a handful of calculations and you want to test it out and see if it works properly with different inputs. Then you Run Continuosly so you can see if the the results are correct while you play with the input controls. In normal VI usage, it keeps you from ever ending a VI cleanly because the only way to stop it is to use the Abort button.
Attached is a way to do it with one while loop.