Dacta Control Lab Software

[Toastie]

On 12/13/2024 at 8:36 AM, LH4PI said:

info , well done 

Hi Lars,

thank you very much for your kind words, but this is a collective effort - I am just writing things up, many others have already reported ... in addition to a few things, that may not have been reported, but the net is wide - and so deep ...

Best regards,
Thorsten

[legoROBOLAB]

good morning friends

Do any of you have the original software that was sold with this book? Does it matter if it's for Mac, Acorn or Windows?

[BrickTronic]

20 hours ago, Toastie said:

Dear all,

more timing and some other data on #9751:

1. A serial port buffer is filled with 8192 bytes in about 9.6 +/- 0.2 s (used my QBasic program and watched for IF LOC(1) > 8191 THEN STOP with a 8192 long serial input buffer, did not read anything, just waited for the program stop along with my cell phone timer. Took a few replicates ... this is absolutely not elegant but quick ...
   In other words, 8191/19 = 431 19 byte long data frames are emitted in 9.6 s = 45 frames per second. Every 22 ms such a frame arrives.
2. One 19 byte data frame is (see above) 20 ms long.
3. #9751 samples the input ports for 130 us every 3.3 ms (used my very low profile digital oscilloscope).
4. Within 130 us, all 8 inputs of #9751 can be sampled, as the total sampling/conversion time for the microcontroller's ADC is 13 us (as per data sheet).
5. 3.3 ms x 3 = roughly 10 ms are required for a 3 bit increment in the internal "counters" for the light and rotation sensors.  
6. During sampling, the input port voltage is 5.0 V (10k internal pull-up resistor, see my last post), the remaining time it is 7.5 V for active sensor "charging".
7. When "shorting" an active input with a 9V lamp, it "glows" a little; "shortening" it with a current meter results in a current of 15.9 mA which is the max. current provided by each input of #9751, as was reported by Mark Bellis for the RCX inputs.

That's it for the moment maybe @Bliss, @BrickTronic or anyone else of course may want to check my calculations/assumptions? I tend to screw up such things regulary ...

Best,
Thorsten   

Hello,

nice update

1. 9,6s / 431 Frames = 22,27ms @ 190 Bit (19 * (1+8+1)) -> 117,23us/Bit => 8530,2Bd
   but : 50Hz (20ms per Frame) * 19 Byte = 950 Byte/s => @ 8192Byte -> 8,623s
   so 1s difference seems more than response-time issue because manual start/stop cell-phone timer usage ...
   Can you measure the real Baudrate (Oszilloscope) and the Frame-Repetition Frqueency ?
   -> does we really have 20ms per Frame ?
2. OK
3. Your measurement of 3,3ms with 130us is longer than Philo has evaluated for the RCX (3,0ms / 100us)
4. for 10-Bit Values 2 AD-Conversions are necessary (2x 13us * 8-Channel),
   and there has to be added also overhead in Interrupt Routine (save/store Register; modify DAPR and Multiplexer Register ...)
   not enough time for all 8 Channels
   different handling of active and passive sensors might not the case and makes Code more complicated
   (remind Status-Bit evaluation between Rotation, Light Switch & Temp seem to use same Thresholds)
   I assume that 130us measurement-slot has offset between previous and next channel
   => this can be evaluated by Oszilloscope
5. within a 20ms Frame there would be 6 Sensor-Readings but unly 3 increments can be communicated
   maybe some kind of Filtering ? or to supress spikes (changed Votage only accepted when following measurement is in same range ?)
6. did you measure "after" Bridge-Rectifier (+1,4V = 2x Diode-Drop) at Sensor or was this read from Oszilloscope Screen ?
7. OK

Jo

[Toastie]

Hi Jo,

thank you very much for your thoughts!!!

Well, I guess I can clarify a few things:

6 hours ago, BrickTronic said:

3. Your measurement of 3,3ms with 130us is longer than Philo has evaluated for the RCX (3,0ms / 100us)

Yes, but 130us is the minimum time. I initially thought something "jitters", but that is nonsense: There are 130us sampling and 260us sampling times (i.e. I see on the oscilloscope the trace going from 7.5V to 5V and back with rather sharp slopes for 130/260 us). Need to verify that because I just thought, it is my crappy experiment ... but this is real. I don't know (yet) how often the 130us sampling window width switches to 260us.

This is further supported by the frequency reading of the scope: It fluctuated between 230 and 300 Hz for the sampling rate. So 300 Hz is definitely an upper limit, calculated by the scope for tow or more consecutive 130us windows or the like ... again, need to look into that. 

6 hours ago, BrickTronic said:

4. SNIP (remind Status-Bit evaluation between Rotation, Light Switch & Temp seem to use same Thresholds) SNIP

Yes, I am pretty sure that is the case. However, for the rotation sensor data creation (bit 2 + 1,0), 4 voltages are evaluated; for all other sensors bits 5,4 + 3 are set upon crossing the same threshold voltage (or maybe two; one for 0->1 and one for 1->0 = hysteresis, will find that out using the power supply).

EDIT: There definitely is a hysteresis: Bit 3 goes from 1 to 0 (from "open" to "close") much earlier than returning from 0 to 1 (from "close" to "open"). I love QBasic

I am still "coding" my QBasic program, but upon some logical ANDing and bit shifting it becomes clearer: When banging a 4.5V touch sensor really hard into the seat (these sensors produce a bold short = are real on/off switches), the on/off bit as well as the #"transitions since last frame" change only once and then again when releasing the switch. Pressing the switch smoothly, everything becomes a bit nervous as ringing sets in: The on/off bit - well - goes on and off and then remains steady; the #transitions count goes up-to 20 and more, depending on how slowly I press. The rotation sensor bits also change, but of course in a meaningless manner.

6 hours ago, BrickTronic said:

6. did you measure "after" Bridge-Rectifier (+1,4V = 2x Diode-Drop) at Sensor or was this read from Oszilloscope Screen

I used a) my multimeter (on DC voltage) directly attached with a custom 9V cable to one of the active sensor inputs and b) my oscilloscope (it is a low-cost type), as I thought the sampling "drop" may cause some lower reading) - again it said 7.5V when not sampling and 2.5V for the sampling voltage drop to 5V.

