crelf

The worst time to read a book in a bad situation IMHO is Catch 22. I was working at a crappy job at the time. Made me feel hopeless... It's a good book, I read it at the wrong time..

I stumbled across that book about a week ago and was about to start readin it. Lucky my job is awesome

One for the holidays: http://www.instructables.com/id/Flamethrowing-Jack-O-Lantern/

The first thing this illustrates is that I use a lot of LVOOP objects, of more than one type, and a little thing that says "OBJ" really isn't that useful for easily identifying the object.

*Exactly*! If the icon shows something useful (other than just the datatype, which is shown on the terminals anyway) then it's often appropriate to show the icon.

After I got the PO together for the Safir version, my boss tells me we may be switching to PostgreSQL, and BAM, I am back to square one.

So do you get to put a new PO together for your boss wasting your time?

I usually use the small terminals, although I'll sometimes use icons for typedefs (because the typedef's icon is shown). This works equally as well for cluster icons on the BD that are typedefs. So I guess you could put me down for my usual "it depends" half vote yes, half vote no.

Just because you use a class, doesn't make your program an object oriented design any more than passing a value from one function to another makes it dataflow.

Sure, but my point was that your whole application doesn't have to be completed OO for you to be using OO. Two of the most powerful things about OO is encapsulation and instantiation, which you could be doing without really thinking about it. I like to give these examples (DAQmx, Config File VIs) to help people ease into OO.

I found this property node can set the instance index.

That's kinda neat

My team answered NO...

Yeah, I'd tend to agree.

Oh, and the 2nd edition of "LabVIEW: Advanced Programming Techniques" is from 2006. Do you think they're working on a third edition??

No, that sounds about right. I might have to get my hands on a copy. I thought the first edition was quite good - am looking forward to seeing what they came up with in the 2nd.

The OOP aproach is less interesting with the loss of dinamic dispatch, but it keeps the interest of encapsulation...

Right, but is encapsulation enough to go that route when the inheritance makes it awesome?

I have LabVIEW: Advanced Programming Techniques, but it's the 2001 version. I'll see if I can get ahold of a copy of the newer version.

There's a newer version? I'd heard that they were working on it, but didn't know it was published.

If the OOP course was ever offered in the DC area, I would take it (ditto Advanced Architectures).

I'd tlak to your local DSM, or maybe even ping some trainers directly (Nancy Hollenback and David Corney spring to mind) - my understanding is that if you can get a minimum number for a course, NI will teach it (hey, that's how Nancy got a week in sunny Sydney about 8 years ago, when she taught me the Advanced Course).

My initial plan is OOP Factory pattern for IVI like instrument driver has similar interface and new child class when new instrument added or replacement, it's easy to add new "NO IVI compatible" instrument but need more work, but if IVI and in future must use the "NO IVI compatible" instrument seems a lot work to do to modify the exist work?

Hmmmm - in that case, I guess you could start by creating LVOOP drivers that wrap the IVI functions, and if you get a new instrument that isn't IVI compatible, you can clone the driver class to a new instrument specific driver. You might even want to implement this with inheritance: have a parent that has all of the IVI functions in it, and only override a method in a child class if the parent doesn't do what you want. This might actually work... Oh, except that TestStand doesn't support LVOOP dynamic dispatch I guess you'd need to wrap it in another class...

both have some pros & cons

Maybe *you* should start by telling us what you think they are?

I'm a big fan of IVI - as abso said, it's there already, which has big advantages in that it's supported across several instruments classes and by a foundation that's thought through the architecture much more deeply that I would. Also, it's off-the-shelf and already tested by many people in many ways.

That being said the cons I see of IVI is when your instrument doesn't support the IVI standard(s). For example: some hardware vendors will make instruments that are IVI "compatible", in that you can talk to them using IVI drivers, but their setup might require a custom step to put the device into a mode where it'll respond. Or all of the IVI methods work, except for the one you need. Also, if the instrument isn't supported at all, then IVI doesn't make sense.

