Rs232 Serial Communications VISA using HEX. Values seem to be lost.

[KyleF.LabView]

My PCB is expecting the following bytes to switch between two detection modes:

Byte 0: 0x50, Polling delay / SLEEP period
Byte 1: 0x03, Aux data output as 9600 baud serial (default
Byte 2: Reserved
Byte 3: 0x01 <-- to switch mode

Byte 4: 0x00  All following bytes are default and are unchanged
Byte 5: 0x01 
Byte 6: 0x00 
Byte 7: 0x00 
Byte 8: 0x00 
Byte 9: 0x00 
Byte 10: 0x00 Aux output serial format, HEX byte format
Byte 11: 0x00

When I asked the manufacturer they said that all I need to do is send 50h 03h 01h to make it change modes. However, as far as I can tell in Labview the 03h and 01h are lost as these low hex values correspond to defaults in the ascii that the VISA write accepts. I have limited coding experience so I dont fully understand how the VISA actually send the bytes. I am also recieving data in HEX just fine.

I have attached the VI that I have been using which is just a modified version of the basic serial read/write that labview has as an example. I have also attached the data sheet for my PCB which describes the codes I have highlighted. I am using 9600 baud, 8 bit, 1 stop bit, no parity and using the CTS line for hardware handshaking. My PCB is hooked up correctly to get its TTL level output up to RS232 voltage so there is no problem there.

Thanks,

Kyle

[Sam_Sharp]

What values are you putting in the 'string to write' - the VISA Write uses a string just because that's the most convenient, but it doesn't change the data (e.g. to only visible characters) - it maintains the bytes you're transmitting.

Did you actually wire your bytes (converted to a string) to the VISA write?

Your array only had 4 bytes in it - the array should be 12 bytes in length according to your post. It also helps when debugging these things to turn on 'radix display' so you can see if you're working in hex/decimal etc.

[crossrulz]

---

@KyleF.LabView wrote:

When I asked the manufacturer they said that all I need to do is send 50h 03h 01h to make it change modes. However, as far as I can tell in Labview the 03h and 01h are lost as these low hex values correspond to defaults in the ascii that the VISA write accepts. I have limited coding experience so I dont fully understand how the VISA actually send the bytes.

---

VISA will just send the bytes you tell it.  It does not care about the ASCII values.  Since you have the Hex display on your string control, you should just have to type "500301" in the control and the VISA Write will write out those three bytes exactly as told.

[KyleF.LabView]

Thank you for the quick response.

I have tried to do as suggested and write 5003 01 in the Hex string input to the VISA. I tried this before posting. There is no result that I can see as the PCB has not changed modes.

The manufacturer seems to think that it might be a problem with the CTS line not being detected or the COM port not being set up via "hardware handshaking". I don't know if this is the problem though as the com port must be set up as it is recieving the correct bytes in HEX from the PCB just fine. Is there any way that I can see if the CTS line is being detected correctly in LavVIEW? The bytes must be set when the CTS line is LOW otherwise the PCB will not accept it.

Also the manufacturer said to ensure that LabVIEW is sending HEX bytes and not Ascii bytes. I would assume it is since i try to write it using the HEX input style in the string.

Thanks

[KyleF.LabView]

Thanks for the quick answer.

Yes i did wire it i just rewired it to try the 5003 01 method before posting. I made the array 12 bytes long as suggested but that shouldn't make a difference as all the rest of the bytes are defaults.

I can't quite get the Radix to show. LabView help says to:

'Right-click a numeric object and select Visible Items»Radix from the shortcut menu' or

'Use the Operating tool to click the letter and select Decimal, Hex, Octal, Binary, or SI Notation from the shortcut menu.'

The visible items right click just has labels in it and I don't know what it means by operating tool and a search for that gives tons of results.

I also just figured out that the VI fails and gives me an 'error -1073807339' which appears to be a timeout error whenever I attempt to write. I think this is it failing to write and not reaching the read. If I don't attempt to write it reads fine. This might well be in relation to the CTS line or the hardware handshaking.

[KyleF.LabView]

To check the CTS line is getting a correct waveform I hooked it up to an oscilloscope. It is recieving the correct waveform on the CTS pin into the female end of the RS232 plugged in to the computer. This waveform has it going low every few microseconds as it says. So it is definitely something on the software side as LabVIEW shouldn't care if the PCB recieves it correctly as long as it is sending it during the correct CTS LOW period.

Also, the flow control I have it set as is CTS/RTS since I need to use CTS. It shouldn't matter that RTS is being unused as that shouldn't matter for writing correct?