The LEGO DACTA 70909 controller has 8 outputs and 8 inputs that can be controlled from a PC via the serial port.
As a part of my thesis in computer science that I did in 2006, I coded a JAVA class that can control the box. It also comes with a some example code that will enable you to control the box.
Since the box is quite old (from 1992 or something) it is practically impossible to find anything on the WWW about it and all software etc. that followed the thing seems to be lost forever. You can never have too many in and outputs when doing something in robotics, so even though old it is still a nice piece of hardware that can still be used for many purposes.
As a part of my thesis in computer science that I did in 2006, I coded a JAVA class that can control the box. It also comes with a some example code that will enable you to control the box.
The pages about this project seems to be visited quite often,
so I decided to keep the page even though I hardly remember anything
about how this thing works.
I don't have one of these units myself so I cannot update the code, or write a newer version. The code relies on JAVA communications API, which seems to still exist, but has probably been changed a lot since 2006.
However these downloads can get you started, and you should be able to create your own.
A zip file with the JAVA source code. (The zip file includes the controller, an example and basic documentation.)
A pdf describing how the box works in detail.
I’d like to thank Anders Isaksson, who had left some well hidden notes
on the internet with some information about the protocol
etc. (2021-01-28: None of these exist today.)
Several people commented during the years on my old page, about how to get things working.
| 2011-10-05: Bob
writes that the Java Communications package is nowhere to be found. We find another project that seems to work: http://rxtx.qbang.org |
|
2011-11-25 - Pengvado: I have discovered a case in which the actual behavior of my 70909 box disagrees with your documentation: The pdf says that the first two bytes of an input packet
are constant zeros, and the java treats any deviation from that as a
desync error. Timo: Perhaps your 70909 is a newer revision, and the original LEGO software just never checked the first byte? However it is also perfectly viable that my example, and the others too, simply throws away information when the 70909 returns the byte #1 like yours do, and we never noticed this, because everything worked well on the next frame received. (I assume the next frame has double zeros`?) If you have byte #1 changing “randomly” all the time, the code in the example will have to be rewritten quite a bit. To detect when a complete block of code have been received you’ll have to look for complete 19 byte frames by checking for zero’s in byte #0 and the correct checksum in the end. I’d love to hear more about it, also how you made Java talk to serial devices. (I assume you’re not using the old Java Communications package.)
> I assume the next frame has double zeros? Your proposed solution sounds right. But note that
fixing the header check is independent of reducing resync latency. If
you don’t mind a resync taking 0.4s (like it currently does), then the
checksum is already available, so you can just not look at byte #1. > how you made Java talk to serial devices. Updated source tree, including my header patch, and the 1-line rxtx patch, and updated the readme to include rxtx: http://akuvian.org/src/DACTA70909.zip |
| 2013-04-13 Darryl: Just a quick note to say thanks for the original code. I used it as part of an application I built several years ago to control multiple controllers. Just refactored it to work on Windows 7(64-bit) and created a github repository for it. You can find it at https://github.com/degoworks/degoworks. |