In summary: I suggest you don't make this a blanket choice between IVI or a custom applied OOP pattern, I'd choose IVI everywhere you can, and backfill with custom code where you can't.

I don't do OOP

You ever used DAQmx? Ever read keys out of an ini file using the VIs in vi.lib? I'm guessing you do do* OOP, just without knowing about it.

* wow - "POOP" and "do do" in the same thread - real mature LAVA!

That's true - I realized after writing that post that you can always increase or decrease scope and eventually you'll be able to coin something as "hygienic."

We're stilling talking about programming, right?

Off the top of my head, any VI that calls to hardware (particularly for measurement or I/O) or any VI expressly written to return data that is either time-sensitive (e.g., salted hash) or random in nature seems like it would qualify as non-hygienic.

It depends on whether you call what is essentially a reference call to something during execution (the DAQmx reference is, for all intents and purposes, the same, but the data it represents isn't). If you take your definition of hygenic, that would mean any calls by reference to an external data item in any programming language would make it non-hygenic.

Anyway, we're getting away from the classic definition of hygenic programming, which refers only to macros, or code portions - I think attempting to apply it to a whole programming language in the context of trying to determine if a programming language is hygenic is misguided and of no value, which is why Daklu said that only a pure dataflow programming language can be considered hygenic. I, for one, am glad LabVIEW isn't hygenic. Wait, that didn't come out right...

new-> VI for override...

Right - unless your method is already child or isn't going to be part of an inheritance scheme, and that's called method cloning (which is not supported in native LVOOP, but is with jgcode's LVOOP Assistant and Endevo's GDS).

Even after doing FFT it shows time domain graph.

It shouldn't - can you post an example?

Clearly it is possible to create non-hygienic functions in G...

How? I'm interested in hearing the options...

I wired the output of the boolean array with a property node "val(signl)" linked with the "switches" indicator that was inside the event structure

Yep - that'll work nicely - good job.

While playing around with the codes limits I noticed that if the boolean array is longer than 32 elements/switches then the code does not display the change of the booleans (numbered from 33 and above) in the graph.

I don't have the code in front of me, but maybe the conversion to number (to decide which Boolean has transitioned from false to true) is set to only I32?

Thank you for the help!

My pleasure

I have an issue though...If the "switches" control becomes and indicator, then the vi does not work! (see picture here http://imageshack.us...eindicator.jpg/)

Right - the code I gave you is a place to get started - you need to work out how to put it into your higher-level application. Hint: the event structure acts when the switches array is changed, so you can't use that: try keeping the state of your switches indicator in a shift register, and comparing that with the new value to get your two Boolean arrays. Another option is to use the OpenG "Changed?" VI to select whether to execute my code or not.

Isn't a reference simply another piece of data? It's not business data (stuff the end user cares about,) but it is information that needs to be managed within the application. That's how I look at it anyway. *shrug*

Yes, that's why I added the at the end of that sentance.

In reality, LabVIEW will optimize as much as possible of this copying, but fundamentally every wire branch should be viewed as copying data.

Unless it's a reference - and even then it's still a *copy* of the reference

(It might be easier to learn a little about OOP.) You're right, it's nontrivial to get started with OOP. I wouldn't go back, though!

C'mon Cat, jump into OOP! The NI OOP course is quite good (based on Endevo's course), and once you "get it", you'll never go back.

Otherwise, LabVIEW: Advanced Programming Techniques and LabVIEW for Everyone have some good stuff in them, but you're really limiting yourself by shunning OO.

Specifically that branching a wire into a DVR Create node will always create a copy of the data? That's counter-intuitive to what I expect when I think of creating a reference.

Well, it really is intuative, as you're creating a reference on a wire that is already a copy of the original: the bottom line is that the copy is created when you branched the wire - even before it went into the DVR create. That's why you have a reference to a copy - because that's what you actually asked it to do.