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

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?

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

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, 2024Dec 16 by Toastie

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!

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, 2024Dec 28 by GunnersGarrison

.

Edited December 28, 2024Dec 28 by GunnersGarrison

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

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.

Hello and Welcome, Bliss.

Apologies on my former account's deleted posts.  I was having technical issues with that account, and once realising we can't delete accounts here (go fig??)... And no one replied to my requests for assistance over last year... I just blanked what few posts I had done, created a proper account, and will redo this latest post :D

That all said and done...

I had just gotten through reading (AKA skimming) this whole Dacta Control Lab topic, on this past Christmas day, when on that same day I received a delivery of my 2nd Interface-B (Yah, parcel deliveries on Christmas, and the guy wasn't even wearing anything red :) ). 

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.  

Eventually I was able to bypass a faulty resistor in the interface's Serial transmit circuit... and figured I would try out your program again, this time with it's multi-device option...  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.

I have reinstalled the latest .Net framework in-case that has anything to do with it (not something I actively use... but apparently did have already installed for something else.).  However, even that didn't work.  I can't understand what is happening... I click on the executable, it briefly shows the hourglass, flashed the drive LED... Then crickets...

If I hadn't actually seen and used your program the initial (and only) time, a day or so ago... I would be a bit SUS.  However nothing is flagged on my anti-virus, and I have rebooted, reinstalled .Net, removed and re-downloaded your zip file.  Even tried the installable option.  Again, it just briefly shows the hourglass, flashed the drive LED... and nada, zip zilch...???  

Oh well... I think I will just leave this alone and move on.

I hope others will be able to get it working and test it for you on multiple boxes.  Take care!

Edited December 28, 2024Dec 28 by Gunners TekZone

On 2/22/2024 at 8:04 AM, LH4PI said:

 

I put my  USB oscilloscope  directly on the  RxD pin pin  21 on the microcontoller Siemens SAB 80515  and  decode the message :

Thanks for this little tidbit...  It was what kickstarted my further testing of a non-functional Interface-B that I just received from ebay (and on this last Christmas day of all times).  All it did was blink the online/offline LED every 2 seconds when plugged into a serial link.  Nothing more.  Control Lab didn't even complain that it wasn't there... It just obviously didn't do anything.

I had opened it up and basically looked for obvious power, burnt, broken component issues, etc.  And having found none, had given up on it as having mystery logic issues and becoming a costly parts doner.

But after reading your post, and realising I have a cheap (cost and function) FNIRSI 1014D that I picked up about a year ago... and honestly barely understand how to use it.  But after reading what you did, I was motivated to try, and was able to get squiggly lines in the various spots I tested, and could confirm that something data like was entering (and possibly leaving... but looking drastically odd) the processor on the Interface-B.  But this crappy scope doesn't even have any Serial decoding.

Then I realised that I could probably use a simple USB-UART adapter, as used on Arduinos, etc. reading out on a terminal program.   And, yes... that worked, and I was able to confirm the starting phrase p\0###Do you byte, when I knock?$$$ was feeding into the processor. 

And more importantly... the Interface-B WAS responding with the acknowledgement command ###Just a bit off the block!$$$ followed by the data stream (that was causing the odd look on the scope)... It just wasn't getting any further down the line and was causing the unit to time out.

Some tracing later, and I found a faulty resistor... that was it!  And, not having such surface mounted parts, I just removed it and bridged the gap.  Now everything is working perfectly!!!  Again, thanks for your posting your trials that gave me the insight to continue my own :D

Edited December 28, 2024Dec 28 by Gunners TekZone

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, 2024Dec 28 by Bliss

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

3 hours ago, Bliss said:

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

Well... how silly of me to not check that, after everything else I was doing.  I was clearly not running on all threads...

My primary PC is a laptop without any Serial port, so I was using a USB-Serial adapter.  And had forgot to plug it back in when last attempting to check out your program. 

Amazingly, it popped up just fine with said adapter first plugged in.   TeeHeeHee...Oops!

The small PC I will be using all the interfaces on does have 4 built in serial ports, so forgetting that will be a bit harder :)

 

3 hours ago, Bliss said:

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 .

Thanks... Amazingly it also loads when the adapter is plugged in :P  (But I checked without anyhow... And still same ghosting issue.  Perhaps a warning if no COM port detected?)

Also... A suggestion?... When labeling the outputs, use A-H instead of 1-8.  That way it matches the Interface-B designations.

Now after my "morning" coffee, I will start testing with multiple interfaces.

3 hours ago, Bliss said:

Thank you for your feedback.

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

PS  You are welcome, and Thank You!  :D

1 hour ago, Toastie said:

Great work @Gunners TekZone! How did you actually find the faulty resistor?

Thank You!

I has set up Termite terminal to repeatedly send the startup phrase every 3 seconds.  Then with my USB-UART adapter/tester, I used that signal to confirm that the signal was getting to the Rxd pin (21) on the processor.  And then found the response on the Txd pin (22).

I then manually traced the... trace... from the via, off of the Txd pin on the processor, along the back of the board and up to a pair of resistors on the front, upper left of the board.  There is a translucent section where the UART optical isolation section is. 

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.

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

1 hour ago, Toastie said:

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?