Again, thank you very much!

All the best,
Thorsten

 

Edited December 16, 2024 by Toastie

[Bliss]

Hello,

I'd like to share with you a Visual Studio 2022 project I'm working on for the Lego Interface B.  (I'm no professional programmer.  Just doing this for fun)
I have some ongoing projects for this great lego box but this one is an Upgrade (Including Performance Improvements) and merge of existing projects I did in the past for the Lego Interface B.  (Originally, I did with VB.Net, now it is C# .net)
I just saw my Lego Interface B few months ago getting dirt on a shelf and decided to get back to it :-)

Here is the link to download this project:  Lego Interface B Windows Test Form

I already compiled it and you can find the .exe file in the Lego70909\LEGOInterfaceB\LegoProject\bin\Release folder.
It should work directly if you have .Net Framework already installed.
There is also a Publish folder with an installer that I did not tried.

It is working on my home Computer (Windows 10) and I tested it on my job laptop which is Win 11.  I had to resize the form though on the Win11 to see the Data Log textbox. 

The software is a form that shows Lego Intrerface B Inputs Status and have buttons to allow to control Outputs.  There is no way yet to make some programming like activate a motor when a touch switch is ON etc...  (this is on my to do list)
Note that for the Outputs, there are a OFF and FREE buttons.  OFF actually Stops and "BRAKEs" the motor, FREE will "Coast to Stop" the motor (FreeWheel).

The form has a log window but it is not perfect as it might hang when there is to much lines in the text box...
Also, The data is in Hexadecimal and sometime, would be better to Binary...
Improvement on this maybe in next versions or I might get rid of this.

One of the feature of this project is the use of multithreading and a Lego Class (Methods and Properties) that alows to create many instances of the Lego Box.
This Test project has 2 tabs on the top named Lego1 and Lego2.
So in theory, you can connect and run 2 Lego Interface B at the same time.

I do not have 2 Lego Interfaces B to test this feature unfortunately.

So I would appreciate if someone with 2 Lego Box could try this out and let me know how it goes.

 

Thank you and Happy Holiday!

[GunnersGarrison]

On 12/24/2024 at 5:16 PM, Bliss said:

I already compiled it and you can find the .exe file in the Lego70909\LEGOInterfaceB\LegoProject\bin\Release folder.
It should work directly if you have .Net Framework already installed.
There is also a Publish folder with an installer that I did not tried.

 

Edited December 28, 2024 by GunnersGarrison

[GunnersGarrison]

.

Edited December 28, 2024 by GunnersGarrison

[Guest]

N/A

Edited June 27 by Gunners TekZone

[Guest]

N/A

Edited June 27 by Gunners TekZone

[Bliss]

5 hours ago, Gunners TekZone said:

So while on Christmas Day I had tested your program briefly, on my existing Interface-B, and it worked! :) but I was too busy trying to fix my "new" one to do much more.  

