VI not executing properly when 'light bulb' is switched on.

[J.Mamakos]

I am using an event structure (with one event) in a fairly simple VI (see attached picture).  I think it is working properly but when i put the 'light bulb' on to check this, the event structure doesn't seem to be waiting for the event.  What is going wrong, or is it something I'm doing?

James

Message Edited by James Mamakos on 05-29-2009 01:25 PM

[Ben]

---

James Mamakos wrote:

I am using an event structure (with one event) in a fairly simple VI (see attached picture).  I think it is working properly but when i put the 'light bulb' on to check this, the event structure doesn't seem to be waiting for the event.  What is going wrong, or is it something I'm doing?

James

Message Edited by James Mamakos on 05-29-2009 01:25 PM

---

THere is nothing obvious in your code that tells me the event should fire, so let me grasp at straws.

If you do NOT set the scale max does the event still fire on its own? My thoughts are that the range change is somehow firing the event.

If you figure out anything more please keep us informed.

Ben

[Coq_Rouge]

Then you use the light bulb, the program slows down as some has pour syrup in your CPU. It could be that your event is waiting in a queue somewhere. If you want to do realtime bugging probes and breakpoints are much better.

[falkpl]

It is possible that you are changing the event value before you execute the look containing the event structure, with high light execution on it will take much longer before your loop is executed since the loop will only start once both wires in are satisified (after all file io).  When not debugging this will happen very fast (unless your data file is very large).

[falkpl]

"loop" not "Look" I cant type so I do labview.

[J.Mamakos]

I'm adding the VI this time.

The scale max is set only once, and before the while loop with the event structure executes. What i find is that the event structure wait correctly the first time but then as soon as it's been triggered once, it just lets the data through continuously (as if it wasn't thereand there were just wires) making the while loop execute continuously.  Also, when this happens, i find that the front pannel control cannot be changed.

[falkpl]

Just noticed one other thing, Your stop should be in the event structure, register vor stop value change and also read the stop inside the event structure, all other cases pass out false to the while loop conditional terminal.

[J.Mamakos]

---

falkpl wrote:

Just noticed one other thing, Your stop should be in the event structure, register vor stop value change and also read the stop inside the event structure, all other cases pass out false to the while loop conditional terminal.

---

Yup - just realised that once i'd posted the VI!  Made a couple of slight modifications, and am posting it again.

The problem is still there, and it's not just the dial control that can't be changed, it's the whole front pannel that freezes up.  Can't do a thing to it!

Does this VI look problem free because i'm not getting anywhere trying to check it with the lightblub and i'm not completely certain if it's working right when i use probes and breakpoints.  I've not used event structures much so i'm not that confident with them.

Message Edited by James Mamakos on 05-29-2009 01:54 PM

[johnsold]

I do not see the effect that you describe.  I modified the VI to use a set of locally generated data since I do not have any suitable datalog files.  I left the file read in and just cancel when the dialog pops up.  I cleared the errors so the Scale property node still executes.

The freezing is probably due to the Event structure having the "lock front panel until event case completes" box checked.  I did  note that moving the knob from 1 to 3 appears to generate 2 events, 1 -> 2 and 2 -> 3.  Could that be what you are seeing?

If you use Latch when Released mechanical action for the Stop button, the inversion and local variable are not needed.

Lynn 

[Ben]

---

johnsold wrote:

I do not see the effect that you describe.  I modified the VI to use a set of locally generated data since I do not have any suitable datalog files.  I left the file read in and just cancel when the dialog pops up.  I cleared the errors so the Scale property node still executes.

The freezing is probably due to the Event structure having the "lock front panel until event case completes" box checked.  I did  note that moving the knob from 1 to 3 appears to generate 2 events, 1 -> 2 and 2 -> 3.  Could that be what you are seeing?

If you use Latch when Released mechanical action for the Stop button, the inversion and local variable are not needed.

Lynn 

---

I would expect that to be the issue since it will fire once for each value passed while turning the dial.

Sanity check to verify:

Right-click on the dial and show digital indicator. Use that to key in a single value and see if that fires only one event.

Ben