Reading Com port data

[Andy]

Hi,

I did this many years ago at uni, and completely forgotton it now.

Can someone explain to me in the commread example these lines:

REM in order to read from the port we need to set some
REM timeout values. The interval is 1 second
timeout.ReadIntervalTimeout = 1000
timeout.ReadTotalTimeoutMultiplier = 250
timeout.ReadTotalTimeoutConstant = 1

The only value that changes the timeout value is this line:
timeout.ReadTotalTimeoutMultiplier = 250

In other words, say I want to change the interval from 1 second to 2, I have to change the value of the above line from 250 to 500, why?

My friend has a sensor device that plugs into say com1 (don't yet know the timing interval of the device), but the baud rate I think is 9600.

This is my new project, I will need to read a diagnostic code sent from the device and then look up what that code means in a database and display it.

So any help from anyone who has written this kind of thing would be a great help!

Thanks,
Andy.

[LarryMc]

ReadIntervalTimeout

Specifies the maximum time, in milliseconds, allowed to elapse between the arrival of two characters on the communications line. During a ReadFile operation, the time period begins when the first character is received. If the interval between the arrival of any two characters exceeds this amount, the ReadFile operation is completed and any buffered data is returned. A value of zero indicates that interval time-outs are not used.

A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the characters that have already been received, even if no characters have been received.

ReadTotalTimeoutMultiplier

Specifies the multiplier, in milliseconds, used to calculate the total time-out period for read operations. For each read operation, this value is multiplied by the requested number of bytes to be read.

ReadTotalTimeoutConstant

Specifies the constant, in milliseconds, used to calculate the total time-out period for read operations. For each read operation, this value is added to the product of the ReadTotalTimeoutMultiplier member and the requested number of bytes.

A value of zero for both the ReadTotalTimeoutMultiplier and ReadTotalTimeoutConstant members indicates that total time-outs are not used for read operations.

[Andy]

Thanks Larry for a clear explanation of the comm example.

I could see the timeout was 250 and bytes to read was 4, so 250 x 4 = 1000 milliseconds = 1 second.

Andy.

[Andy]

How do I insert a carriage return when writting to a com port?

The device needs to receive one after each command sent, below is an example of one such command:

      data1 = "AT SP 0"
      IF WriteFile(hcom,data1,len(data1),written,0) <> 0
         PRINT "Wrote ",written,"bytes to the port, ",data1
      ENDIF

Do I use - data1 = "AT SP 0" + "\n"   OR    data1 = "AT SP 0" + chr$(13)

Using a simple console:

string x$

OPENCONSOLE
x$ = "AT SP 0" + "\n"
PRINT x$
PRINT LEN(x$)
DO:UNTIL INKEY$ <> ""
END

does force a carriage return, and gives a length of the string (x$) as 9.

does anyone agree I should use "\n" and that the string length in bytes sent should be 9?

Thanks,
Andy.

[LarryMc]

Use either "\n" or chr$(13)
they are exactly the same thing.
you can prove it  with this line of code

print ASC("\n"),ASC(chr$(13))

[billhsln]

Isn't \n actually chr$(13)+chr$(10)?  LEN("\N")=2, 13=Carriage Return, 10=line feed.  ASC() only returns the first characters value.

Bill

[LarryMc]

Isn't \n actually chr$(13)+chr$(10)?  LEN("\N")=2, 13=Carriage Return, 10=line feed.  ASC() only returns the first characters value.

Bill

Thanks Bill
My bad; you're absolutely correct.
I shouldn't answer questions when I first get up 

Code Select Expand

Print len("\n"),len(chr$(13))
gives 2 , 1

so, the answer to the original question is use CHR$(13) if the device only needs the CR and not the CRLF sequence

[billhsln]

Larry, you are brilliant at coding, just before coffee, the mind gets a little befuddled.  Without my first cup of Java, I am not even worth asking questions, much less answering them.

Take care,
Bill

[Andy]

Thanks Larry and Bill, that was certainly a debate!

I have sent my friend both versions to see which one works, one with + chr$(13) and one with "\n"
The documentation for this device states a carriage return, doesn't mention a line feed but we shall see
when he runs the two programs.

Thanks to both of you!

[Andy]

Okay,

My friend (throwing a spanner in the works) forgot to tell me the following:

The device connects by usb but needs to be seen as a virtual com port - say com 2 for example.

Has anyone written such a program? or does anyone know of a free program I could download?



Thanks,
Andy.

[LarryMc]

From what little I know programming a USB port is nowhere near as easy programming a com port.
USB devices can be constructed to perform some many different things.

I think what you really need to do is to determine the make and model of the USB device your friend is using and then see if the manufacturer offers a standalone device driver for it.

Anyway, that's where I would have to start looking.

[Andy]

Larry,

You were spot on about the driver, yes that did the trick.

However, experimenting with the com examples that come with IWB and this device I have come across something.....

If I send a command say "XYZ" I know the device would send "123" back, however it can send XYZ123 or X123YZ etc.

I can work around this but it would be better if it just sent "123".

One command example AT DP returns PAU then TO where it should return AUTO - where P is the last character of the command sent.

Could this be a timing issue? I have played around with the timing but to no availe.

It's probably me doing something wrong of course.

Any ideas anyone?

Thanks,
Andy.

[LarryMc]

I guess my first question has to be "What info came with the device driver for the hardware you are trying to interface to?"

Are you issuing valid commands to the device?

30 years ago I had some problems with handshaking but I don't remember any of the details other than I was interfacing to an RS-232 device.

Maybe if you supplied more details about the device and the device drive (so  we can look up info) someone MIGHT be able to help you.

[Andy]

Hi Larry,

It seems that the device sends an "Echo" back to you of the command it gets from you.

Fortunately, I have found out there is a command to turn this "Echo" off, and that seems to have done the trick.

It might help someone else with a similar problem in the future.

As always,

Thanks Larry.