Reentrant execution of Keysight 34465A DMM?

[1984]

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-...

[santo_13 · Accepted solution]

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.

[crossrulz]

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).

[1984]

---

@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)

[Mark_Yedinak]

---

@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.

[santo_13]

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.

[James_W]

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

[billko]

Edit:

Misread the original post.

[1984]

Thx everybody for the useful insights.

[crossrulz]

---

@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.