error 85 using Lecroy wavejet 324A

[dave66]

Thanks, it would be great if you could send the modified vi as I am using the USB version on LABVIEW 8.5. I did an even more non-professional version by modifying the error query vi by repeatedly sending *ESR? until I got some data back and then letting scan string do its stuff.

Cheers

[ofmara]

Hi Leonard!!!

I´m using  Lecroy WaveJet 324A with Labview 8.6  I need enable ID query and remove the autosetup in the VI´s lecroy wavejet series acquire: math waveform, waveform, waveform loop; the others VI´s I haven´t seen in detail yet.

Currectly I´m working with acquire waveform and I save the signal with write to measurement file (10kpoints), but it is slow, I´m using USB interface some suggentions to make it more efficient

Best Regards

[Leonard33]

Hi dave66,

Here is your replacement VI for the write.vi.  I am using the project version of the driver so for me, I have to put this vi in the "Private" folder.

Then, you will have to link each vi as you open it to the new write.vi. (LabVIEW will begin searching for the vi and you can browse to it).

Once that is all done, you can save everything and you should be all set.

So, replace the original write.vi with this one, when prompted, browse to it and after everything re-links, save the changes when prompted (it will prompt you when you close a vi, or when you exit LabVIEW).

Let me know if you have any challenges with getting this working and I will get you screen images etc. of each step I did to get everything working.

I did not do a great job with documenting the VI but I tested it and it works with my WaveJet 354A and the USB interface.

[Leonard33]

Hello oframa,

Is the slow down in writing the data to a file?  This is my suspicion, because you are writing 10k points in a single write.  If the points are only 1 byte in length, this is 10k bytes.  If they are in WORD format, this is 20k bytes.

Not a lot but it may speed things up if you were to break up the data and write them in chunks to the file.  I have not had a chance to test anything yet.  I suspect it will not be until Monday when I can get to this.

If I can get to it today, I will post another message and let you know what I discover.

[dave66]

The write.vi you sent me seems to have got me going as far as setting up, timebase, etc. However

Everything seems very slow. I would say at least 1 second to read one measurement parameter. When I dug

around I found two things: (a) the default baud seems to be 9600 so I assume inside the instrument it's

just a UART and not a true USB. However changing this make no difference to the overall speed.  Which leads

to (b) inside the Read.vi there is a 1000ms default only for USB and when you try smaller values as a test

you get back to the original 85 string scan errors. In fact I can write the values down faster than the computer is giving

them back to me which seems too slow.

Cheers

[Leonard33]

Hi Dave66,

Well, I feel really stupid now.  I was looking for the complex solution when the easy one was the way to go.

So, I am not sure why you cannot use a smaller time setting in the Read.vi, I will have to see what I can do about that.

I did some experimenting and I was able to get it down to 796mS.  At 795, it gave me an error.

I threw out the Write.vi I sent you and went back to the original one.  My fix was simply to add this code to the Read.vi:

connect the string to the input of the Match Pattern primitive.  I used a "Not Equal" for code cleanliness. I just wanted to have as few crossing wires as possible.

I was able to use this to get all four measurements and now I do not see the Error 85 anymore.  I will see what I can come up with for the timing to get it working as fast as possible and post something here when I get it done.

If all goes well with my testing for USB and for ENET, I will get it all added to the driver and submit it to NI again.

I hope this helps get you going with some faster results!  Sorry about the stupid Write.vi I created before.  I was trying to come up with a quick fix and I should have stepped back and looked at the issue a little more before jumping at a solution.