Property node issues with while loop

[Sakthipriya]

Hi,

I am trying to programmatically invoke an event structure (using "gain_to_add" control in the image attached). The entire event structure and the gain_to_add value(sgnl) is inside a while loop. After I invoke the event structure case using any of the control parameters, the program is stuck forever. Can someone please help resolve this issue?

Thanks

[pincpanter]

It should be better to upload your vi. Are there other events in the structure? Not sure what you are trying to do because I don't know the device you are using.

However, in each loop you generate one event (by code with Val(Sgnl)) and manage one event, so there is no room for other events.

[Sakthipriya]

Thank you for your reply. I have attached the vi. I am trying to autoadjust the gain of DLPCA amplifier. The original code is from FEMTO and I haven't made changes to  other event structures. So I don't expect them to break the code. 

[altenbach]

I think you should go back to the basic tutorial, look at the shipping examples, and look at the design templates that ship with LabVIEW.

Your code architecture exposes some glaring misconceptions about dataflow and events and we would be happy to help to straighten things out and lead you on the right path.

Unfortunately, an image is insufficient, especially since there are hidden wires going in all directions, missing information on what's in the other cases of case and event structures, and just a general mess. Please attach your VI and explain how the user is supposed to interact with the program and what should happen as a result.

[pincpanter]

---

@Sakthipriya  ha scritto:

Thank you for your reply. I have attached the vi. I am trying to autoadjust the gain of DLPCA amplifier. The original code is from FEMTO and I haven't made changes to  other event structures. So I don't expect them to break the code. 

---

This vi is half event-driven half poll driven, a mess from a structural point of view.

I guess you don't really need to enumerate USB devices at every loop? If the answer is yes, I would fill Available LUCI-10 Devices before the loop and manage the device selection in the Event Structure itself, adding its Value Change event.

[altenbach]

---

@Sakthipriya wrote:

I have attached the vi. I am trying to autoadjust the gain of DLPCA amplifier. The original code is from FEMTO and I haven't made changes to  other event structures. So I don't expect them to break the code. 

---

Thanks for attaching the code. Can you also attach the original example, i.e. before your modifications?

A quick band-aid solution would be to only write the signaling property whenever the boolean changes (assuming this is rare). Still. I have the feeling that much better solutions exists.

Why is "gain to add" a control? The user should not be able to change the value manually if you constantly stomp on it programmatically. There are so many questionable constructs!

[Sakthipriya]

Thank you for your reply. Here is the original VI. Indeed the gain_to_add should not be a control. 

The feature I want is that every time the overload Boolean turns true, I want to update the gain value inside the event structure case 3. Please let me know if you have better solutions. 

[altenbach]

---

@Sakthipriya wrote:

The feature I want is that every time the overload Boolean turns true, I want to update the gain value inside the event structure case 3. Please let me know if you have better solutions. 

---

OK, currently you add whenever it IS true, which is not the same as TURNS true. (Also note that you have a race condition, because you cannot guarantee that the event gets fired by the signaling property before the event executes.)

To get a TRUE whenever there is a false-to-true transition, you could use something similar to the following:

(there is also a boolean crossing subVI that does something similar)

[JÞB]

---

@altenbach wrote:

---

@Sakthipriya wrote:

The feature I want is that every time the overload Boolean turns true, I want to update the gain value inside the event structure case 3. Please let me know if you have better solutions. 

---

OK, currently you add whenever it IS true, which is not the same as TURNS true. (Also note that you have a race condition, because you cannot guarantee that the event gets fired by the signaling property before the event executes.)

To get a TRUE whenever there is a false-to-true transition, you could use something similar to the following:

(there is also a boolean crossing subVI that does something similar)

---

There is even a malleable (.VIM) that does change detection. Changed? And TRUE is relatively easy to read

[altenbach]

---

@JÞB wrote:
There is even a malleable (.VIM) that does change detection. Changed? 

---

... but that detects changes in both directions and cannot tell the difference, so it is not the same.

(Boolean crossing offers that luxury)