What would be the best design pattern for this application?

[cireyellamo]

Greetings.  I am working on an application for testing of a family of products.  It is somewhat complicated to describe, so I will try to keep it as brief as possible.

I have a 4-slot cDAQ chassis with 3-AI (2 voltage 1 current) modules and 1 relay module.  The main application will read from a test script file (probably tab delimited text) and then launch a test panel.  The test panel will execute the test script, which will require it to measure the DAQ inputs and/or set the relay states.  There can also be a "virtual oscilloscope" which will constantly display a PWM waveform (130Hz) while the test panel is open.

I'm thinking a QMH of some sort might be best for this.  I was looking in to OOP for LabVIEW, and, while it looks particularly useful, I am not very well versed in it to determine if this is a good fit for my application.

I'm one of two LabVIEW programmers in my company, and the other isn't really that serious about it, so I don't really have anyone to bounce ideas like this off of.  I appreciate any advise the community has to offer.

Best regards,
Eric

[BonbonBLou]

If you're not experienced in OOP for Labview and you're probably not going to do something similar again, then I would stick with a QMH.

OOP is best used when you are going to reuse code lots of times i.e for creating drivers.

I would stick with a QMH, that seems like the simplest way imo.

[Paul_F-MCP]

I'm probably not the best person to make suggestions because I have yet to get over the hurdle of understanding OOP and finding anything that's worthwhile implementing it for - this is a bit chicken and egg I guess in that I need the undertsanding to be able to properly evaluate the benefits.

If I were implementing this though I would use a Producer/Consumer pattern but with a state machine in the producer loop to handle the initialisation from the script, set up of the acquisition etc.

Regards

Paul

[crossrulz]

---

PaulCPT wrote:

If I were implementing this though I would use a Producer/Consumer pattern but with a state machine in the producer loop to handle the initialisation from the script, set up of the acquisition etc.

---

And you just described the Queued Message Handler...

[moderator1983]

---

@cireyellamo wrote:

I'm one of two LabVIEW programmers in my company, and the other isn't really that serious about it...

---

That's cool... Is there any opening in the organization for a serious LabVIEW programmer 

[cireyellamo]

Thank you all for your input.  

I too have yet to overcome the OOP hurdle.  I'm slowly going through the online training through my SSP but have yet to come up with anywhere that I can actually use it.  Not to mention the ton of other things to do (LabVIEW programming is unfortunately not my full-time responsibilty here) which prevents me from .  That said, I think I'll proceed with the QMH. 

As far as the queue setup is concerned, what are the general best practices to determine how many you need and what data it contains?  I haven't set one of these up from scratch yet (haven't really needed to - a lot of the code I work with was inherited from when it was written in LabVIEW 5.1) so it would be nice to know what the community does in these kinda of cases.

Oh, and moderator1983, unfortunately, no openings.  I'd love to actually work with a good team instead of doing everything solo.  I just don't think we do enough LabVIEW here to warrant it.  We'll see what the future holds...

Thanks again,

Eric

[cireyellamo]

---

@vascibean wrote:

OOP is best used when you are going to reuse code lots of times i.e for creating drivers.

---

One thing that is part of this project is to create a Power Supply control interface.  Get/Set Voltage/Current, Turn ON/OFF, etc.  I was just going to do a .lvlib for it, though.

[crossrulz]

---

@cireyellamo wrote:

---

@vascibean wrote:

OOP is best used when you are going to reuse code lots of times i.e for creating drivers.

---

One thing that is part of this project is to create a Power Supply control interface.  Get/Set Voltage/Current, Turn ON/OFF, etc.  I was just going to do a .lvlib for it, though.

---

I did some power supply drivers that way a few years ago.  About a year later, I really wish I understood the OOP because it would have saved me some headache.  I was able to work around it, but I plan to rewrite those drivers using OOP.

As far as good examples of the QMH, try to look at the LabVIEW Core 3 course.  That architecture is used (assuming they haven't changed it on me in the last couple of years).

[billko]

I saw a really neat graphic in my LabVIEW Core 3 stuff that simplifies the decision-making process by turning it into a flowchart based on requirements, but I'm not sure I have permission to reproduce it.

[cireyellamo]

@billko wrote:

I saw a really neat graphic in my LabVIEW Core 3 stuff that simplifies the decision-making process by turning it into a flowchart based on requirements, but I'm not sure I have permission to reproduce it.

---

Nice, I'll have to look in to that.  Any idea wich module it is contained in?