XY graph in producer/consumer structure

[Leukocyte]

Hey there,

this is my first shot at setting up a producer/consumer structure to operate a power supply (I've posted several questions about it here, but since this is more a Labview programming specific question, I thought this might interest more people). Seems to be working fine when using simple controls. But I also want to display the voltage plotted against time. To get the voltage, I have to send a control to the power supply to get the measurements in answer, get the voltage from there and put it in the graph. Since I can only send one control at a time, I've chosen to queue the "read" state behind every control (so for example, when queuing (or queueing?) "Run", I send "Read" immediatly afterwards so as to start the reading). But of course, every time I send a new control (change parameters for example), the graph is set back to zero. Does anyone know a way around this?

This is just a tryout, no error handling or even closing of VISA sessions.

[RavensFan]

Your graph wire.  On the right hand side of the tunnel, it is a hollow box which means it is not wired through every case of the case structure and it set to "Use Default if Unwired".  Thus it is resettiing to the default value an empty array.

Uncheck  "Use Default if Unwired".  Then make sure that wire is wired through in every case of the case structure.

[Leukocyte]

This is... embarrassing. To say the least. Thanks a lot!

[Blokk]

That is why it is not recommended (usually) to use the "default if unwired" option, easy to miss such mistakes 🙂

Hmm, I think you do not need the 150 msec Wait in the Consumer while loop. you have already timing inside the Read case...

[Leukocyte]

Yeah, I usually use it for booleans to stop or continue a loop, so I only need to place a "false" in one case of a state machine. But the 150 ms is the minimum time between 2 commands sent to the power supply, otherwise, it's not able to manage the commands that are coming in too fast. But I guess that if I really want a reading every 500 ms, I guess I should put (500 - 150 😃 350 ms in the READ state, correct? This was just trying out anyway.

[crossrulz]

---

@Leukocyte wrote:

But I guess that if I really want a reading every 500 ms, I guess I should put (500 - 150 😃 350 ms in the READ state, correct?

---

Not really.  Your waits are in parallel, so the delays do not simply add up.  You really should get rid of the 150ms wait that is outside of the case structure.  If you need to introduce any delays, they should be in the specific cases that will need them.

[crossrulz]

One more comment on your code.  If you have something that needs to constantly happen, I just use the Timeout ability of the queue.  You could just set your timeout to be 500ms and then on timeout it performs a read.  This would eliminate the need to enqueue the Read command at all.

[Leukocyte]

---

crossrulz wrote :

Not really.  Your waits are in parallel, so the delays do not simply add up.  You really should get rid of the 150ms wait that is outside of the case structure.  If you need to introduce any delays, they should be in the specific cases that will need them.

---

Well, the power supply doesn't accept commands that come in at a faster rate, so I was thinking that by putting the wait function there, I would manage the queue in a way that it only sends commands at this specific rate. It's only the read function that needs to be executed at specific intervals. All the others don't need to. So I would still delete de 150 ms and put it inside every other command case?

---

crossrulz wrote :

One more comment on your code.  If you have something that needs to constantly happen, I just use the Timeout ability of the queue.  You could just set your timeout to be 500ms and then on timeout it performs a read.  This would eliminate the need to enqueue the Read command at all.

---

You mean the timeout abilty of the queue? How would I go about this, create a separate "enqueue element", wire a constant of 500 to the timeout and the read state to the element input, then wire it to the Master Queue? I was thinking of using the timeout ability of the event structure. But I guess that wouldn't be ideal if I have more than one producer loop... Anyways, you Sir, are a genius.