Comunication COM1: and a CNC milling machine (timeout?)

[David Vaughan]

On Friday, Sep 19, 2003, at 01:29 Australia/Brisbane, 
malte.brill at t-online.de (Malte Brill) wrote:

snip

> Quoting Sarah:
>> You might want to try out my Serial test stack - available from my web
>> page at
>> <http://www.troz.net/Rev/>
>> I have just updated it so that it allows you to select termination
>> characters i.e. whether sends should end with CR (ASCII 13), LF (ASCII
>> 10) or CRLF and the same for receives.
>> I think it will solve your reading problem, because it doesn't do a
>> single read, but reads continuously as long as the port is open,
>> reporting whenever it gets any data.
> That´s an interesting approach.
> I had a look at your stack, but couldn´t test it with the mill yet, as 
> I
> disturb the production process every time I try testing the stack and 
> they
> are really busy today.
> When I would use the method of testing if there is data sent, how 
> would I
> know that the transmission is done?
> Could I try "listening" to the port until data is sent and then read 
> until
> EOF? Or would I need to write a stop handler to terminate reading when 
> no
> more data is sent?

Malte

While reading earlier bits in this thread I had forgotten that I wrote 
a similar stack a couple of years ago. These points are probably 
covered in Sarah's stacks but the following is the strategy I used.

The device was an intelligent battery charger which simply pumped out 
data when it was working. No commands, no handshakes.

I used three buttons, Clear, Prepare and Stop, with fields to show 
time, data and state (clear, waiting, running, stopped).

Prepare started a listener which cycled looking for the first instance 
of data. If you have no input buffer then skip this step or roll it 
into the second. When it found data it started the Reader, Writer and 
Monitor routines (all running in cycles rather than continuously)

Reader kept up with reading data, taking it in small chunks and using 
send in to run again at a short interval. With 300 baud input you 
should have no problem cycling yet still capture unbuffered characters.
Writer logged the data to disk every half minute. (Skippable)
Monitor ran at five minute intervals. If no new data had appeared in 
the last five minutes it cancelled the other handlers and closed the 
port. You can also press Stop to do the same. Since this device 
normally ran for over half an hour I did not hang around to watch the 
excitement :-).

All of these intervals should be tailored to the machine with which you 
are communicating.

For platform reasons (i.e. lack of successful USB access under OS X at 
the time) the draft in RR was transferred to HyperCard on an old Mac so 
I was using idle, but "send in time" should accomplish all the same 
today.

regards
David