Reusable custom controls/indicator groups and associated code

[giacomociani]

HI all,

sorry again for the slow interaction. I have a lot of things higher in my priority list than solving this issue, although I'm curious about it...

Anyhow, Jeff, thanks for the hint. I'll experiment with that when a find a little time.

Bilko, I must take back what I said. It seems like the globals are re-read every time I run the subVI. I don't know why that was not working the firsttime I tried... I was unable to recreate the conditions.

For your curiosity, my use of global variables is as follow: I have a piece of code doing input-output real time on an FPGA. Then I have and host VI that basically only reads/writes data from/to the fpga DMA channels and copy it to global variables. Then I have a number of VIs that read the "input" global variable and do different stuff: one writes the data to disk, another just displays is, some other write back some value on the "output" global variable (although each one is using a different ouput variable, and the values are then summed by the host VI before passing them to the FPGA DMA channel, so I believe I shouldn't have any issue with race conditions).

Giacomo

[crossrulz]

---

giacomociani wrote:

Bilko, I must take back what I said. It seems like the globals are re-read every time I run the subVI. I don't know why that was not working the firsttime I tried... I was unable to recreate the conditions.

For your curiosity, my use of global variables is as follow: I have a piece of code doing input-output real time on an FPGA. Then I have and host VI that basically only reads/writes data from/to the fpga DMA channels and copy it to global variables. Then I have a number of VIs that read the "input" global variable and do different stuff: one writes the data to disk, another just displays is, some other write back some value on the "output" global variable (although each one is using a different ouput variable, and the values are then summed by the host VI before passing them to the FPGA DMA channel, so I believe I shouldn't have any issue with race conditions).

---

That sounds like the prime candidate for race conditions.  Trust me on this, you want to use queues instead of the global variables.

[giacomociani]

Crossrulz, thanks for the warning. However, I do not quiete understand wich type of race conditions you expect... since no VI is writing on the same variable as another one, there is no risk of values being "overwritten". What else could happen?

[crossrulz]

---

@giacomociani wrote:

Crossrulz, thanks for the warning. However, I do not quiete understand wich type of race conditions you expect... since no VI is writing on the same variable as another one, there is no risk of values being "overwritten". What else could happen?

---

Lost data.  You have A writing to the global and B reading.  So what happens if A writes to the global twice before B reads it even once?  You just lost a data point.  In almost every situation I have been in, that is BAD.

[giacomociani]

Ok, I see your point. And indeed, we already considered that possibility. In fact, we have a solution already in place for that.

The global variable we are writing too is actually and array. The writing routine keeps track of the last position written, and always writes in the folowing one (wrapping around the length of the array when necessary). The reading routines do the same. I now see that queues would have been "built in" and maybe easier way of doing it (although with a few differences), but we didn't realize they were there when we wrote the code... luckily, what we implemented seems to be working well enough! 🙂

Again, thanks for the warning!

Giacomo

[crossrulz]

---

giacomociani wrote:

The global variable we are writing too is actually and array. The writing routine keeps track of the last position written, and always writes in the folowing one (wrapping around the length of the array when necessary). The reading routines do the same. I now see that queues would have been "built in" and maybe easier way of doing it (although with a few differences), but we didn't realize they were there when we wrote the code... luckily, what we implemented seems to be working well enough! 🙂

---

That is until your reading loop gets really slow and you overwrite your buffer.  Trust me, queues are EXTREMELY efficient and will not allow you to lose data (unless you use the Lossy Enqueue).

[giacomociani]

When may reading loop gets so slow that it looses 10 seconds of data, I have other issue to be worried about! 🙂

Anyway, I take your point. One possible issue with using queues in our system is that right now we have the data acquisition VI running all the time, and we can write and deploy new VIs that "consume" the data without stopping it (the just read a shared variable that is there anyhow). I guess that using queue I would have to create a new one (and thus stop the acquisition VI) every time we want to add a new VI?

Giac

[crossrulz]

---

giacomociani wrote:

Anyway, I take your point. One possible issue with using queues in our system is that right now we have the data acquisition VI running all the time, and we can write and deploy new VIs that "consume" the data without stopping it (the just read a shared variable that is there anyhow). I guess that using queue I would have to create a new one (and thus stop the acquisition VI) every time we want to add a new VI?

---

If you are doing that, you might want to look at the Actor Framework.

[giacomociani]

Interesting. I didn't even know it existed... thanks!

[Hooovahh]

---

@giacomociani wrote:

Interesting. I didn't even know it existed... thanks!

---

Thanks are given with kudos, and marking a solution to a thread when appropriate.