LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

duplicate driver lvlib

Solved!
Go to solution

Hello, my question is regarding to HW handling "best practice".

I have a LV project which connects (beside other things) to a MKS PR4000 control station (this is a digital PSU and readout/controller device for pressure sensors and flow controllers).

So far I have 2 flow controller units connected to this PR4000 unit. My PC (and my LV project) connects to the PR4000 via RS232. I got the drivers from NI website for the PR4000, all work just fine.

For easy project handling I have created my own drivers based on the official drivers, only including those features which I need.

I put these drivers into a lvlib library under the project tree. I have an ActionEngine (scope is private), and some wrapper VIs (scope public) to be able to set all inputs as "required" on the connector pane, and to hide the reference, etc. wires inside these wrappers. Also it is nice that all the lvlib public VIs have the same colour, easy to find them in my main block diagram.

 

lvlib_PR4000_scrshot.png

 

My question: later on I will need to extend my experimental rig: I will deploy an additional PR4000 unit (and connect to the PC via USB-RS232 cable, since the native RS232 is already occupied). What is the "orthodox" way to use independently the same drivers for this second PR4000 unit? Since I have already implemented the LVLIB for this HW unit, can I just duplicate the PR4000 lvlib under the project tree? So I would have two lvlib under the project tree: lets say PR4000_1.lvlib and PR4000_2.lvlib. I could set a different colour for the second lvlib, and apply it to the VIs, so I could easily distinguish between the public VIs which will have same names. So is this the usual way to proceed?

Thanks for advice!

Regards,

0 Kudos
Message 1 of 4
(2,869 Views)
Solution
Accepted by topic author Blokk

Yes, that would work. Do 'save as' on the lvlib to a different directory and you should get a copy of all of the VIs and a new .lvlib file with a different name.

 

Think about this though, what would you do if you suddenly had to add 10 of the devices? Would you make 10 copies of the lvlib? What would you do if you then discovered that there was a mistake in your VI - you would need to update all 10 copies of the VI!

 

A better practice would be to modify your action engine to store multiple device references (e.g. indexed by name (variant attributes are good for this) or by number).

 

I think best practice is for your 'driver' to be independent of your hardware references - so have your driver VIs with the references fed in by wire and then handle maintaining those references outside of your driver lvlib - I usually store them in shift registers in my application. There is a slightly more advanced version of that uses DVRs to store your hardware references.


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 2 of 4
(2,852 Views)

Thanks for the very useful hints!

0 Kudos
Message 3 of 4
(2,844 Views)

What I have done in a similar situation was have the Action Engine store all of the references and a name associated with those references.  So part of the AE is to lookup which unit you are controller and pass out that reference.  This works extremely well in a TestStand situation.  In a pure LabVIEW architecture, I would not use the ActionEngine and just pass around your reference.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 4 of 4
(2,840 Views)