Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Visa Read Problem

Solved!
Go to solution

I have a Serial communication vi that works fine.  I need to change it over to Visa and created a vi.  My problem is i get some data that does not make sense at all with the VISA program.

 

For instance:

Byte 1:  Leading byte 0D 

Byte 2:  Bit 0,1,2 define the decimal and only one of these can be 1.

Byte 3:  Various status

Byte 4:  These are the Units and only 1 bit from 0-6 can be 1.

 

The Hex data is invalid now.  I can run the old serial communication vi and I get the correct data without changing any setup.

Any ideas?  There is no termination character.

 

Thanks

0 Kudos
Message 1 of 6
(4,121 Views)

The subVI is missing from your first program. From the name of it, maybe you should be doing a buffer clear in the new VI. I have no idea why you are passing in a 0D string. Would need to see the code. Passing a hex value of D to the VISA Configure Serial Port does nothing.since you have disabled the termination character.

 

The statement that 0D is byte 1 does not match the string indicators. There, the first byte  is 01. Could the missing subVI be doing a read until a 0D is seen and then pass the remaining? This subVI is custom code so it would need to be replicated in anything new.

0 Kudos
Message 2 of 6
(4,111 Views)

I was trying several things with the Visa.  That last thing I had added ther termination character and had it on.  I was looking for the Byte 1 as 0D as the start string in the serial communication.  I attached it with the sub vi for the serial communication.

0 Kudos
Message 3 of 6
(4,094 Views)

Here is what the manual has for communication:

 

Protocol of RS-232C Serial Interface (RM-1501) Ten bytes are sent out through RS-232C connector to PC. The definitions of each byte are as followings:

Byte 1: Leading byte 0x0D
Byte 2: Decimal point of LCD display
    bit0: dp1 (0000.0), if 1
    bit1: dp2 (000.00), if 1
    bit2: dp3 (00.000), if 1
Byte 3: Flags for current status
    bit0: low battery, if 1
    bit1: Max. value overflow, if 1
    bit2: Counter overflow, if 1
    bit3: Auto-power-off disable, if 1
    bit4: Min. value overflow, if 1
    bit5: Ave. value overflow, if 1
Byte 4: Unit
    bit0: rpm, if 1
    bit1: m/min, if 1
    bit2: ft/min, if 1
    bit3: yd/min, if 1
    bit4: rps, if 1
    bit5: counter with external light source, if 1
    bit6: counter without external light source, if 1
Byte 5: Function
    bit0: normal, if 1
    bit1: max, if 1
    bit2: min, if 1
    bit3: average, if 1
Byte 6: Flags for current status
    bit4: LCD reading over load (OL)
    bit7: Hold
Byte 7: Least significant byte of reading in binary format
Byte 8: 2nd byte of reading in binary format
Byte 9: 3rd byte of reading in binary format
Byte 10: Most significant byte of reading in binary format

0 Kudos
Message 4 of 6
(4,093 Views)
Solution
Accepted by topic author kyle_vi

The subVI is doing what I thought it might. You will have to implement the same logic in your new program. Just like the old driver, there is no built-in capability to look for a leading character and then return the rest. Your read string with the new program will be incorrect until you sync the data stream like the old program did.

 

p.s. If you hadn't cheated a bit and used an llb to keep the old low level serial functions, your 7.1 VI would have used VISA. The conversion was (and is) automatic.

Message 5 of 6
(4,088 Views)

Thanks for the support.  As it turns out, I had the baud rate set wrong as the primary reason I received the wrong data.  Then I just created a loop to look for the right character and got going.

 

Thanks

0 Kudos
Message 6 of 6
(4,044 Views)