LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reentrant execution of Keysight 34465A DMM?

Solved!
Go to solution

Hi,

 

I'm working on controlling couple of 34465A DMMs in parallel (via DQMH cloneable module) but I have realized that the driver VIs are set to non-reentrant execution. This means that however I have the mechanism to perform the measurements in parallel the instruments still take data one-by-one.

 

I have set the instrument driver VIs to reentrant execution and that way everything works fine. The concern I have is that as the driver VIs are in the instr.lib once I move the source code to another PC I need to change all the driver VIs again. Or if later on maybe in years when I have a different PC and I need to change something on the sourcecode I download it from GIT but as the drivers are not included I need to change them to reentrant again (except if I forget it which is certainly an option).

 

What would be the right way to handle this? Should I include the drivers to my project folder and upload it to GIT?

 

thx.

 

 

Found this topic, but it seems irrelevant as neither the low level VIs are reentrant.

 

https://forums.ni.com/t5/LabVIEW/Is-it-possible-advisable-to-make-Agilent-34401-drivers-reentrant/m-...

0 Kudos
Message 1 of 12
(1,586 Views)
Solution
Accepted by topic author 1984

The best option is to bring the driver under your project control - in the sense, it can still reside under instr.lib but not the base driver from the mfr but your modified one.

For any driver updates, it has to go through you, you get the latest driver from mfr and then make all modifications and redistribute it within your company/group. This way you can guarantee that the drivers installed on your deployed systems are under your control.

 

Many times I have handled in a similar fashion, sometimes even develop from scratch for the custom merged functionalities.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 2 of 12
(1,574 Views)

This is one of the reasons I always make my own drivers.  I don't like being dependent on external libraries unless they bring a huge benefit.  Generally, instrument drivers do not bring enough benefit (they are generally super easy to make myself).


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 3 of 12
(1,566 Views)

@crossrulz wrote:

This is one of the reasons I always make my own drivers.  I don't like being dependent on external libraries unless they bring a huge benefit.  Generally, instrument drivers do not bring enough benefit (they are generally super easy to make myself).


Our level of experience is certainly different but I dont see how making drivers on your own is super easy. It requires (at least) a pretty careful reading of the documentation and then the implementation and testing. This could take fair amount of time even with a relatively simple instrument as the 34465 and certainly takes days on more complex instruments (eg with a scope).

 

Normally I don't have problems with the official drivers, so I dont see what would be the value writing it on my own. (in this particular case I do have a problem with the official driver, but I have downloaded probably 100+ drivers over the past 15 years and I can't recall any major issue)

0 Kudos
Message 4 of 12
(1,561 Views)

@1984 wrote:

@crossrulz wrote:

This is one of the reasons I always make my own drivers.  I don't like being dependent on external libraries unless they bring a huge benefit.  Generally, instrument drivers do not bring enough benefit (they are generally super easy to make myself).


Our level of experience is certainly different but I dont see how making drivers on your own is super easy. It requires (at least) a pretty careful reading of the documentation and then the implementation and testing. This could take fair amount of time even with a relatively simple instrument as the 34465 and certainly takes days on more complex instruments (eg with a scope).

 

Normally I don't have problems with the official drivers, so I dont see what would be the value writing it on my own. (in this particular case I do have a problem with the official driver, but I have downloaded probably 100+ drivers over the past 15 years and I can't recall any major issue)


While I haven't used as many drivers as you over the years I can say that many of the ones I have downloaded are written terribly. The code is generally a mess and I don't have lots of confidence in them. I had a CAN driver once that was a real hot mess. There was no rhyme or reason to their connector panes which meant as you used several VIs in series you couldn't help but have all kinds of bends in the wires. When I see code like I am genuinely concerned about have reliable it is. More often then not I have rolled my own. It generally doesn't take much time. I also try to make good use of classes so it is easier for me to swap instruments in the future.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 5 of 12
(1,551 Views)

General advice is you be the judge, we provide the arguments to weigh the decision.

 

I agree with your take on you have to spend time on it, it may be significant or insignificant, it depends on the user base and impact it creates. If your organization is large enough and only one engineers takes the effort for all the other 100s of engineers, then it is beneficial for the org.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 6 of 12
(1,549 Views)

I have to go with crossrulz on this this.

I don't think I've ever used a manufacturer driver apart from if it's in a dll and can't be re-written in LabVIEW since before 2008.

The main reasons are:
PSUs use pretty much the same commands (same for DMMs etc)
the manufacturers fill the drivers with horrible stuff on more advanced insturments (and even some of the basic ones) - so you think you've sent 3 commands and you've actually sent 10 becuase they assumed you would want to send another series of commands - therby undoing your careful instrument setup.
If you write your own driver, you can scan for invalid params on input and kick them back (the maunfacturers dont do this and kick it out of the instrument or set it up incorrectly instead - but you can test a system configuration without H/W if you write your own drivers. makes full system test and simulation very much easier.

You're own drivers is also very useful - It has caught out OEMs updating the F/W in the past and changing the way calculations are done on a customer system and invalidating a whole medical test system until the OEM fixed their F/W (using the OEM driver would not have caught that!)

 

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 7 of 12
(1,529 Views)

Edit:

 

Misread the original post.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 8 of 12
(1,509 Views)

Thx everybody for the useful insights.

0 Kudos
Message 9 of 12
(1,489 Views)

@James_W wrote:

You're own drivers is also very useful - It has caught out OEMs updating the F/W in the past and changing the way calculations are done on a customer system and invalidating a whole medical test system until the OEM fixed their F/W (using the OEM driver would not have caught that!)


Last year, I ran into sort of the opposite problem: the OEM driver broke due to an OEM firmware update.  Luckily, I was only using the OEM driver as an example as I developed my own driver.


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
0 Kudos
Message 10 of 12
(1,483 Views)