[time-nuts] Tbolt temperature Control & ad-hoc IO from Windows.

Dave Baxter dave at uk-ar.co.uk
Thu Aug 27 10:13:26 UTC 2009


Just some general info on the subject of ad-hoc/experimental IO from
within the Windows environment.

I personally think, that if you want to keep a T'Bolt at a constant
temp, it's best done with an independent control system (hardware or
software) than any attached PC.  In the long term anyway.


However, to prove the point, and for general experimental messing and
fiddling...  Take a look at INPOUT32.DLL 
http://logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_9
8/2000/NT/XP.html

It allows you to have almost direct control of any IO space port the
system has.  Common "targets" for this are otherwise unused LPT ports,
but it has to be a "Real" hardware port, not a USB<>LPT device.
(You can still send control bytes to those via the OS though, and read
the status likewise, but the delays can be a pain!)

It will pass through commands and data if running on a Win9X system, or
install a Kernel mode driver on a NT (2k, XP, etc) system.

You can use just about any common programming language to drive it, so
long as can call external DLL routines and pass data to, and receive it
back from such routines.

There is a "Huge" amount of info on t'interweb, about how to use the
venerable LPT port for general purpose digital IO.


Otherwise, take a look at any of the USB<>Digital IO experimental kits
that abound the web.

In this case, if the T'Bolt can report it's internal temperature over
RS232 as you describe, then using a serial port, with one or more of the
handshake lines "re purposed" to control the heater/cooler should do the
job, you just need to get a bit creative.

Though many Windows based SW development languages are poor in their
handling for COM ports, it is possible, and once you have the grasp of
how to directly manipulate the port via the OS, things like that work
very well.  (Some versions of VB though have some interesting "Features"
in the way they handle the serial port, that can really annoy you, just
to make it difficult to send/receive binary data.  ASCII OK, Binary
seems to get some bytes filtered out!)

DO NOT try to command IO ports directly on NT systems from your own
code.  They will at best object with a popup, at worst crash with a
BSOD, or just reboot on you unexpectedly!   You will need something like
INPOUT32.DLL (or other similar tools.)   Even then, sometimes unless you
tell the OS you are going to use the port, there can still be trouble.
Best with COM ports, to go via the OS, at least it'll be aware of what
you are doing, so should prevent any other app from trying to grab it.

I recently implemented a 4bit IO control bus via the LPT port, to
interface to an old ICOM HF receiver to a much newer control system.  It
works well, and is stable for weeks/months at a time...   It even
survives a reboot without screwing up, and it doesn't just sit there
dormant all the time, as it is controlled and polled repeatedly from
another program, with the inter-program communication via some virtual
com ports courtesy of Eterlogic's VSPE tool.
http://www.eterlogic.com/Products.VSPE.html 

or N8VB's virtual null modem.
http://www.philcovington.com/SDR.html  Scroll down to "Open Source
Software".


I have used MarshallSoft's serial IO library (WSC at
http://www.marshallsoft.com/ not free, but very good value and stable)
with both "Real" and USB<>RS232.  You can't tell the difference for most
purposes, but avoid Belkin adapters.  They seem to have some
"interesting omissions" in some of their USB drivers!  FTDI seem to be
about the best chipsets to use, and the documentation is excellent from
FTDI's website.
http://www.ftdichip.com/ 

There are also USB<> Parallel IO chipsets too.  I've yet to need to
explore them


With both real or USB<>RS232 ports, with the Marshallsoft library (and
with my own native Win/Delphi code) I have had simultaneous serial IO,
and used the DTR/RTS lines as power and control lines for a hardware
interface, swapping them over +-/-+ to control TX/RX on a radio as well.
No problems.   In some ways, once you have all the needed code baggage
in place, it's easier in Windows to do that sort of stuff, than it ever
was with DOS.  It just eats more memory to do so.  (But looks nice!)

Oh yes..  Also, since Win2k SP3 (I think) MS disabled by default any low
level (DOS mode) access to the COM ports.  There is a registry tweak
that can re-enable such things but I've lost sight of it, as when we got
hit by that at work, I bit the bullet and learnt how to program in
Windows with Delphi, and re-wrote many of our tools and utilities
(originally written for DOS in QuickBasic) for Windows.  It was painful,
but well worth it in the long term.

Don't let MS's latest bloatware OS's put you off from experimenting with
IO on modern PC's.  If anything, with the later GUI OS's and some good
(sadly not all dev' tools are "good", paid for or otherwise) SW
development tools, you can still take over the world in odd ways, as you
wish.

Ulrich's EZGPIB tool, also has easy serial port handling (mind you, I've
not tried the handshake tricks yet) and has minimal impact on a system,
unlike installing a full development package!  Highly recommended.
http://www.ulrich-bangert.de/html/downloads.html

I have to say though, my experience stops at XP (but includes 3x, 9x, ME
& 2k).  I now have a Vista machine in the fold, but have not tried any
of this on that OS, yet....  I suspect I'll be in for a surprise of some
sort, as it only has USB ports, nothing "real" sadly...


If you want to "go for broke".  Check out SIB (Small Is Beautiful)
http://www.grc.com/smgassembly.htm or hints as to how to program in
native assembly language for Windows!  Scroll down for all the useful
links etc.


Just my sixpence worth anyway.   

Regards to all.

Dave B
G0WBX.



More information about the time-nuts mailing list