Agilent U2000 Series Acquire Measurement example - LabVIEW gets stuck

[Troy]

Take a look at this modified example and give this a try.  I basically changed the VI to "take apart" the Read Measurement VI.  I took out the Initiate (Continuous) VIs and place them outside the while loop.  Inside the while loop I placed the Fetch Measurement.VI.  This is how I retrieve the measurement data on my application using my own "drivers".  Let me know if this works on your U2000. 

I suspect that the repeated continuous on/off and psuedo OpComplete check are causing the meter to struggle.  That configuration is not how the meter should be run when trying to read continuous measurements.

This is a good example of NI Examples and drivers not being fully suitable for all occasions.  I run into this fairly often.  With the newer plug and play project style drivers, NI has done a good job of breaking up functions so that it is easier to create a application specific VI.

[Arkady_V]

Troy,

I tried your example, it doesn't make the system freeze, and that's a good point. It also has a bad point - the Fetch function fetches just one value, although it's doing it in a loop, but the value never changes. And usually it's incorrect. But I like the idea, I feel that it's one step from a working solution.

[Troy]

Let me look into that again.  I started last night but my PC has a corrupt MAX database (among other problems).  I will step out into the lab this morning and see if I can fix the issue.  I made the change to the example without actually testing it (so of course it will have problems). 

In the mean time, I have attached the project with the app I developed.  I did this mostly as an excersice in UI development, but it is functional.  This was developed for the U2004A originally, so I updated the device find to look for the U2000A.  Hopefully this works with your meter.  If it doesn't, you can take out the ID check located in the "Find USB Meter.vi".

[Arkady_V]

Troy,

Your front panel is fantastic, and my knowledge of LabVIEW is not good enough even to properly decompose it and understand how you customised the standard controls/indicators to look so fancy. Setting up and reading is working perfectly. Actually I have my own not-so-fancy version of Power Panel where I utilize the same idea with small variations, e.g. I use single sweep mode instead of continuous sweeping that seems working slightly faster.

But I still want the project style drivers to work properly. It's not this difficult to control any device using SCPI commands, but you need to have manuals available and still consider proper syntax etc, when LabVIEW is supposed make this part easier.

[Troy · Accepted solution]

Thanks for the compliment on the panel.  It took me a bit to figure out how to do it.  Got several of the ideas from some of the UI ideas in the community. 

As for the drivers working properly, I too wish they were a bit more universal.  NI has gotten much better with the project style of drivers, but I still feel they combine too many functions into one VI, which can be problematic.  Also, they cannot test their drivers over all versions of the hardware the driver is supposed to support, and that occasionally leads to bugs (which is what is happening here).

I too strive to use the NI drivers as much as I can.  When I get into a situation where I need best speed or reliability I tend to write my own as I can optomize the command set to suit.  I just don't like sending commands to the equipment that have no relavance to the function I need.  This is recently proving to be true for Agilent USB based hardware.  I am beginning to think their USB interfaces are not that robust (nothing like LAN or GPIB). 

I was able to fix the example piece to run on my U2004A meter (code attached).  I had to change several settings from the example (see the notes in the block diagram).  The one that stumps me at the moment is I had to set the average buffer size to zero to get things to work.  Apparently there is a syntax error or something with the command set that causes a -113 incorrect header error when the buffer size is >0.  I don't really have time at the moment to troubleshoot NI's driver, but I am sure they would appreciate the feedback. 

This version also seems to have an anoying problem of pausing every few seconds.  Not sure what that is.  I remember seeing this before when I put together the other app, but don't recall off the top of my head what the cause was.  This should give you a good starting point.

[Arkady_V]

Troy,

The last example is working pretty well, and with my U2000A I hardly notice any pauses. Yes, the settings are somewhat sensitive, this averaging buffer set to 0 is weird, and that means that in order to average I will need to do it programmatically. And also you needed to disable automatic gate feed, set trigger to immediate instead of internal. But Ok, it's working, I can accept it as an interim solution while I'm waiting for NI to fix the drivers. I'll send the link to your example to the NI engineer who is working on my request, hopefully it will help.

Thank you again!

[Charles.Tac]

Hello Arkday_V,

Thanks for post it here and I am glad that you have figured it out by yourself.

Recently, NI has updated the driver to fix this issue. Please have a try and let me know if there is anything else we can help.

http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=AAE5F020E3B76F1CE0440021287E6E...

Thanks,

Charles