JAVA control class for DACTA 70909

The LEGO DACTA 70909 controller has 8 outputs and 8 inputs that can be controlled from a PC via the serial port.

dacta709091

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.

controllerimage1

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 😀

You can download:

A zip file wit 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 for still having some, even though well hidden :-), pages available where I could find a lot of information about the protocol etc.

His pages describe a similar piece of software done in Delphi, and is definitely worth a visit if you want to code the DACTA 70909 using Delphi.

14 thoughts on “JAVA control class for DACTA 70909

  1. Hi Timo,

    Ive just aquired a 70909 control box that has never been out of its box. If you know of anyone who wants to buy one

    Regards

    Andy

    • Since it has never been out of the box you might be able to sell it on ebay (or something) to LEGO fans.
      I don’t know anyone myself though.

    • Do you stil have that interface from LEGO? I like to buy one? i know it’s allmost 7 years ago but i try anyhow.

  2. i dont understand how you actually run the program. it’s all downloaded, but i can’t start it.
    i also dont understand all that stuff about copying it to the /bin/ directory thingie.
    please help.

    • Hi bob.

      JAVA does not have any built in way to access the serial ports on a machine. Therefore you also need to install the Java Communications package.
      BUT.. I wrote it back in 2006 and now 5 years later Java has changed a lot. Oracle now hosts completely new pages, and the only thing they have related to the Java Communications package is a bunch of javadoc, but there is no way to actually download the Communications package. This means that the example can not be run just as it is.

      For some reason, that’s buried beneath a lot of not working links on the internet, it seems that the support for serial ports was officially dropped from java.
      However… a project located at http://rxtx.qbang.org should be able to give you the same functionality.

      To make it work you need to install java, and then “on top of it” also install rxtx. Then all lines in the DACTA example code, where it says:
      import javax.comm.*;
      you need to change it to:
      import gnu.io.*;

      Then you should be able to run the example after compiling everything again.

      It’s probably not as easy as this, but I do not have the DACTA box any more, and cannot test it myself at this moment.

      If you can get it running I would love to hear more about it.

  3. 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.
    My box uses byte #1 to acknowledge any output commands processed on the previous clock tick, as a bitmask of which output ports were affected. (Byte #0 really is zero.)
    Therefore, I get a desync after each output command, and if I issue an output command on every clock tick then I never get any sensor inputs.

    • Interesting. There isn’t much info on the 70909 on the net, but the few places that I can find just now, agrees with the two first bytes being zero.

      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?
        Yes.

        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.
        I can’t test any change to resync latency, because my box never drops data, so (once I made it not look at byte #1) it would work even without any resync support at all.

        > how you made Java talk to serial devices.
        Your suggestions to bob worked perfectly.

        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

  4. Wonderful java project. It took very little effort to get it working. The steps I took were:
    1. Download and install rxtx (hardest part).
    2. Load the src into Netbeans(java development ide).
    3. Remove bad imports in files.
    4. Fix imports using Ctrl-Shift-i
    5. Change com port to my usb serial device.

    Thanks so much my old computer which was running Control lab was begining to fail, and I was unable to get it to work with Windows 7(64-bit). Now i can port my code over to java which i prefer to program in anyways.

    • Cool. It’s really nice to see this controller (and the old code) still being useful. Thanks for writing this comment here as well.

Leave a Reply

Your email address will not be published.