VISA Write Error with Agilent 34401A DMM Error Code -1073807339

[malanskas]

I am connected to a HP34401A and a SR630 over GPIB. I can initialize and configure both devices successfully. When I run on my dev station, my program works as expected. I can log data, read measurements, and end the program once all data is read. Once I install it onto the computer where the testing will happen, I get a VISA error in the Agilent 34401.lvlib with the following error message. VISA Write in Agilent 34401.lvlib:Configure Trigger.vi-> Agilent 34401.lvlib:Read (Single Point).vi-> Thermocouple Data Logger.vi.

Any help is appreciated as the problem seems to be with the driver for the DMM.

[Albert.Geven]

Hello

It could be a race condtion that only occurs in the exe file.

Can you give short description of what the program is supposed to do?

The bock diagram is a bit big for my system, but probablly ok. 

And handy to know the error message including the error code.

[Albert.Geven]

Hi

I replaced almost all, but should have replaced all "Wait Until Next ms Multiple" by "Wait ms". 

You probably did not learn that "Wait Until Next ms Multiple " sometimes does wait a very short time. In fact it can be almost zero ms if the next Multiple of the ms is close by. In a for loop it then waits the first time a short time and all other loops (if the loop is shorter) the speciifed time.

So you probably had somewhere a too short time, and sometimes it could be running OK.

Also you use a lot of uneccessary local variables and I did my best but stopped optimizing after I changed several of them.

HAve a look at what I cleaned up and if you have some questions, your welcome.

[cstorey]

Eek, that program needs some dataflow help!  It looks like it could easily be a state machine, but then it became a sequence inside an event structure.

Since you use time delays employing "Wait untll next ms multiple" its quite possible your testing computer isn't waiting as long as your development pc and timing is the problem.  You could use in-line time delays to be sure that's not the problem.

To quickly debug look at highlight execution.  It's not clear that the error you report doesn't occur earlier in your program and you just aren't catching it until the read loop.  

Some other suggestions.

 - take the instrument initialization outside the main loop.  I don't see where you terminate communications, but you should also do that as good housekeeping.

- use an Error Querry for the SR630 after configuring the channels.

- get rid of all those local variables

- use a button event rather than a keypress?

Look at implementing a true state machine design with states like "initialize, wait for key/button (idle), measure, error, close"  

Hope that helps.

Craig

[Albert.Geven]

Your comment is exactly what I tried to show.

But let start slowly, first get it working and than better.

I already removed a lot of locals but it is clear the style is not yet good enough.

[cstorey]

@Albert.Geven - Agreed, you did a nice job cleaning up the OPs code and it should now be easy to debug.  I think I must have missed your update while I was studying the initial VI.

[Albert.Geven]

Thanks

I'm thinking about building a small state machine example tomorrow.

[Albert.Geven]

Hi

I have the small state machine attached to this post.

It is not tested ery well and maybe a few timings are not yet OK.

Also the file writing is different and can be wrong.

If you can send me a measurement file I can build in a simulation mode that should generate the same file.

But you  can learn how to use a state machine instead of a big big block diagram.

I also added a read SR630 databuffer instead of using an intermediate file.

And you "need" the type definition of the states.

If you like a bit more of the philosophy, I will add thoat in a few days.

[malanskas]

Could you write this in LabVIEW 2017?

[Albert.Geven]

As far as I know I did.

Which version do you see?

And please add a measured file.