cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Community Nugget 06/25/2007

Re: Community Nugget 06/25/2007

Nice Nugget Shoneil,
I also use the veriant method to transfer data between Producer loop and consumer loop too.In my last project where I have to control three Instrument using (client server architecture)
like producer consumer architecture but in my case the Server vi which is the Instruments has to be called dynamically.unlike the producer consumer loops which are in the same vi.

Veriant was the only way I could pass data from the server to the client using queue.

Keep the Nuggets coming.

CLAD
Certified LabVIEW Architect
Certified TestStand Architect
0 Kudos
Message 21 of 51
(3,989 Views)

Re: Community Nugget 06/25/2007

You can pass any class through a queue and they will retain all their data and the exact information about which child object they are. You can even flatten classes to strings and unflatten them, and they still retain all this information.
Jarrod S.
National Instruments
0 Kudos
Message 22 of 51
(3,987 Views)

Re: Community Nugget 06/25/2007



@tst wrote:

Another point - relying on undocumented features could give you some headaches later on. For example, in a recent thread there was someone complaining that the DB toolkit didn't work.
Why? Because when adding variants to the DB it relied on the internal structure to determine the size of the data. When that internal structure, the toolkit broke and NI didn't find it because they didn't test for that case.

JLV, one good reason for not using variants is that they are not strictly typed, so you can only catch errors at run-time. This is also something that speaks for them (for example, when you want to create this type of architecture), but there are other ways to do this as well.


Just curious:  what about portability to non-Windows OS? such as Linux..  how would it react to variants?
______________________________________________________________________
0 Kudos
Message 23 of 51
(3,964 Views)
Highlighted

Re: Community Nugget 06/25/2007

As far as I know, the endianess and internal representation of variants has nothing to do with the OS or the processor, so I believe they should be portable.

___________________
Try to take over the world!
0 Kudos
Message 24 of 51
(3,956 Views)

Re: Community Nugget 06/25/2007

tst wrote;

" As far as I know, the endianess and internal representation of variants has nothing to do with ... or the processor, ... "

Its NUXI story time. Smiley Mad

Unix was originall developed on a DEC PDP 11/70 and was latter ported to (I beileve ) an IBM machine.

When it booted for the first time it "flew the banner"

"NUXI"

becuase IBM had one endiness and DEC used the other.

So if the flattening was taking place on a PC and the unflatten was on a Sun work station, MAC or other, I would stop and ask myself about endiness about two seconds after it did not work. Smiley Wink

Ben

Message 25 of 51
(3,951 Views)

Re: Community Nugget 06/25/2007

I've been thinking about the responses to this nugget, especially Jarrod's.

What I'm missing in the whole picture is basically something akin to a polymorphic VI which accepts different inputs differing not only based on Data type (DBL, SGL) but also name (or full TDif that's clearer).

I tried creating a Polymorphic VI last nicht with two different strictly typed Typedefs as input.  Both have data type DBL.  Firstly, the Polymorphic VI was valid (even with two DBL instances) but there was no automatic selection of the second VI on the polymorphic VI list.  If this was possible, my problems would be solved.  It would then be possible to create the front-end for such an overloaded architecture in a polymorphic VI.  The clue is that the Polymorphic VI should NOT allow coercion.  Either an exact match, or no match.  Surely this is possible, even if we may disagree over the usefulness of such an approach.  Personally, I would heartily welcome it.  It truly allows compiler-time catching of data type (Full TD) differences which might break this architecture.

Even though the Visitor pattern outlined by Jarrod goes some way to implementing this, the first step (detection of the specific control which has changed) is still wishy-washy.

My 2c.

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
Message 26 of 51
(3,866 Views)

Re: Community Nugget 06/25/2007

Jarrod,

Can one flatten a Class, save it to a file, load it on a later date, unflatten it and still expect it to be valid?  That would be nice.

I could try it out myself, but lacking in LVOOP, it might take some time....

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
Message 27 of 51
(3,853 Views)

Re: Community Nugget 06/25/2007

Yes you can. Classes even have a way of auto-migrating old versions of themselves to the new versions. So if you've updated your class since you saved class data to file, it should translate itself automatically.

This may bring some new life to the old LabVIEW Datalog VIs, because they handle all this very easily.
Jarrod S.
National Instruments
Message 28 of 51
(3,831 Views)

Re: Community Nugget 06/25/2007

"Classes even have a way of auto-migrating old versions of themselves to the new versions."
 
Now that has perked my interest in LVOOP again!
 
One of the issues I had with saving variants was the possible issues of data types changing with LV upgrades.
 
I have had to write converters for data log files that were the saved versions of a type def'd cluster. When the type def changed, the old files would have been unreadable. So before I changed the type defs, I would save-off a copy of the original version so I could use it in the converter. The converter itself was also a pain to write when the type def had a lot of fields.
 
Ben
0 Kudos
Message 29 of 51
(3,827 Views)

Re: Community Nugget 06/25/2007



@Ben wrote:
 
I have had to write converters for data log files that were the saved versions of a type def'd cluster. When the type def changed, the old files would have been unreadable. So before I changed the type defs, I would save-off a copy of the original version so I could use it in the converter. The converter itself was also a pain to write when the type def had a lot of fields.

Isn't that complicating somthing that's supposed to make life easier (to maintain/scale)?
______________________________________________________________________
0 Kudos
Message 30 of 51
(3,822 Views)