Community Nugget 06/25/2007

[shoneill]

The way I see it with "future versions", NI will have to offer something to allow the same capability, whether it's in the form of TDs or not.

Currently, everything works.  How long have NI been telling us not tu use serpdrv, and how long has it lasted?

I see this as a demonstration of something which, in an ideal world, would be inherently supported.  If I have to make an adaptation to another method for identifying data types, or in NI introduces something to support this kind of thing natively, then fine.  That's something I'm willing to undertake.  Chances are, it'll be repalced by something which NI themselves introduce, thus removing the need to even write something new.......

I also programmed in 6.1 for many years after it was no longer "up to date".  This method works all the way back to 6.1 by the way.

My 2c either way.

Shane.

[tst]

BTW, I did do enum+variant based messaging before. In my version, formatting the variant was done by creating a typedef and a stub VI for each action, to force the user into entering the correct data.

Your version is definitely nicer in the sense that it does not limit the user.

[Ben]

The closest I have come to this is a cluster of enum plus string where the string is a flattened data structure that is un-flattened by the recieving agent that is indicated by the enum.

Unfortunately, many of applications require speed rather than re-usability so I seldom have a need to use this type of application.

Ben

[TCPlomp]

---

@K1200LT rider wrote:

I'd love to see Nuggets based on OpenG VIs in the future.  It's freely available to everyone, so why not?

- Brad

---

Jim Kring has written some things about this:
OpenG VIs I couldn't live without

Ton

[shoneill]

Tst,

can you elaborate a bit on your typedef stub approach?

I thought of something like this, and the ability to check correct data at compile time would, in my opinion, be a great advantage.

Is it possible to create polymorphic VIs which accept different DBL typedefs for example?  This way, we can unite data type and name in a pre-compiler approach....... This would then be closer to "proper" overloading.

Shane.

PS If NI is listening..... Native handling of this kind of thing is really the best way forward........  Hide the TDs for what I care, if I don't need the TDs for something like this and there are no (little) speed penalties, then that would be nice.

Message Edited by shoneill on 06-25-2007 11:34 PM

[Jarrod_S.]

---

@shoneill wrote:

PS If NI is listening..... Native handling of this kind of thing is really the best way forward........  Hide the TDs for what I care, if I don't need the TDs for something like this and there are no (little) speed penalties, then that would be nice.

Message Edited by shoneill on 06-25-2007 11:34 PM

---

Best dispatch method I can think of that can be plugged into this scenario is LV Classes. It would require you to encapsulate your command formation and processing into class methods, but once you've done that you have a very efficient approach to passing arbitrary data from your producer loop to the consumer loop. This dispatch method used to determine which override method to call is always constant time, so you don't have to worry about slowdown occurring as your number of messages build up.

Another really nice thing about this beyond performance is that you can encapsulate your actual architecture into a generic base class that you can reuse again and again by simply overriding the generic message protocol with your application-specific implementation.

Message Edited by Jarrod S. on 06-25-2007 05:28 PM

[Jarrod_S.]

There's a cool example you can check out here that illustrates using classes for generic messages and processing them using a generic Do Action method. The example is more geared towards a LVOOP-style functional global, but many of the same ideas could apply here for a Producer Consumer design pattern.

Here's a link explaining some of the design pattern ideas. It's under the section called Visitor Pattern.

[shoneill]

Thanks Jarrod,

Sounds cool, I'll have a look at it tomorrow.

Shane.

[tst]

Here's an example.

The problems:

• You have to use all the parameters (unless you want to create additional VIs or use the defaults).
• You have to use the enum to describe the type so that it can take it apart on the other side. It doesn't do the overloading you do.
• If you send the wrong one, you will get an error.

The main advantage is that it breaks these into modular components. You can use the stub VI on the other side to convert the variant back.

[shoneill]

Jarrod,

This seems to be exactly what I was missing.

Since I have zilch experience in LVOOP, I have two things to learn at the same time (Three actually, since I've never really implemented LV2 globals!).

Seems just the right way to do things.  Can we pass this action class in a queue?  Is this the logical extension to the Producer-Consumer approach with proper (Compile-time error checking) Overloading?

Shane.