Serial: IOCTL, IRP and Visa Write

[HEG]

I am building a labVIEW drivers to comunicate with an instrument through serial port. To getting the commands from the (quite poor) manual. The STOP instruction is supposed to be Control-C. So I guessed that it would be transmiting Hex 03 to the serial port. This did not work.

So I run the propietary program of the istrument and sniffed the serial port using sysinteral portmon. When this command is executed, the sniffer reports
IOCTL_SERIAL_IMMEDIATE_CHAR Char: 3
and the device did STOPPED

When I use my LabVIEW code using VISA write and wiring a string constant in HEX mode with 03 the sniffer reports:
IRP_MJ_WRITE Length 1: 03
and the device did NOT STOPPED

If IOCTL_SERIAL_IMMEDIATE_CHAR is just a fast way to send a command (making the first in the buffer), the LabVIEW version should work because my buffer is empty when I send it.

Any ideas? How can I send a IOCTL_SERIAL_IMMEDIATE_CHAR type command in labVIEW?

Thanks,

Hernan Grecco

[waldemar.hersacher]

Dear Hernan,

I'm doing binary transfers with a device over serial port. In the VI I open to start the communication I do:
VISA Configure Serial Port with a boolean FALSE connected to "Enable Temination Char".
The "duplicate VISA resource name" is then going into a property node setting "Serial Setting >> Serial End Mode for Reads" to "none".

Next suggestion is to set the handshake and all the other parameters to the right mode. This depends from your device.

I have a little acknowledge about the Windows kernel messages. You cannot, as far as I know, determine which method VISA will use to write and read from the serial port. IRP_MJ_WRITE is the normal way to write to a device. This method will allow to buffer data within the kernel driver if the device is busy. IOCTL_SERIAL_IMMEDIATE_CHAR will bypass any kernel driver buffers and write the data into the serial I/O hardware. I don't know if you can transmit more then one character and what will happen when the FIFO buffer of the serial I/O hardware is full.

I have attached a screenshot of the BD.

[HEG]

Dear Waldemar,

Thanks for your post, but I am afraid that the termination character is not the problem in this case as this is a writing problem and the termination character in the VISA Configure Serial Port is related to reading operation.

Baud Rate, stop bits, data bits, parity and protocol parameters are Ok as all other commands work perfectly.

Thanks,

Hernan

[Ben]

Hi Hernan,

You wrote

"and the termination character in the VISA Configure Serial Port is related to reading operation"

Actually this can be configured independently for both read and write. So please double check what what Waldeman suggested.

Second;

A hex "03" is an "ETX "End-of-text" character.

See this link for reference

http://www.lookuptables.com/


I do not have book handy but as I recall a ctrl-c was a keyboard code and not an ASCII character.

The issue may be what the "poor manual" means when it says "ctrl-c".


Maybe "5E63" or "5E43" is what they were trying to communicate.

Just trying to help,

Ben

[HEG]

Dear Ben,

Thanks for your suggestion.

In the on-line help for VISA Configure Serial Port says:

"Enable Termination Char prepares the serial device to recognize termination char. If TRUE (default), the VI_ATTR_ASRL_END_IN attribute is set to recognize the termination character. If FALSE, the VI_ATTR_ASRL_END_IN attribute is set to 0 (None) and the serial device does not recognize the termination char.

Termination char calls for termination of the read operation. The read operation terminates when the termination char is read from the serial device. 0xA is the hex equivalent of a linefeed character (\n). Change the termination char to 0xD for message strings that terminate with a carriage return (\r)."

So changing this will not change my write termination char.

Buts let's go back to the main issue. I am sniffing the port so I know exactly what I am sending, and I am not sending any termination char.

I agree with you that Ctrl-C is a keyboard code. However, Ctrl-C was usully mapped to Hex 03 (one of the non printable characters). I tried "5E63" or "5E43" and did not work.

Don't forget that I have the original software for it where this command is implemented and they are sending a single character (3) using a IOCTL_SERIAL_IMMEDIATE_CHAR.

Thanks,

Hernan

[Ben]

Please post a small example of your code.

I think we may be more helpful if we had some visual aides.

Sending a hex "03" should work based on your observations of the propriatary code.

Otherwise I will watch for others to contribute.

Still trying to help,

Ben

[Ben]

After thinking for a while I would like to repeat my request for sample code.

I send a hex "03" to terminate escape sequences in an app I have running at home.

So, please post an example so we can help.

Ben

[HEG]

The code is really simple. Just the serial config, the move command (1000 1000 r) and the stop (HEX 03) command. I have attached anyway.

I put the serial port settings as constants in order you are able to see them.

The problem is that I am not sure that I am sending exactly the same with the original program and with labVIEW because they appear differen in my sniffer. (See my first post)

So: Is there any way to issue a IOCTL_SERIAL_IMMEDIATE_CHAR command in LabVIEW?

Thanks,

Hernan

[Ben]

Thank you for the image!

I think that you are transmitting an ASCII character for the number "3".

Right click on your string constant and enable "slash codes".

In that mode you can key in the ASCII code you are after.

See attached jpg.

Let me know if this takes care of things.

Ben

[HEG]

I am transmiting Hex 03. When I right click on it the Hex Display is selected. In addition I have checked with the sniffer and I AM transmitting just Hex 03.

Hernan