Thanks for the advice; consistent with your recommendations and those of Mr. Cleis, I will re-implement this using write-bytes rather attempting to display a string.<div><br></div><div>My working VB code required the carriage-return linefeed character in order to work properly ( .WriteLine("V00" & vbCrLf) ). I'll attempt various line terminations and, failing all else, I'll check the pins with a scopemeter to see the characters transmitted and go from there.<br>
<div><div><div><br></div><div>Thanks all,<br><br><div class="gmail_quote">On Fri, Dec 30, 2011 at 6:24 PM, Neil Van Dyke <span dir="ltr"><<a href="mailto:neil@neilvandyke.org">neil@neilvandyke.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are a number of things that could be going wrong, due to RS232 and terminal device subtleties, and the OS abstractions.<br>
<br>
Assuming that your bit rate, data bits, parity, and stop bit are compatible, and you're using the right cable (null-modem or straight through, and enough of the pins wired through rather than unconnected like in some cables), and you're not confused by something like flow control or full/half duplex (and I'm assuming it's ASCII)...<br>
<br>
The very first thing I'd do from the Racket side is to send exact bytes rather than strings, just because bytes are the right way to do it.<br>
<br>
Then I'd be sure that I was sending whatever newline convention the device requires: after the #"V00" bytes, does it require a CR byte and/or an LF byte?<br>
<br>
The very next thing I'd look at on the Racket side is that I'd quickly peek at the implementation of "open-input-output-file". (From your description, it sounds like it is correctly not buffering the output, and that EOF doesn't look like it can be right if it's doing a blocking read with the semantics I'd expect, but I'd just make sure I knew the implementation, since the documentation makes this look easier than I'd expect it to be.)<br>
<br>
If it's not working by this point, I'd pick one of the open source libraries that does work with it, and see what they're doing differently. Maybe try to find one that's not using Win32/MFC/etc. calls, but works using standard C and POSIX calls. RS232 is a pain in the butt, so I think this is a good time to first do cargo cult engineering -- go through the magical incantations that seemed to work once before -- and then after it seems to work you can figure out the *why* so that you can have as robust of a solution as you need.<br>
<br>
If all else fails, you can use the Racket FFI to make example Win calls you find in MSDN or on some Web page, but good to try the elegant "open-input-output-file" first.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<a href="http://www.neilvandyke.org/" target="_blank">http://www.neilvandyke.org/</a><br>
<br>
</font></span></blockquote></div><br></div></div></div></div>