LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Retaining SubVI input values

I'm using two instances of the 'ODBC LOG' SubVI within my temperature monitor vi. 

 

Just wondering if there is a more elegant way of retaining the input values of the first instance and passing them to the second instance?

 

By the way, the first instance creates the log file and the second instance inserts values.

 

In conventional code, the input values would be set-up in variables and then these would be used by both instances.

 

We had a contractor once that set-up shift registers within a subVI to act as memory elements for this purpose. This also is not very elegant solution when you open the vi.

 

Just wondering if there is another way of getting the second instance to pick-up the first instances input values without having to link them all across?

 

Many thanks in anticipation

0 Kudos
Message 1 of 6
(2,654 Views)

@AndyVessey wrote:

I'm using two instances of the 'ODBC LOG' SubVI within my temperature monitor vi. 

 

Just wondering if there is a more elegant way of retaining the input values of the first instance and passing them to the second instance?

 

By the way, the first instance creates the log file and the second instance inserts values.

 

In conventional code, the input values would be set-up in variables and then these would be used by both instances.

 

We had a contractor once that set-up shift registers within a subVI to act as memory elements for this purpose. This also is not very elegant solution when you open the vi.

 

Just wondering if there is another way of getting the second instance to pick-up the first instances input values without having to link them all across?

 

Many thanks in anticipation


 

It is hard to tell without looking inside the sub-VI.

 

Re: not very elegant

 

Again I don't know what is inside the sub-VI but it sounds like the contractor tried to implement an Action Engine (please see this Nugget on Action Engines here).

 

When properly implemented Action Engines are second only to LVOOP in the area of "elegant code".

 

I hope that Nugget helps explain what you are seeing. I suspect this reply is not what you were looking for when you posted.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 6
(2,624 Views)

As an alternative to the Action Engine (see Bens post), just go by-wire.

 

In conventional code, the input values would be set-up in variables and then these would be used by both instances.


The equivalent to variables of conventional code are the wires in LV. The common 'pattern' you would use is to wire them through in the SubVI, so you would have the same indicators (output terminals) as you have controls (input terminals). You see this on the error wire, which just connects through in a straight line. There is nothing 'bad' that they are just unchanged inside the SubVI.

As a second point, they could be bundled as a cluster to only have 1 instead of 3 wires (unbundling takes place in the SubVI).

 

Now a short comparison of the by-wire and the Action Engine (AE) approach. The AE would eliminate the wires after the first call (Insert/Create = False), as the data is kept inside the unsigned shift register (USR). On the down-side of the AE, this would make the Logger VI a single-instance. So if you want to log diffrent data to a diffrent file in the same application, you either need a duplicate AE or use the by-wire approach.

 

If I were to change something on the code, I'll replace the boolean Create/Insert by a type def'ed enum. It's not really clear what Insert/Replace=False really means (guess it's a toggle switch on the FP).

 

Felix

0 Kudos
Message 3 of 6
(2,606 Views)

@f. Schubert wrote:

As an alternative to the Action Engine (see Bens post), just go by-wire.

...

On the down-side of the AE, this would make the Logger VI a single-instance. So if you want to log diffrent data to a diffrent file in the same application, you either need a duplicate AE or use the by-wire approach.

... 

Felix


Way back in LV 6 and prior we did not have polymorphic queues. Since they were not polymorphic, the data had to be flattened to a string then unflattened to pass it via a queue.

 

So back then it was faster to use a "Round Robbin" buffer to share the data. To avoid the situation you mentioned, I implelemented RR buffers that had multiple pointers and could serve more than one consumer. It act eaxactly like using two queues but only uses a single buffer to store the data.

 

This is what that code looks like now in LV 2010.

 

Round_Robin.PNG

 

 

 

 

As soon as I benchmarked the polymorphic queues against this approach, I abondened this code. I am posting the image to illustrate that AE are only limited by our imaginations and ability to code.

 

Ben

 

PS String driven cases where all the rage back then.

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 4 of 6
(2,597 Views)

Ben,

Thanks for the reply.

 

I have looked at the Action Engine Nugget and now understand this the term. Yes this looks like what the contractor was using.

 

LVLOOP object oriented programming is interesting too.

 

Felix,

Thanks for the reply.

 

I'm not sure what 'by-wire' means - is this how I have it in my attached picture, where you simply use wires?

 

I like the comparison with the error cluster, as thinking about it, it is doing the same thing 'linking/passing across values'. As this is a fundamental in LabVIEW I guess this is how it is done - with a cluster. Unfortunately there is still a connection there with the cluster approach and the values aren't simply retained

 

It's my ODBC sub-vi second instance picking up the default input values when the inputs aren't wired which is the problem. If a system was in place to disable defaults on inputs, then the question would be which former instance if the subVI does the latter vi get it's values from.

 

Thanks very much for help on the options

 

 

 

 

 

0 Kudos
Message 5 of 6
(2,560 Views)

Ben,

 

The picture you posted is a good example of what I meant by 'not elegant' yet it is very functional. The shift register AE also relies on a lot of manual commenting, as the labels don't occur 'naturally' from the 'variable' names.

 

My understanding of LabVIEW is improving and I do really enjoy writing the code.

 

Andy

0 Kudos
Message 6 of 6
(2,554 Views)