Simple question about XON/XOFF

[Rick Nelson]

Hello,

I'm using LV 7.1 to send/receive commands from a microcontroller via the serial port. My specs say that XON/XOFF software control will be used to throttle data during the transfer. Then the specs then go into detail about how XON is ASCII character 17, and is transmitted after a Break when the receiver is ready for data, as the same with XOFF being ASCII 19 and how its is transmitted after a Break, and then how the transmitter is restricted to sending out 8 bytes after a Break->XOFF command is received... etc.

My question is: Do I need to write LabVIEW code to handle/look for Breaks, or are the deetails handled in the VISA/LabVIEW drivers? I would think that it is handled by VISA, but the fact that the details of using the Break command are right in the specs might mean that this scheme is specific to our microcontroller (which isn't built yet, so I can't test on it).


Thanks for any replies!

-- Rick

[Dennis_Knutson]

I'd have to double check my serial comm reference but that seems like normal XON/XOFF handshaking, in which case, the VISA driver will handle everything for you.

[Rick Nelson]

Ah... I think I may know why the spec goes into detail - we're trying to send binary data. The data does not come back on my loopback cable if I send down 0x01, 0x02, 0x03... (it actually goes up to 0x0A... I think this should be 0x13, which is XOFF). Isn't XON/XOFF bad for binary because the device won't know if we're sending a 0x13, or if we want to send an XOFF.

I guess I just need to know how to handle Breaks with this (does using them allow us to use XON/XOFF with binary data?)

[Rick Nelson]

Oops, never mind. 0x0A is the default termination factor, which is on by default in LabVIEW. I told LabVIEW to ignore 0x0A, and now that part is fixed. But I still have a feeling just checking the box to use XON/XOFF won't work if I want to send down the XON and XOFF characters if my binary data happens to have those characters in it.

[tbob]

Usually you do NOT use XON/XOFF when transfering binary data. At some point in time the data being transferred will be mistaken for an XOFF command and the system will lock up because it is sitting idle waiting for an XON. Been there, done that, won't do it again. Usually XON/XOFF is sent without being preceded by a Break. Perhaps your system is designed to handle the data after a break as a command, like XON/XOFF. If this is the case sending a Break before XON/XOFF might work. It all depends on how the system you are communicating with is designed. If it is indeed designed to work like this, I would bet that your Labview program would have to be desinged specially as well. The serial config vi found in the Serial palette has an input for handshaking mode, and it includes XON/XOFF as a choice. So I'm sure that it would normally handle these commands. However, I don't think it would treat a Break as a flag to treat the next byte as a command instead of data. If you use the configure vi and set the mode to XON/XOFF, you will see a lock up at some point in time. You will have to write your code to treat the incoming data. As you read the data, look for a break. Use a case structure. If break then handle next byte as a command. If not break then handle the next byte as data.