01-15-2021 03:50 PM
To keep a list of instruments and their data I am using attributes (as a one element queue) in a variant. I am wondering if this is best practice. Would you please comment and/or direct me to a document that would explain pros and cons of different methods?
I made the attached example to help understand what I am asking.
Here is how I initialize the object.
Getting data from the variant is just a Preview on the queue.
One drawback to this method is the shift register (feedback node) requires the list vi to be non-reentrant. This means that the VI must complete before any other code can use this VI. Is there a better way? Also, if there are large data sets (large arrays for example) in the object does that mean a huge amount of memory manipulation? I would think there may be a better way to make the code faster.
01-15-2021 07:31 PM
My current "Instrument Registry" code uses a Map of DVRs of Instrument Objects. Yes, this registry VI is nonreentrant, but are you really trying to lookup that many instruments at the exact same time?
Maps are new in LabVIEW 2019 and are so much easier to understand and the performance against the Variant Attributes matches at the worse.
A Single Element Queue is a really old way to do a DVR. DVRs with In Place Element Structures are great for ensuring only one place can communicate with an instrument at a time.
It looks like you already have the OOP figured out, so I'll leave that part alone.
01-16-2021 08:44 AM
I have a bank of cameras that I am using that capture images all at the same time. These image files can have large amounts of data. Unfortunately this also requires an image processing dll which means I have to send it large arrays. Thus, I believe the answer is yes that I do have to look up many instruments all at the same time and the timing is critical.
On the Instrument Registry do you know of a blog or example program? I plan on making one myself to make sure I know how it works on the inside but it is always nice to double check if there are any gotchas that I may have missed.