...Only now your LegoB.exe doesn't do... anything?!?!... No error, no nada.  I rebooted and tried again... still nothing.  Odd???   I run Windows 10, 64bit.

 

Hello @Gunners TekZone,

Thank you for your feedback.

Congrats fixing your faulty Interface B!!!  Hats off!

When you say you rebooted, you rebooted you PC or the application only?

At the top of my program windows form, you select the COM port and  click on Start Lego.  Under the Start/Stop Button there is a textbox that shows the status of the connection and initialization...
Do you get any statut message in this little texbox after you click the Start Lego Button?

Did you try the EXE file in the BIN folder directly or used the setup in the publish folder?

I noticed that if I select the wrong COM port and click start lego it may hang eventually and the only way to get back to normal is to remove the USB RS232 adapter and reconnect it...

I updated the link with an improved version (I think).  I also used costura.fody to build a standalone exe that has supposedly all dependant libraries DLL etc.
Use the EXE file in the ...LLEGOInterfaceB\LegoProject\bin\Debug\app.publish .

UPDATED Lego Interface B Test Program

Thank you again.

 

Bliss

 

Edited December 28, 2024 by Bliss

[Toastie]

Great work @Gunners TekZone! How did you actually find the faulty resistor? I have some issues with output A of my #9751 box: It turns on for a few seconds when told so, but then goes off again. Turning it off then back on repeats the behavior. All other outputs are fine. Must be something in the driver circuit, I guess?

And thank you for your Windows programs, @Bliss!

I am currently "stress testing" my Interface B with my own QBasic program running within DOSBox-X. Here is a preliminary screenshot:

This program builds on the QBasic interrupt controls ON COM and ON TIMER along with some further interrupt control during text output; the entire screen output is text based and thus rather fast, even when emulating a DOS PC system with a 286 processor running at 25MHz in full QBasic 1.1 interpreter mode. Compiled to a DOS3.3 compatible stand alone EXE using QuickBasic 4.5, which results in a less than 70kByte long file, it runs very smoothly and allows close monitoring of the inputs and outputs, as well as running simple user programs for parallel operation of the outputs etc.

As #9751 simply does not know which sensor is attached to any of its inputs, I decided to monitor all available input data (according to the "bit sheet" posted further above). These are the data in the 4th and 5th screen row in the picture above: Either raw data (A/D), transitions (0-1 + 1-0 are counted up) or rotation clicks (counted up/down - 16 per sensor revolution), plus rotation sensor direction (the +/- signs directly right to the data field) and finally sensor open/close. Outputs are all controllable in parallel, for manual control just hit the 1–8 buttons: Toggling means hit once = on, twice = off; press and hold means "as long as you press a button" it is on; used the well known and stone old DOS 0x60 "trick" (access to the keyboard shift register) to get rid of the keyboard delay and repetition hassle:

DO
  DEF SEG = 0              'absolute adresses 0-65535 for PEEK/POKE
  POKE &H41A, PEEK(&H41C)  'POKE tail byte to head byte of keyboard buffer = clear buffer
  DEF SEG                  'return to default program data segment
LOOP WHILE INP(&H60) < 128 'loop until key is released

SHIFT + 1–8 reverses the output direction; in manual mode, you can navigate to the corresponding output using the keyboard arrow keys, then hit "+" or "-" to increase/decrease power. The same procedure is used to change the displayed input data format (or the sensor type, but this is irrelevant and just for reminding me, which sensor is attached to any of the 8 inputs).      

Using this QBasic program, I believe in having found some further information on the behavior of #9751:

Outputs:

