GPIB-USB transferring speed problem

[vgbraymond]

Hi 

I have attached a NI Spy file.

I am using a NI GPIB-USB to control a Flash-ADC board. In my spy file I was trying to keep check trigger arrivial by sending 2 GPIB-write to write commands and sending 1 GPIB-read to read feedback. Whenever it reads the last bit of receiving data as "1", the FADC board receive a signal. I put this in a while loop looping for 100 times.

My question is, from what I see in the Spy file, in the time column, 6-7 commands were sent nearly at a same time, and then another 6-7 commands were sent also at a same time, however the two were always separated by around 15 or 16ms. It looks like a pattern to me. Why is there such a pattern? 

Actually my intention is to make the whole process finished as quickly as possible. It looks to me that it's possible to run 6 commands with in 1ms and it looks to me that that 15-16ms separation is avoidable if I find out why it is.

My second question is - not foundable in this spy file - that when I try to receive a data block of 20504 bytes via the same GPIB-USB , it takes me ~31ms, is that a normal speed?

Many thanks to your help!

Raymond

[NateBraska]

Hi Raymond,

I am trying to replicate your issue but am having a bit of trouble with it. Can you elaborate on the reading and writing commands that you are using? I have heard about groups of commands being repeated in a set pattern similar to this, and most resources I have checked seem to indicate that it is due to Windows.

I would like to get more in depth with your specific setup to allow me to replicate it.

Regards,

Nathan B

Applications Engineer

National Instruments

[vgbraymond]

Hi Nathan,

  Thanks so much for your time. I have attached that part of code in the FADC_Code.vi and also made a screen capture of it. Would you need more information please tell me.

[vgbraymond]

Forgot to mention, in the FADC_Code.vi, I included a complete set of read/write to perform a readout in the FADC. However, only, in the while loop inside the time sequence, the first write (Start acquisition) and then the second write (Interrupt) and first read inside the inner while loop are relevant to what I saw in the NI spy that attached before.

For your information, the frist frame in the time sequence is a Get Date Time and the same in the third frame, I did a subtraction to know how much time I spent in the Read/Write process.

[vgbraymond]

Hi would there be any idea of what's the problem?

[Jacob_K]

One of your problems is that you are not properly initializing the visa commands.  Here is a link to a great tutorial about how to use NI-VISA:

http://zone.ni.com/devzone/cda/tut/p/id/3702

Fix these commands and see if that helps.

Jacob K

[vgbraymond]

Hi Jacob,

  I have been using the GPIB palette to do all GPIB's work. I havn't shown on my capture but I did do a GPIB initialization. I use all the default values so I havn't connected anything to the GPIB initialization except that I connected its error output.

  Would this be a problem?

  It's worthwhile to try the VISA read/write. However I have a question, can I just simple put what I put into the GPIB subVI into the VISA read/write subVI? I doubt this as I think those GPIB subVI has done for me a lot of low level works, while VISA won't. Am I right?

Raymond

[Matt.M]

Hi Raymond,

The reason there is spacing between your GPIB communication is because Windows is not a determinant system.  The operating system allots time to each task that is running, and then switches between the different task.  The amount of time given to a task can change, which is why sometimes 6 commands are sent, and sometimes 7 are sent.

For your second question, that transfer calculates to about .6 MB/s...488.1 supports up to 1.8MB/s, but a transfer rate of .6MB/s is good.

Regards,

Matt M.

[vgbraymond]

Hi Matt,

  Thanks for your reply. Maybe it's out of the scope of Labview, however do you know how I can optimize the GPIB operation regarding to CPU time usage? Can I do that in Labview?

Thanks,

Raymond

[Matt.M]

Raymond,

The one thing you can do is set the execuation priority of your VI higher.  This may help, it depends on what other processes are running, and their priorities.  I recommend you do not set the priority higher than "high priorty" as "time critical" can cause your system to lock up. 

In order to set the execution priority, in your VI, go to File --> VI Properties, then under the "Execution" category there is a priority drop down box.  That is where you can set the priority of the VI.

Regards,

Matt