[time-nuts] ad-hoc I/O

[Lux, Jim (337C)]

On 8/28/09 7:43 AM, "Richard (Rick) Karlquist" <richard at karlquist.com>
wrote:

> The XT-Nano-XXL looks very interesting, and the price is good.
> 
> With these kinds of hardware devices, the question always
> arises as to what to use on the other end to talk to the
> device.  I see that ak-nord has a virtual com port driver,
> which many vendors have.  It would also be interesting to
> see if two of the XT-Nano-XXL devices could talk directly
> to each other without any computers being involved.  The
> manual talks about a "tunnel" mode, but shows the Nano
> connected to the box with 2 serial ports.
> 
> The other problem I have with these kinds of devices is
> what to do about software to talk to them.  Some devices
> come with free software that has basic functionality to
> debug the hardware.  What I would really like to do is
> to get an API and build a simple interface program with radio
> buttons, etc that control relays etc.  The problem is
> that I am not a programmer.  I keep looking for a tutorial
> that explains how to do simple Visual Basic or something,
> but I consistently run into two showstoppers.  1.  The tutorials
> cover only the VB or C++ language, and not the mechanics
> of compiling, linking, libraries, and .dll files.  2.
> The tutorials assume the program talks only to the "console"
> (keyboard mouse and monitor).  No discussion of connecting
> to the LAN and interfacing with the hardware.  What I
> have seen written about these topics is incomprehensible
> to me as an analog engineer.

We share and feel your pain..

OK.. Strategies for programming..

One is to make the remote device understand string input and produce string
output.  Most any language has some way to shoot strings to a serial port or
a file or a pipe or something.  Either you open a file ("COM1:") or use some
serial port method (SerialPort.Open = True) or similar.  I usually look for
an example of a terminal emulator program..

Another is to talk to the device in some form of messages/packets.  At a low
level, I like the "socket" interface.  Open a socket at an IP address and do
send() and recv() from the socket.  One of the best explanations at a simple
level is in the book "how to build a Beowulf" by Sterling, et al, where they
give an example of communicating between computers using Berkeley sockets
and explain the 4 or 5 API calls you need. (a pox on those who tell you,
just look at the man pages..).

At a higher level, using http: as a transport is fairly straightforward.
Yes, usually you use a web browser, but nothing says that has to be the
case. Http provides a very simple "put", "get" type interface to a remote
device (strings again). The program "cURL" makes shooting out the strings
easy.

But, say you want to build an interface that has some radio buttons and when
you click on the button, it shoots the string to the device doing
something.. Easy in languages like VB.NET.  But you want to start with
something like a terminal emulator, which will have all the gory details of
"opening and configuring" the com port already done.  You just replace the
part where it sends/receives characters with your new interface.