Slight Differences in project for two systems - What is the best solution?

[OSclimb]

I have a project that can fit two systems with only slight differences. (A different Piezo stage to be controlled, and some UI subVIs for saving data).

Till now I have tried to control the differences by naming the VIs the same and on each machine call the VIs from a different folder. This requires to have actually two projects on each machine and to keep synchronize them both. 

I thought to try different approaches:

1. To use the "Conditional Disable Structure" with "Symbol" "Machine" and "Values" {MySys1, MySys2}.

2. To use libraries and change to the right library in each machine (I'm less familiar with this one).

Can you help me decide?

Does someone have other solutions or ideas? 

[Jay14159265]

Do you know in advance which hardware the project will run on our must the software determine that? 

[Bob_Schor]

Can you "isolate" the differences, say by having a routine "Piezo 1" that handles the specific code for one Device, and "Piezo 2" that does the same thing for the other?  Let's say you determine that Piezo needs to respond to a few "commands" -- Initialize, Start, Read (or Write), Stop, Quit.  Make a sub-VI that accepts one of these Commands, and that (inside the sub-VI) initializes the specific Device, keeping the "Task" information in a Shift Register inside the sub-VI so that subsequent commands "know" the Device in use.  Now, if you are really clever, you might make the Initialize "state" figure out which device is connected, but you could also have a parameter passed in with "Initialize" that says "Use Piezo X", which you'd only need to do once, when first called.

As for having slightly different data output requirements, you'd also write a sub-VI that can do either, depending on which Piezo you are using.  This works best of the Inputs (meaning the data coming in) are compatible between the two cases (so it's only a matter of "amount of data", or possibly "formatting").  But this way, you have a single code-base, and at Run Time, you decide which Piezo you are using, and the code takes the appropriate Case.  No need to Diagram Disable.

Bob Schor

[OSclimb]

I know in advance.

[OSclimb]

Thanks Bob_Schor!

I'm not sure how to "isolate" the differences 🤔. I'll try to think if there is a nice way to do it.

I can't use the same basic sub-VI's for the different piezo (One is from PI and the other from Jena...), so I need a different set of them (Move, Stop etc.), the communication protocol is not the same.

Then I can use your suggestion by using a case structure with two cases: "Piezo1" and "Piezo2", and some string variable that can be set at some point in order to choose which case to use, but that brings me back to "Conditional Disable Structure", isn't it?

[santo_13 · Accepted solution]

All the discussions so far tend to scream OOPS with the HAL approach, please correct me if I am missing anything.

https://www.ni.com/en-us/innovations/white-papers/08/addressing-obsolescence-with-hardware-abstracti...

https://www.dmcinfo.com/latest-thinking/blog/id/10056/a-simple-hardware-abstraction-using-labview-oo...

[OSclimb]

Thanks Santhosh!

That is definitely a big gun to kill it all 😅. I guess you are right. specially for the piezo issue. 

I'm not sure I'm ready for it right now, but for the long run I definitely need to use it more.

Would you use it also for differences in UI part of the application?

Lets say I have some saving data window, that pops-up when the user saves the data, with parameters related to the measurements (Sample type, Filters used, etc.) that will be inputs from the user to support the saved data. Now, each system has a different set of parameters, but the rest of the system is identical (at least up to a OOP class 😅). Here I have the opposite situation, I want a different UI that will create the same task (save a csv/txt file with the supporting information). 

[santo_13]

---

@OSclimb wrote:

Thanks Santhosh!

That is definitely a big gun to kill it all 😅. I guess you are right. specially for the piezo issue. 

I'm not sure I'm ready for it right now, but for the long run I definitely need to use it more.

Would you use it also for differences in UI part of the application?

Lets say I have some saving data window, that pops-up when the user saves the data, with parameters related to the measurements (Sample type, Filters used, etc.) that will be inputs from the user to support the saved data. Now, each system has a different set of parameters, but the rest of the system is identical (at least up to a OOP class 😅). Here I have the opposite situation, I want a different UI that will create the same task (save a csv/txt file with the supporting information). 

---

Anywhere you need to code once and change the behaviour based on certain conditions, you would go with OOPS, use the parent class in the implementation, and based on the object passing through the wire, the appropriate child method will be executed. All your requirements can be solved with OOPS in an elegant scalable way.

[Kevin_Price]

I agree with santhosh (as I frequently do) that this is a classic case for classes and OOP.

However, you also stated that you aren't sure you're ready for such a "big gun" for solving your immediate app needs.  So while an OOP approach might be the conventionally *correct* choice, it may not be your own personal *best* choice at the moment.

There *is* a learning curve, both for OOP in general and then also for some of the particulars about LabVIEW's implementation, often referred to around here as LVOOP.   It's a strong tool, but like many tools, best used by those who've already developed the special skills needed to use it.

So if you aren't already at least somewhat comfortable with LVOOP, I think you may be better off in the short run to take an approach you already know how to implement correctly -- such as the case structures sprinkled about here and there where you need to execute different code depending on which hardware config you have.

Along the way, you can start *preparing* yourself for possible future use of LVOOP.   Make a .lvlib LabVIEW library for each of your piezo drivers.  Try to come up with matched sets of API functions for your different piezos.  Give them the same names (the .lvlib will be a necessary part of LabVIEW allowing them to have the same filename) and the same terminal wiring.   Doing this much will march you right up to the front doorstep of actual LVOOP.

-Kevin P