LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FP Control Array update using References

I'm asking for advice to see my way forward-- I need to expand the number of channel that my UI handles.  My subVI currently commands, data and status for a single hardware unit connected via a serial port.   I pass references of FP indicators  to the subvi as follows:

subvi.png

As you can see, to get to 8 channels on my FP, I created 8 copies of the indicators, then manually created their references to pass to the subVI that handles one channel.   

I need to expand this to many more channels, and so I need to solve the problem of displaying the indicators on the front panel, and creating the control references manually.  It seems to me that a control array is useful for this purpose, something like this:

controlarray.png

 

I'd like to be able to do the following in order to minimize the amount of work in expanding the number of channels:

1.  Allow the user to specify the number of channels

2.  Have one cluster in the control array for each channel

3.  Programmatically create an array of references to the indicators

4.  Use the channel index to obtain the references for the FP indicators and pass them to the subVI

Is this possible?   Or if there's another approach to this that I'm not seeing, let me know.

 

Thanks,

John

 

 

0 Kudos
Message 1 of 16
(3,834 Views)

I'm not sure exactly what you're asking because I think you already have come to the correct conclusion. Use an array. The single array reference is all you need to access the values of the array elements.

 Array Ref.PNG

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


Message 2 of 16
(3,794 Views)

Just to make sure I understand, I would pass the array reference to the subVIs, along with a channel number and update the array element for that channel?  I had the understanding that in order to update the FP indicator value from the subvi, that I had to supply the reference to the subvi.  That's why, in the block diagram snippet I showed, I was passing a typedefed cluster of control references to the subVI where I used a value property nodes to update the FP indicators.  Is there another way that's scalable to many channels?

0 Kudos
Message 3 of 16
(3,781 Views)

In order to update a control/indicator on the front panel, you either need access to that control's terminal (i.e. not within a subVI), or have a VI Server Reference value for the control/indicator (i.e. right-click, create, reference). There are more complicated ways to generate references in more sophisticated VIs with a million controls, but you don't need to worry about that if an array works.

 

Once you pass that array reference to a subVI, that is all you need to set the array value. How you pass the channel number to the subVI, etc, is up to you. The entire code above (excluding the terminal and reference node) could be put inside a subVI.

SubRef.PNG

 

I should point out that you are setting the value of the entire array when you set the value, so you will need to index, change, and overwrite a specific element in the array then write the entire array back again. My example above does this.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


Message 4 of 16
(3,777 Views)

Thanks, I'll give your suggestion a try.   So I just need to pass the array reference to the subvi--I don't need an array of control references--much simpler than I thought!    And the value update is immediate if it's done in a while loop in the subvi?   

0 Kudos
Message 5 of 16
(3,770 Views)

Also, if I have N reentrant subvis for an n-channel system isn't there an issue with simultaneous updating of the FP array in the subvis?

0 Kudos
Message 6 of 16
(3,766 Views)

Setting a Value property using a reference is essentially the same thing as writing the value directly to the control terminal. Pretty instantaneous.

What you will run in to if you are doing this in parallel is race conditions... If you read from the array twice at the same time, the slightly slower instance will end up overwriting the other instance as it will have missed the change from the faster instance. A bit tricky to describe, but hopefully you understand.

 

Do you need to have this updating done in parallel? It doesn't take long to update values, so potentially you could update each instance 1 by 1 in a For loop and not worry about the parallel updating. Another option, if it reeeally has to be reentrant, is a FGV that is non-reentrant inside of your reentrant VI. The FGV would act as a forced memory space that would eliminate the race condition at the disadvantage of causing your reentrant subVI instances to wait for each other if they operate the FGV at the same time.

 

I think at this point we need to see what you subVI looks like. Can you share your code?

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 7 of 16
(3,761 Views)

No subvi instance will update the array element for any other channel, so there's only one writer for an array element.

 

Subvi is attached, of which there are 8 instances in the current program.   Soon to be as many as 64.

 

0 Kudos
Message 8 of 16
(3,755 Views)

@wygonski wrote:

No subvi instance will update the array element for any other channel, so there's only one writer for an array element


But you will have the race condition when two parallel processes try to update the array (you could overwrite new data with stale data).

 

Over the years, I have realized that control references are very rarely a good solution.  Instead of passing the array reference, use an User Event to send the updated element and ID to your main GUI loop.  That loop can now handle updating the GUI and avoid race conditions.  This will also help your device loops since property nodes are horribly slow.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 9 of 16
(3,737 Views)

Yes there will be a race condition since the FP indicator is being used as a storage location (should be for input or output but not storage)

Spoiler
(but for very slow boring VI's I have cheated)

 and once it is read in one thread, simultaneous updates will fight with each other.

 

 

Better to have a single master copy of the data in a DVR or Action Engine and only write the FP when the data changes.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 10 of 16
(3,721 Views)