Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

VISA Read wrapping

Solved!
Go to solution

I am using VISA to read 179 bytes from a Agilent 3458A connected through GPIB.  I noticed that as I continue to run my read vi, more digital form the bottom value will wrap around.  Have you seen this?  

 

2
1.995951462E-02
1.995958701E-02
1.995955596E-02
1.995953467E-02
1.995953733E-02
1.995969452E-02
1.995944259E-02
1.995943567E-02
1.995962604E-02
1.995952030E-

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 1 of 8
(2,811 Views)
Solution
Accepted by topic author jyang72211

It more likely that is data left over from your previous read.  You might want to try reading more.  Is the instrument setup to use a termination character?  That would be the best way to go in situations like this.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 8
(2,808 Views)

@crossrulz wrote:

It more likely that is data left over from your previous read.  You might want to try reading more.  Is the instrument setup to use a termination character?  That would be the best way to go in situations like this.


Yes, That instrument can be configured to send \r or not on EOI.  Be a bit cautious with that though since it can also be configured to send scale, offset and raw ADC values (speeds up large data transfers) youl'd be surprised how often you can get an ADC count of 0d10 and leave data in the buffer. (And how many man-hours it takes to find that bug when you are new.)

 

The odds are the term character IS enabled and you are not accounting for it in your reads leaving an increasing number of charaters in the buffer with each read


"Should be" isn't "Is" -Jay
Message 3 of 8
(2,790 Views)

@JÞB wrote:

Yes, That instrument can be configured to send \r or not on EOI.  Be a bit cautious with that though since it can also be configured to send scale, offset and raw ADC values (speeds up large data transfers) youl'd be surprised how often you can get an ADC count of 0d10 and leave data in the buffer. (And how many man-hours it takes to find that bug when you are new.)

Yep, been there.  But as long as you are just using ASCII, the termination character is by far the best way to go.  And if the VISA session is set up to use the termination character, just set the bytes to read something absolutely rediculous (like 1000).  You should then get a good read.  Oh, if you are getting a lot of data in this fashion, also make sure the VISA Timeout is decently high.  The default 10 seconds should be plenty fine.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 4 of 8
(2,782 Views)

@crossrulz wrote:

@JÞB wrote:

Yes, That instrument can be configured to send \r or not on EOI.  Be a bit cautious with that though since it can also be configured to send scale, offset and raw ADC values (speeds up large data transfers) youl'd be surprised how often you can get an ADC count of 0d10 and leave data in the buffer. (And how many man-hours it takes to find that bug when you are new.)

Yep, been there.  But as long as you are just using ASCII, the termination character is by far the best way to go.  And if the VISA session is set up to use the termination character, just set the bytes to read something absolutely rediculous (like 1000).  You should then get a good read.  Oh, if you are getting a lot of data in this fashion, also make sure the VISA Timeout is decently high.  The default 10 seconds should be plenty fine.


The 3458A has a LOT of memory (for a 1960's device) and the driver does have a few "idiosyncrasies"
Enable the term char, trap the warning, check the buffer.Smiley Wink

"Should be" isn't "Is" -Jay
Message 5 of 8
(2,779 Views)

I did some digging, and the default timeout for VISA read is 2second.  I actually had to change the timeout to 4s for it to work.  

 

http://digital.ni.com/public.nsf/allkb/E4F90AD24DEC9CC786256F4300605C02

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 6 of 8
(2,756 Views)

I did some some troubleshooting, and I arrived to the same conclusion.  The wrap around is left over from the previous data point.  I didn't create this code, so I am making as little change to it as possible.  It seems liek after I changed the GPIB read node to VISA read node, I have to read 180 bytes instead of 179 to get the expected amount of data.

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 7 of 8
(2,754 Views)

@jyang72211 wrote:

I did some some troubleshooting, and I arrived to the same conclusion.  The wrap around is left over from the previous data point.  I didn't create this code, so I am making as little change to it as possible.  It seems liek after I changed the GPIB read node to VISA read node, I have to read 180 bytes instead of 179 to get the expected amount of data.


That would do it.  There is a slight difference in end mode on reads GPIB and VISA (End on EOI vs End on Term Char not all VISA supported busses have parallel handshake lines) so you need to add the term char to the count when migrating.


"Should be" isn't "Is" -Jay
Message 8 of 8
(2,744 Views)