visa serial interrupt

[Laian]

Hi Dear Members

I have a question regarding VISA interrupt routine. I want to write 20 bytes serial data that during this write process if visa read function gets any special byte like (AA) it should be paused the visa write function and wait until receiving any special char like (BB) to resume the write process again. would u please help me to use which visa function for that purpose?

Thanks 

[GerdW]

Hi Laian,

so you want to read and write to a serial port in parallel?

---

@Laian wrote:

I want to write 20 bytes serial data that during this write process if visa read function gets any special byte like (AA) it should be paused the visa write function and wait until receiving any special char like (BB) to resume the write process again. would u please help me to use which visa function for that purpose?

---

You could:

• read the serial port in parallel, setting/clearing a flag based on "AA" and "BB"
• write the message byte for byte in a loop
• have a small wait in the loop
• proceed with writing bytes in the loop based on the flag

Then there still is one problem: the bytes you write to the port will go into a (internal) buffer of VISA and/or the serial port driver. There is no way to know in LabVIEW, when the byte is sent over the serial connection…

Btw. who is "u"?

[rolfk]

Sounds like what you want to do might be supported by the standard serial protocol feature of XON/XOFF. And VISA supports that too.

However the Standard VISA Configure Serial Port.vi only lets you enable XON/OFF flow control, not configure the actual XON/XOFF bytes that will control this feature. By default serial ports use the byte 0x13 (Control-S) as XOFF and byte 0x11 (Control-Q) as XON value.

You can however always add VISA property nodes to change the two XON and XOFF character bytes. But don't change the VISA Configure Serial Port.vi itself! You never should modify VIs that come standard with LabVIEW.

[Laian]

Hi Mr GerdW,

1-For :

"Then there still is one problem: the bytes you write to the port will go into a (internal) buffer of VISA and/or the serial port driver. There is no way to know in LabVIEW, when the byte is sent over the serial connection…"

will Labview send this byte(into a (internal) buffer of VISA) after resuming?

2- "setting/clearing a flag based on "AA" and "BB""

is this the same as XON/OFF flow control?

Thanks

[Laian]

Hi rolfk,

I prefer not to use standard VIs(XON/OFF flow control)

just using a simple way to stop and resuming the write function process

I think it maybe more simple and easier, is it?

Thanks

[rolfk]

---

@Laian wrote:

I think it maybe more simple and easier, is it?

---

Absolutely not! What could be easier than writing 3 VISA properties during initialization of your session? The process you described is exactly what XON/XOFF does. This happens inside the kernel driver which has the possibility to enable hardware interrupts in the UART when the XOFF chatacter arrives in the input FIFO and react to it in a timely manner.

Everything is done for you by the driver and you simply have to enable it and configure your XON and XOFF characters! VISA itself is an application level software (not running inside the privileged kernel space) and therefore can’t use hardware interrupts. You could use possibly VISA events to achieve some sort of software interrupts but this has never even remotely the same reaction time as a hardware interrupt used in the kernel driver for the UART. And it’s quite a bit of work to get events to work properly as testing isn’t straightforward. So easier? Absolutely not! Possible? Maybe!

While XON/XOFF simply exists and can be enabled literally with the flick of a (virtual) LabVIEW switch.

If your question was about if it was easier to implement on your device side in a different way or use of XON/XOFF is really necessary, we can’t answer that for you as we do not know the capability of your hardware device and the features of your development platform for the device firmware. Generally almost every UART chip I know of nowadays implements support for XON/XOFF but you likely have to program some interrupt routine for it. Interrupt programming is notoriously difficult to do and debug so you would be probably in a bit of a wild ride there.

But this alinea only applies if you talk about programming your device hardware on bare metal. On Windows (or any other full OS including embedded Linux) you don’t have direct interrupt capabilities from user space where all application processes are running. That is always taken care of by the device driver and they normally support the enabling and configuration of the XON/XOFF handshake in the UART hardware or would have the means to implement it properly if the UART doesn’t have built in support. Inside VISA or your LabVIEW application you are to far away from the chip to be able to react in a timely manner to be able to implement this properly unless you intend to limit the baudrate to something like 75 Baud maybe! 😀

[Laian]

Hi rolfk

thanks for your complete answer

[Laian]

Hi GerdW & rolfk

I have attached my vi

appreciate for any advice

thanks

[Laian]

Hi Mr GerdW 

as you said:

"Then there still is one problem: the bytes you write to the port will go into a (internal) buffer of VISA and/or the serial port driver. There is no way to know in LabVIEW, when the byte is sent over the serial connection…"

I 've encountered this problem. when micro receives 20 bytes(of 40) from Labview then it sends XOFF char to labview for stopping the write process but the XOFF char will be recieved by labview with a delay therefore labview has sent more than 20 bytes what is your suggestion for solving this problem?

thanks

[rolfk · Accepted solution]

You most likely make this much more complicated than it needs to. The XON/XOFF handling is happening on the serial port level itself in the Windows driver. LabVIEW nor VISA does not need to know about that. You need to separate the handling of the serial port transmission with the handshaking (software XON/XOFF or hardware RTS/CTS) making sure that the two sides don't overrun each other and the protocol that you need to communicate with.

The overrun protection through handshaking happens in the UART chip and/or device driver. The protocol handling with the sending of specific commands and receiving and decoding, happens in your application. You generally don't care when exactly each byte arrives in the serial port buffer. The only thing you care about is that if you send a command "READ something\r\n" that this command arrives at some point completely at the other side and that this other sides then sends something back and you receive the entire response without missing characters. How long that exactly may take and if the different characters arrive at a specific time and when is not important to you, only that they do arrive and that the whole message arrives.

VISA supports this by allowing to configure the VISA session for a termination character. When you then issue a VISA Read with a certain number of characters to read, this VISA Read returns when one of these things happens, whichever happens first:

1) An error occured in the driver or somewhere. The function immediately returns indicating the error.

2) The number of requested characters have been received. The function returns successfully (really with a warning indicating that there might be still more characters in the receiving buffer) with the requested amount of characters.

3) The termination character was encountered in the incoming data stream. The function returns successfully, with the characters up to and including the termination character.

4) The timeout expired without one of the first three events happening. The function returns with a timeout error.

So if your device needs XON/XOFF handling, just enable it in the driver. Your LabVIEW application has not to be concerned about that at all and needs to do no complicated detection of the XOFF character at all. All your application is concerned about is sending out complete commands to the serial port which will handle the rest and then to wait until you received a complete answer frrom the device and interprete it.

And as explained, use VISA Read with a termination character when possible. Usually text based protocols use either carriage return (\r), new line (\n) or a combination of the two to indicate that a command or response is finished. Using the Bytes at Serial Port property to do your own scanning and trying to find the end of a response is ALWAYS the wrong solution.