05-06-2009 07:30 PM
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
Solved! Go to Solution.
05-06-2009 10:27 PM
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.
05-07-2009 08:35 AM
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.
05-07-2009 08:45 AM
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
05-07-2009 09:03 AM
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.
05-11-2009 01:00 PM
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