Serial Receive Non-ASCII characters

[jspaarg]

I am interfacing to an ancient serial device (DELCOM Model 717 Conductance Meter) over a serial port.

The command protocol is to send the meter a ^P (byte = 0x10) to initiate a transfer.

It is supposed to respond with six bytes in the format:

0xFF

0x40 - 0x47

RR

RR  where RRRR is the 16-bit reading

0x0

0x0

The hardware protocol is 4800 BAUD, 8N1, Xon/Xoff

When I interface through Hyper Terminal the device works and responds with the six bytes.

When I interface through LabView (2009) there is no response from the device

Putting the transmit signal on a scope, the byte is identical.

I have not looked at the return on a scope because I had to give the meter back before I could get the scope.

I will try that next week when I get both systems again.

In the meantime, does anyone have any idea why I am not getting a response?

Any ideas are appreciated.

By the way, I use similar functions for all my other serial interface devices (none of which have non-ASCII characters in their strings.

[johnsold]

Typically when a device communicates with a terminal program and not with LV it is because the terminal program appends an end of line character and LV does not.  You do not mention whether the device protocol requires a line feed or carriage return after the command.

It seems strange to send binary data and to use Xon/Xoff.  What if the binary data includes the Xoff character?

Lynn

[jspaarg]

Hyper Terminal is setup to not send any termination characters.

The only thing transmitted is the 0x10 (as confirmed on the scope).

Don't know what you mean by the Xoff character.

There is only a single byte being transmitted.

And it matches a 0x10 both from Hyper Terminal and LabView.

I assumed (perhaps incorrectly) that Xon/Xoff used the handshaking signals (e.g. DTS, RTS).

The command protocol is a single byte ^P (0x10).

Thanks for the thought.

[johnsold]

Xon/Xoff is a handshaking method that transmits the Xoff character when the other device is to stop sending and then sends an Xon character when it is ready to receive again.  If a system uses the Xon/Xoff handshaking method (rather than extra wires like RTS/CTS), then the characters transmitted as data or commands must never be allowed to include the Xon or Xoff characters.  In your case, it looks as though the RRRR data could include any possible character.

Lynn

[jspaarg]

Assuming that you mean like a CTX, ETX ("^B,^C)

Then why is there only a single character displayed on the scope for both Hyper and LV?

[RavensFan]

I'm not sure what you mean by "non-ASCII characters" in your message subject.  There is no such thing as a Non-ASCII character.  (Well I guess there could be if you are dealing with extended character sets or Unicode characters.  But none of that seems to deal with your message.)

I would recommend that you post your VI so we can see what you are doing in LabVIEW.

A good way to determine what is working in Hyperterminal, but not working in LabVIEW is to use a program like Portmon with each application and see what the differences are in their communication scheme.

[Coq_Rouge]

I prefer to use Realterm instead of hyper term http://realterm.sourceforge.net/. But Labview may also work as RS232 terminal. Anyway post your code. I guess it will be easy to find a fix 

[jspaarg]

Okay, perhaps non-ASCII is not the correct term.

What I mean is that the response can be any byte value from 0x00 through and including 0xFF.

That means that I can receive non-printable characters.

So the question remains why is LabView different?

[jspaarg]

Okay, perhaps non-ASCII is not the correct term.

What I mean is that the response can be any byte value from 0x00 through and including 0xFF.

That means that I can receive non-printable characters.

So the question remains why is LabView different?

[jspaarg]

I am not looking for a different terminal program.

I am looking to make LabView work.