View Single Post
  #14   Report Post  
Posted to rec.crafts.metalworking
David Billington David Billington is offline
external usenet poster
 
Posts: 856
Default help with drip feeding R2E4

Lloyd E. Sponenburgh wrote:
David Billington fired this volley in
:


Any idea what language you'll
be using, my experience is with C and C++.



I can do C, and a smattering of C++. I retired from software work before
C++ had a full following among industrial users, but C was well and
thoroughly rolled out.

I started about 20 years ago so I think C++ was around but hadn't become
mainstream, it didn't take many years after that to do so though IIRC.
When I was at college some people were using SmallTalk and I met a guy a
few years ago that was an expert in it, at that point I think it was
officially a dead language. Doesn't take long for some languages but I
don't see C going away for a while.

However, I'm most likely to do it in Visual Basic. It's not all that
great a language in terms of efficiency, but I have a library of hardware
functions and widgets that claim to deal with all the preemption crap.
Obviously, at 4800 baud, interrupt latency is important. Coupling that
with the fact that the control will choke if you send more than three
characters past the XOFF makes real-time handling pretty important.

I've never done any communications that required XON/XOFF but my
understanding is that Windows should handle that for you if configured
correctly. You may want to look at the DCB structure as detailed here
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx . One of
the gotchas I ran into in some code was a call to WriteFile () followed
by a call to WaitCommEvent (). It was regularly timing out on the
WaitCommEvent (), it seems it was frequently being pre-empted between
the 2 calls and at 115k baud the reply had already been picked up by
Windows and placed in the receive queue. WaitCommEvent () won't tell you
if data is already in the queue, only when new data has arrived and been
placed in the queue.


Dave, I could not figure out how to make the control use Xon/Xoff "dumb"
protocol for the DNC. I followed your instructions of using a "-1" as
the filename, but my termulator still just blithely sent the whole file,
rather than pausing per-block. I don't yet have a protocol analyser
hooked up, but I presume that means there were no flow-control characters
coming from the control.

OTOH, I can transmit a DNC stream successfully from EZlink, using ONLY a
"-" as the filename (at the control) and two executes. The first one
seems to set the protocol, and the second starts the DNC link.

Perhaps you could explain that -- what is the significance of the "bare"
minus sign as a filename? I just did that from rote per the EZLink
instructions, but have no idea what it does. Can the DNC protocol be
invoked with a "real" filename, also? (haven't tried yet)

I air milled several parts yesterday under DNC via EZLink.

Thanks,
LLoyd