LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Community Nugget 06/25/2007

Great nugget and I look forward to the comparison to LVOOP.

But as the ancient here, I have to correct the history. UNIX was not developed on a PDP 11/70 it predates that machine by a lot. I think the first version of UNIX was developed on the PDP 5 or PDP 6.

To keep my title of "ancient", I must say that I have programmed and played spcwr on a PDP-1X system.

-Scott

LabVIEW ChampionLabVIEW Channel Wires

Message 41 of 51
(3,567 Views)
To add to what Jarrod waid about flattening and unflattening Classes....

It seems that there's more saved than the binary representation of the data within the class.  Otherwise, it would not be possible to know what the "old" class had for data.  It may no longer exist by the time the file is being read.  This means that the information must be in the fflattened string.

My guess is that the TD for the control (including name) is being saved (or whatever NI have replaced the TD with nowadays).  Then, you have not only the binary data, but a descriptor.  Kind of like non-ascii XML if you want.  It's then easy to say, this piece goes there, this piece goes here, and this piece doesn't exist any more, it'll be deleted and so on.

This interpretation of data based on full TD is exactly what I was doing, albeit most likely in a less elegant way.

I've jsut started working my way into classes, and I love "Dynamic dispatch".  I'd also love exactly the same thing for Typedefs.  I want a control I can place on a Front panel, wire up to a function and to have the function automatically execute a method "registered" for that exact typedef (such as entering that value into a pre-defined cluster).  Replace the control with another Typedef, and the code called updates.....  How and where the "registration" takes place, I dunno.  Maybe even statically within the VI being called, thus providing strict limits to accepted typedefs.

Am I way off on my own in thinking this would be a great thing for UIs?  This would give us compile-time type error checking for the method I've essentially outlined in this nugget.....

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

My goodness, I feel as though I have stumbled onto gold reading this thread. Great nugget Shane!

I look forward to Jarrod/NIs responses in future nuggets/whitepapers/NiWeek Sessions?

0 Kudos
Message 43 of 51
(3,301 Views)
Shane,

If you're looking for a blend of LVOOP and front panel display, I believe your best option would be an XControl that displays the inputs you desire, but whose datatype is actually a class. That would give you the dispatch functionality you're looking for. Then just have all possible selections for the function you want be class methods of classes that inherit from the same base class.

It's a bit more work than just working with type-defs, because you'd have to program the functionality of the XControl yourself, and unfortunately XControls don't have any notion of inheritance, so each class would have to have their own specific control. But if all the controls are similar, they can share a great deal of the code.
Jarrod S.
National Instruments
Message 44 of 51
(3,283 Views)
"an XControl that displays the inputs you desire, but whose datatype is actually a class."

Good news or bad news.....

Good news is that this sounds VERY promising, but isn't creating an XControl rather time-consuming?  I wouldn't want to have to do that for 10+ controls within a project.  Having said that, I haven't started teaching myself Xcontrols yet. (I've heard they're rather complicated).  I'll have to have a look at these newfangled XControls.

Bad news: I sometimes feel like I'm being punished for programming in 6.1 for so long.  There's so much more in LV 8.2.1 that it's a bit Overwhelming at times.  Does anyone actually get to master ALL areas of LV programming? (Apart from Dennis of course 😉 )

Thanks for the response.  I'll maybe post an update of the nugget if I get this scheme working.

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 45 of 51
(3,271 Views)
I just tried out saving a class in a binary file, then loading it, and that works great.  What doesnt work is changing the datatype of the class around (I added a numeric in the front of it) then trying to reload the original class.  I was saddened by this, because it would have been really sweet to be able to load up old versions of classes (we have a DB app that we know we will need to update some day with a new item, and if we could do it in lvoop that way, we would jump at it.)
 
Just for reference, I am using 8.2
0 Kudos
Message 46 of 51
(2,932 Views)
I have to say I really like LVOOP in the producer consumer model.  I use a lot of that type of model, and using classes here is incredibly powerful.  I made a queue of classes like the picture below:
 
 
AWESOME.  We have a ploymorphic queue that passes data from producer to consumer without ever duplicating memory space as far as I can tell.  I have a big set of inherited classes that can interchangably be passed on the same queue.   This is killer in a state machine that implements the producer/consumer model.  This is massively better than an enum/variant combo because you can just call polymorphic class methods instead of having case structures all over the place.  Plus you don't duplicate memory space in LVOOP method vi's, so you can have huge amounts of data passed around essentially by reference, seldom duplicating memory.
 
By the way,  Jarrod, I don't see how classes can possibly decipher the flattened string to an updated class datatype.  There is no way the clas could know how it changed or how to map the old data to the new datatype.  If a typedef can't do it I don't see how a class can.
-Devin
I got 99 problems but 8.6 ain't one.
Message 47 of 51
(2,932 Views)


@billings11 wrote:
 
By the way,  Jarrod, I don't see how classes can possibly decipher the flattened string to an updated class datatype.  There is no way the clas could know how it changed or how to map the old data to the new datatype.  If a typedef can't do it I don't see how a class can.


Refer to my guess about the underlying methodology on page 4 of this post,  from 06-28-2007 10:11 AM. Typedef changes can maintain data in certain situations, just not with regards to unflattening old data. I believe the same mechanism is at work with LVOOP. If you really don't believe me, try it! 🙂

And glad to hear you're having success with classes in the Producer/Consumer design pattern!
Jarrod S.
National Instruments
0 Kudos
Message 48 of 51
(2,917 Views)

Jarrod,

I know what you are implying.  In certain situations it can decode flattened data properly without an error even when the data type has changed slightly.  For example, new elements can be added to an U8 enum and the flattened data will still work fine.  You aren't really changing the datatype there though since it is still a U8.  But if you added entire controls to a typedef or class data type, it will probably error.  I know with a typedef if you add any new control to a cluster it errors when you do flattened string to data.  So I'm sure the same is true for classes.

 

Even if there are certain conditions where it doesn't error and actually manages to decode teh string properly, since we have no way of knowing the exact rulesets for this, we have to assume we are going to get an error if we change the class.

Message Edited by billings11 on 07-25-2007 01:49 PM

-Devin
I got 99 problems but 8.6 ain't one.
0 Kudos
Message 49 of 51
(2,913 Views)
Give it a try. I've successfully added controls to my class data, renamed controls, reordered controls, etc. I'm sure there is some limit to what data can successfully be handled. If you deleted all your existing class data controls and replaced them with entirely different ones, then I wouldn't expect much of the old flattened data to survive. But a great deal of situations can successfully be handled.

There's actually a shipping example for LV 8.2 that I mentioned in a previous post that can walk you through all the steps needed to prove that this does indeed work. It's called Read Write Class Data to File, and can be found in the Object-Oriented section of the Example Finder.
Jarrod S.
National Instruments
0 Kudos
Message 50 of 51
(2,903 Views)