Having only disassembled/reassembled it once, all I can suggest is A) Do NOT tip the opened "top" over... The red button and all those small light pipes will fall out and make a game of 52 card pickup look easy :D
The black and coloured 9v connection parts are clipped in, and will stay put just fine.

When disassembling, place the "top" face down on a smooth, hard surface.  The board can then be gently pried out around the edges.  The two grey plastic pins that look like they are holding clips seem more likely to be alignment pins.  Be gentle when releasing them, as you don't want them to break.

When reassembling, align the board as best able with the "top", then carefully press slowly across the board, where the connectors are, until they all feel solidly pressed into place.  Again, the two plastic pins seem more to be alignment pins then holding pins, and between them and the flared spring clips on the board, self aligning to the back of the "top" 9v connections goes fairly easy.

Edited December 28, 2024Dec 28 by Gunners TekZone

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

34 minutes ago, Bliss said:

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.

That executable seemed to work (I ran it from within the folder).  This time on a Windows 7 (32bit) system with fixed COM ports.  I did NOT install or update any .Net... just what may have been original, or installed with older LEGO Mindstorms programs.

As with the prior one (that I hadn't yet responded about), when attempting to connect the 2nd interface (Set COM3 and press Start Lego), even though I chose COM3, it crashed... referencing that it can't re-open COM2.

=================================================================

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.InvalidOperationException: 'PortName' cannot be set while the port is open.
   at System.IO.Ports.SerialPort.set_PortName(String value)
   at LegoNS.LegoInterfaceB.set_ComPort(String value) in C:\Users\sengx\source\repos\LegoDemoB\LegoInterfaceB.cs:line 64
   at LegoNS.Lego.CmbComPort2_SelectedIndexChanged(Object sender, EventArgs e) in C:\Users\sengx\source\repos\LegoDemoB\Lego.cs:line 61
   at System.Windows.Forms.ComboBox.OnSelectedIndexChanged(EventArgs e)
   at System.Windows.Forms.ComboBox.WmReflectCommand(Message& m)
   at System.Windows.Forms.ComboBox.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(HWND hWnd, MessageId msg, WPARAM wparam, LPARAM lparam)

************** Loaded Assemblies **************
System.Private.CoreLib
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
LegoDemoB
    Assembly Version: 1.0.0.0
    Location: 
----------------------------------------
System.Runtime
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Windows.Forms
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.ComponentModel.Primitives
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Windows.Forms.Primitives
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Drawing.Primitives
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Collections.Specialized
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Runtime.InteropServices
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Threading
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Diagnostics.TraceSource
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Collections
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Drawing.Common
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.IO.Ports
    Assembly Version: 9.0.0.0
    Location: 
----------------------------------------
System.Linq
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
Microsoft.Win32.Registry
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Memory
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
Microsoft.Win32.Primitives
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.ComponentModel.EventBasedAsync
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Threading.Thread
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
Accessibility
    Assembly Version: 4.0.0.0
    Location: 
----------------------------------------
System.ComponentModel.TypeConverter
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Numerics.Vectors
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Diagnostics.FileVersionInfo
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.ComponentModel
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
Microsoft.Win32.SystemEvents
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Collections.Concurrent
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.ObjectModel
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Private.Uri
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Collections.NonGeneric
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Threading.ThreadPool
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Threading.Overlapped
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Diagnostics.StackTrace
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Reflection.Metadata
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Collections.Immutable
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.IO.MemoryMappedFiles
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Text.Encoding.Extensions
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------
System.Runtime.Loader
    Assembly Version: 8.0.0.0
    Location: 
----------------------------------------

************** JIT Debugging **************

 

Edited December 29, 2024Dec 29 by Gunners TekZone

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

3 hours ago, Bliss said:

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

Got both interface-b's running... Using the 2nd link i think. 

- 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

- They both seems to work independently for the most part, but there is partial transference with the Set Power between the two devices. If I am keeping things straight... adjusting one shows the change in the other's setting, but not in real time operation.  However, stopping and restarting an output will use the new setting, regardless which "side" made the change (EDIT, sometimes only changes when the power slide is adjusted... i gets easily confused, so not always sure, heh).

And as an aside... I know aesthetics tend to come after function, but I think there needs to some clearer indication of which device is active on screen (besides the actual toggle buttons in the top left. Perhaps a larger font with customized name/title that displays above the controls??  I dunno... Or even just coloured borders?  I am not great at design... But I have found myself needing to triple check which device I am controlling... And this with only the two options to choose from so far, Hah!

And personally I prefer a layout similar to the device, using similar 2x4 layout on both input (1-8) and output (A-H) displays.  But then I do tend to have a visual orientation preference.

Otherwise, it is nice to have dual device control :D  Keep up the great work!

Edited December 29, 2024Dec 29 by Gunners TekZone

@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.

 

Edited December 29, 2024Dec 29 by Gunners TekZone

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

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 

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, 2024Dec 29 by Bliss

1 hour ago, Bliss said:

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

It says...

Stopped

Opening Serial Port on COM2...

Serial Port on COM2 Opened.

Sending Initialization Message on COM2...

Running on COM2 (But the STOP light on the interface is still lit)

Stopped

This only happens on any 1st attempt to Start Lego at initial start of application.  Once past that 1st attempt, connection works as expected for both devices.

Also, any attempt to change port while already running will crash app... similar to what happened when attempting to run 2nd device a few posts back.

 

@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, 2024Dec 29 by Toastie