• Byte 2 in the 19 byte frame is not providing permanent information of the status of the outputs, but is rather delivering an acknowledgement from #9751: The outputs turned on with a command sent (for either one or more outputs) is acknowledged in the next sent frame as 8-bit coded (output H = bit 7, A= bit 0); the corresponding bit is 1 for each output turned on (regardless of power setting). During arrival of the next frame, all bits are 0 again.

Inputs:

• The rotation sensor thresholds for the "four states" per 1/4 clockwise revolution are 1023/784/354/536 A/D units corresponding to 4.8/3.7/1.7/2.5 Volt. I simply watched the A/D values when slowly turning the rotation sensor axle clockwise and used my A/D counts to voltage diagram also shown above for conversion.
• On each transition between these values, e.g., from 1023 to 784 = cw, the rotation direction bit4.2 changes accordingly (to 1) and then the increments since last frame (bits 4.0 and 4.1) can be accurately added or subtracted to a software counter. A transition from 536 to 354 results in an immediate rotation direction bit change to 0 = ccw and so on.
• The rotation direction bit is always "0" for (passive) inputs 1–4.
• The open/close bit4.3 is behaving a bit more sophisticated than I previously thought: It changes from open (1) to close (0) upon a transition from a higher A/D value to a lower - this seems to be around 200 A/D counts. Similarly, it changes from close to open the other way around. Should this really be the case, I can see why they did that: Transitions on e.g. light sensors can then be monitored with much more flexibility: Expose the sensor a light source considered bright, then make sure that a dark state is about 200 A/D counts below that reference, and you can react accordingly without any programming efforts on the controlling computer side, as #9751 does that for you with bit4.3!  

All the best,
Thorsten

[Guest]

N/A

Edited June 27 by Gunners TekZone

[Guest]

N/A

Edited June 27 by Gunners TekZone

[Toastie]

1 hour ago, Gunners TekZone said:

I found the correct via and resistor with the signal, but it ended on the other side of the resistor.  I expeditated my resistor test with a fine tweezer across the resistor (to short it) and suddenly my terminal started showing the response signal. 

How cool is this! Nicely done. So I guess I shall open my Interface B once again! When you pull off the top cover, all the "snap-in" type connectors need to come off. Is it tough to get all of them back on when reassembling?

Best,
Thorsten

[Guest]

N/A

Edited June 27 by Gunners TekZone

[Bliss]

I uploaded a new version of my Lego Demo windows app compiled with .net 8.0.

Before it was .Net Framework 4.8...

Here is the link for the whole souce and bin files...

I tried to compile a standalone exe but not sure yet if really did...
You should look at the exe in: folder LegoDemoB\bin\Release\net8.0-windows\publish\win-x86.

 

Bliss

[Guest]

N/A

Edited June 27 by Gunners TekZone

[Bliss]

Thank you @Gunners TekZone for reporting the bugs.

Indeed I did not test the opening of the second port while the first one was connected.  (Even if I do not have a 2nd lego interface B, I have other com ports and just selecting one of them while one port was already in use, did give the same error.)

 

So I think I found why and made the corrections.  I updated the Projects:

Updated Lego Demo Project in .Net Framework version.

Updated Lego Demo Project in .Net *.0 version

 

Bliss

[Guest]

N/A

Edited June 27 by Gunners TekZone

[Guest]

N/A

 

Edited June 27 by Gunners TekZone

[BrickTronic]

13 hours ago, Toastie said:

...

• The rotation sensor thresholds for the "four states" per 1/4 clockwise revolution are 1023/784/354/536 A/D units corresponding to 4.8/3.7/1.7/2.5 Volt. I simply watched the A/D values

...

Thorsten

Hello,

your values looks strange.
When you divide Voltage by ADC-Result there should remain Voltage of a LSB :

3rd Line is 1 LSB in mV
and 4th Line is LSB * 1024 Full-Scale ...

I would have expect 5,00V as ADC-Reference taken from 5V linear Regulator and not less, something arround 4,8V ...
 

Jo

[Toastie]

34 minutes ago, BrickTronic said:

When you divide Voltage by ADC-Result there should remain Voltage of a LSB

Hi Jo,

