LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can't use front panel after for loop runs

So I'm new both in LabVIEW and programming in general so maybe I'm making a very basic mistake here but I'm stuck.

 

I have an array entering a For Loop with auto-indexing on and no value wired to the count terminal. 

Seperate from the For Loop I have a While Loop that is collecting data.  There is a button to terminate the While Loop and pass the collected data out for some analysis.

All of this is enclosed in an Event Structure, which is enclosed in a large While Loop that really just keeps the program running.

 

My problem is that once the "Start Run" button (which is the control linked by a Value Change to the Event Structure) is pushed I can no longer use any control on the front panel.  I've used the Execution Highlighting and both loops are running fine but I can't end my program or the While Loop. 

 

Any idea where I've gone wrong? 

 

 

Thanks in advance!

0 Kudos
Message 1 of 10
(3,723 Views)

Read the Cavaets on event structures in the help file.

 

It sounds like you've kept the default (lock front panel until event completes) in the event configuration.  

 

You really want to use queues to pass commands to consumer loops when you have code that takes several seconds to complete.  The event case must complete before any other events can be handled and this causes some ackward UI behaviors


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 10
(3,721 Views)

Hi Jeff,

 

I certainly did not modify any defaults.  However my board has been taken for another project and I'll have to wait until tomorrow to see if these fixes the issue! 

 

Are you talk about a Queued Message Handler?  I've used this type of setup in the past and it did go very smoothly.

 

Thanks for your help!

0 Kudos
Message 3 of 10
(3,716 Views)

Dac83 wrote:

Hi Jeff,


 

Are you talk about a Queued Message Handler?  I've used this type of setup in the past and it did go very smoothly.

 

Thanks for your help!


Yes-  as a matter of fact I had worked up a simple example for another post a three loop Event driven QSM with a timeout feature.  I'll attach it here as a referance about what I mean.  In this example the "working code goes in the middle loop leaving the event structure free to deal with that gready user who keeps demanding the front panel controls should work RIGHT NOW!


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 10
(3,694 Views)

Dac83, post your code.  I'm sure that there is a simple solution to your problem.  Jeff, although I like your queued message handler, I feel like this is a bit too much for a beginner.  A simple producer consumer architecture would probably fit the bill without overcomplications.

 

- tbob

Inventor of the WORM Global
Message 5 of 10
(3,686 Views)

 


@tbob wrote:

Dac83, post your code.  I'm sure that there is a simple solution to your problem.  Jeff, although I like your queued message handler, I feel like this is a bit too much for a beginner.  A simple producer consumer architecture would probably fit the bill without overcomplications.

 


 

Yep- but I had some fun playing with the timeout feature on the queue!  I really had not realised how USEFUL it could be until I ran with it.

 

And I saved myself from using an "express vi."  so double kudos to the OP of This thread for the chance to explore a feature.


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 10
(3,653 Views)

Ok sorry for the delay in response.  I've got the board back and am about to try Jeff's suggestion about the default setting.  My code is attached to see if there are any additional comments/criticisms/suggestions or just a simple solution.

 

Thanks again for the help!

 

16965i0084D914DABEEA17

0 Kudos
Message 7 of 10
(3,640 Views)

Yep! way to much code in the event!

 

You need the event to complete before another event can be handled.  so you need a Producer-consumer architechure to make this function right. 

 

You CAN add attachments to to posts so we could help with the vi itself rather than a picture.  but you still have some obvious issues.

 

Placing a User controlled loop inside an event case is NEVER a good plan and your implementation has some added disadvantages.  Events generated by front panel activity can be surpressed (and that is the default condition for an event case) so the user can click on "Stop2" all day long and the button WILL NOT press until the event its trying to STOP  is completed. 

 

You made a new style of infinate loop!  I'lll dub it the "Event can't complete until the event completes Inf loop" or eccutecil for short


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 10
(3,634 Views)

I went ahead and attached the VI.  I'm currently working on fixing some of the issues, we'll see what happens!

0 Kudos
Message 9 of 10
(3,621 Views)

I suppose I should be clear about what I'm actually trying to accomplish here.  I'm working with a non-NI board to send a digital signal to open a shutter.  The VI's that come with the board require a very clear ON of OFF (1 or 0) signal.  For instance if you send it a 1 and end the program the board will continue to output an ON signal to the shutter forever (or until you restart the VI and send it a 0).  This needs to be able to repeat N number of times with a certain delay (1 second open, 1 second closed).

 

At the same time I need to be able to collect analog input at a high rate to detect the increase in light from the shutter opening (and decrease from shutting) for each interation.  Then save the rise time and fall time to a file for each iteration to a file.

 

Maybe I've approached this problem from the wrong direction all together so I thought I should be clear about what I was attempting to do!

0 Kudos
Message 10 of 10
(3,615 Views)