you are right of course, however, this is what I got when attaching my rather powerful regulated power supply to the input ports. At 4.8V, readings maxed out at 1023. There is of course an experimental margin of error; at least with what I am doing, which can be done much better. I am rounding off after the first voltage digit, as this is all what my power supply shows. Then I can turn the voltage dial back and forth a bit; the number on the power supply display stays the same. Also, the reported A/D numbers are not LSB-stable. The wire I used to connect the power supply to the 9V inputs is a 4.5/9V hybrid. The contacts on my interface B box have not yet have had a full deoxidation = reduction clean - the A/D reading depends a bit on how I clip the 9V terminal onto the sensor input, and so on. And then there is this 10kOhm resistor inside #9751 that the external active sensor has to fight. All in all, there will be quite some overall error - students in my lab courses literally love it when I ask them to calculate the error propagation ... 

Not the point though: With all these errors, everything is still working without glitch: The counters count up/down with no error, even when counting to several hundred and comparing the revolutions. I guess there is quite some tolerance inside #9751 firmware - so my reported values may be still good for orientation.

Thanks again for your interest - I really appreciate your comments and checking!!!

All the best,
Thorsten 

[Bliss]

11 hours ago, Gunners TekZone said:

@Bliss  Hah, I just realized that I can run multiple instances of the program... Nice!... And no apparent conflicts between them. 

So short of cross device program-ability in the future, what is the reasoning of dual (or more) device control in a single instance?

Honestly, if Windows DACTA Control Lab had the ability for running multiple instances, then that would be near perfection in my mind.  Yes, somewhat limited programming, due the older TC LOGO language, but by far better than anything else I have tried so far, particularly with the WYSIWYG GUI side it also incorporates.

 

Thank you for all your comments, recommandations and observations.

I did not even notice we could run multiple instances of my Lego Demo Program :-)

But actually, my ultimate goal, is to integrate some kind of basic language to allow the user to program logic interacting between inputs and outputs of more than one Lego Box.

I will post a very preliminary version of this program that i'm working in parallel.  It uses the same lego class engine but I removed all the buttons for now and provide just a textbox to enter a script and an output textbox to display results when applicable.
This program will be a standalone exe.

I was also thinking about making another program to control the Lego InterfaceB that would integrate an MQTT Client, i.e. some kind of Lego Gateway, so users could use Home Assistant and/or Node-Red (Home Automation) to program logics to interact between lego boxes on same PC (Program would allow 2-3 Legoboxes to run) and even between PCs with 2-3 lego  boxes on each PC... 

 

About the Lego Demo progr., you said:

Quote

- The first time program started, Lego1 or Lego2 (whichever is first to run) needs to be started twice before it holds (disconnects the 1st time).  After that they both can be stopped and restarted OK

Was there any error message in the textbox of the one that gets disconnected?

 

Thank you again for your precious help.

Edited December 29, 2024 by Bliss

[Guest]

N/A

Edited June 27 by Gunners TekZone

[Toastie]

@Bliss

Fantastic work!!! I downloaded your Zip file earlier in the day. The application works very nicely, as @Gunners TekZone has already posted. Very cool. I am really happy that Interface B software gets full up-to-date support (from users of course, TLG can't do that anymore - they are frying other fish ...

Furthermore, I looked a bit into your code to finally figure out what was wrong with my stopping the motor using float. They always stopped with break; I simply used a wrong opcode. Thank you very much!!!

I also take the freedom of "suggesting" (nothing else!) a little change to your program: What I display in my QBasic program is the last rotation direction, as long as it stays the same. In your approach, the cw/ccw textbox briefly shows 1 then returns swiftly to zero, at least I believe so. Other than that: Nice(!!!) interface.

With regard to the interface "looks": I am a bit on the functionality side and would not necessarily change the software form to match with the interface "form". As far as I am concerned, you can unleash the power of interface B only in programming mode. Pointing with the mouse or using hotkeys is fine, but naturally limited to changing the properties of one output at a time. Which is totally OK in manual mode. However, turning 4 outputs on at the same time or clearing rapidly counters is only possible in programming mode. So: I'd leave the interface as is or better orient the layout along programming rather than manual control options. Well, just my 2 cents and personal view!

All the best and keep on the good work!
Thorsten

Edited December 29, 2024 by Toastie