Bliss

I did the same observation as I mentionned in a previous post that I suspect you have not seen as we posted almost at the same time.

Congrats! One small step for man, one giant leap for old lego fans ;-) We can now think of using Smart Home Hubs and devices like Home Assistant, Hubitat, SmartThings, name it, that supports MQTT, to start/stop an "Old 9V Train" automatic sequence that uses Lego Interface B. We could add a button on Home Assistant (HA) UI (I'm using Home Assistant) or use HA Automation, or Node-Red Plugin that will use MQTT to interact with the Lego Box... That certainly gives some ideas...

@Gunners TekZone If we forget about win7 for a moment and come back to win10, I think the unknown location problem is related to: https://github.com/pythonnet/pythonnet/discussions/2420 If you put the whole directory of the LegoClassB.zip inside your python working directory, then it appears the PATH starting with the LegoClassB folder is already seen by Python because Python automatically uses the working path in its seach path for modules... The folder named LegoClassB conflicts with the DLL file Name. So in "from LegoClassB import LegoInterfaceB" line, Python prioritize the Folder as a package at first... So, remove the LegoClassB folder from your working directory and leave only the LegoClassb.dll in your working directory along with your .py files and just do like my second previous post. OR, rename the LegoClasB folder to make it different than the Dll file name. >>> import clr >>> clr.AddReference(r"C:\Users\sengx\source\repos\Python\LegoClassB\bin\Release\LegoClassB") <System.Reflection.RuntimeAssembly object at 0x000001B853287740> >>> from LegoClassB import LegoInterfaceB Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: cannot import name 'LegoInterfaceB' from 'LegoClassB' (unknown location) >>>

Just answering my question about python compatibility with windows 7.

@Gunners TekZone I copied the LegoClassB.dll (ONLY This DLL) in a Python work Folder along with the .py file (Same ones than in the dropbox link). In Thonny, on the Files pane on the Left, I selected this Pyton Folder and see listed the Dll and the .py files. This becomes the working directory. In the LegoTrain_01.py, the path was simply the name of the dll: import clr clr.AddReference(r"LegoClassB") from LegoClassB import LegoInterfaceB Lego1=LegoInterfaceB() Then I hit the "Play" button in Thonny and this is working here very well too.

@Gunners TekZone But at some point you said it was working no? Is it working in the Python CLI now or not? Is it only in Thonny that you have problems? Is it working in Windows 10 but not in windows 7 ? (I think I read somewhere, pythonnet would not work well on win 7)

Here is a link with some Python Programs I adapted to Thonny: Sample Lego Interface B Python Files

When I paste the content inside the code box into NotePad++, it shows a stange character at the end of: from LegoClassB import LegoInterfaceB It happens often in the forum Code Window... I have to double check some time... (These character are not visible in the final post but we can see them in notepad++ and sometime, in the code edition window.

I'm guessing it is possible to install the pythonnet library (Which allow the use of import clr) in the thonny environment. First go back in the menu Run, Configure Interpreter and select the Thonny local python.exe as the python executable. In the menu tools, click on open system shell. I think it is possible from there... From the shell, I entered: pip install pythonnet and it did install in thonny libraries... Then from the Thonny local python 3.10, I was able to use import clr etc...

@Gunners TekZone So I installed Python 3.13 and uninstalled older versions and updated manually the PATH system variable in windows (Control Panel, in the serch bar, entre "Path", click modify environment variables, in the next window click at the bottom Env. Variables...) After that I reinstalled with a Dos Window, the python net using pip install pythonnet. I checked with the Python 3.13 CLI that I was able to import clr, AddReference to my LegoClassB and use LegoInterfaceB... Everything was OK... Then in Thonny now - Thonny uses its own Python exe... So, You have to go in menu run, Configure Interpreter, Interpreter Tab and specify the path and exe of the python 3.13 which is the one that has python net installed... - Now, in the Thonny Shell, it will show Python 3.13.1. - If you enter import clr at the >>> prompt it should work

I just installed Python 3.13 and uninstalled 3.11... But there are still traces from old versions... The "Path" environment variable was still set with 3.10 ... I corrected this so pip is now back fonctionning... So make sure your PATH is set correctly...

I did not run into this situation yet but I'm not testing as much as you do I guess... I'm using Python 3.11. ... >>> from LegoClassB import LegoInterfaceB >>> Lego1=LegoInterfaceB() >>> Lego1.ComPort="COM14" >>> Lego1.StartLego() >>> Lego1.Inp[1].On False >>> Lego1.Out[1].On False >>> Lego1.Out[1].On=True >>> Lego1.Out[1].On=False >>> Lego1.Out[2].On=True >>> Lego1.Out[2].On=False >>> Lego1.IsRunning True

The lego Interface B code (Communication, Reading continuously and Decoding of Inputs and writing commands) is all done in what they call a C# Class which you can explore de code by opening the LegoInterfaceB.cs with notepad or Notepad++. LegoInterfaceB.cs is located in the complete zip package directly in the root folder (Ex. LegoClassB folder) When we compile a class it becomes a DLL (Library) and even in the LegoSciptB and LegoDemoB, there is a LegoInterfaceB.DLL but I tried to import it in Python and didn't work... I had to compile with a different .Net...

Anyway, I think you're right, IronPython integration to C# is probably very minimum... But since you aready have Python 3.X on your PC, you could do the other way around... Use Lego directly into python... You could use the Dacta Python program that you found here: https://www.shamlian.net/projects/dacta/index.html I did not personnaly had time to look at it. But I'm guessing it might work very well. OR You could use my Lego DLL directly in Python but there are few step to achieve this. I did some test and I will describe the steps I followed. I'm still very newbie at Python. I compiled the Lego Interface B program as a Class Library (DLL). Only the part that manages the Interface B, No IronPython. At first it did not work. To make it work, I had to compile it using .Net Framework 4.7... 1. You have to intall Python Net from the CLI (Command Line Interface, I just opened a Dos Command Window) You type in the command line: pip install pythonnet and press enter. Make sure it has installed properly. 2. Download my LegoClassB: Link to my LegoClassB 3. In python IDLE Shell or Python CLI, enter the command: import clr If pythonnet installed correctly there should be NO Error. 4. Now enter the following: (Please note the small "r" at the beginning of the path to tell to use raw string or you may get a problem because of the use of "\") LegoClassB is the name of the DLL without the extension DLL... clr.AddReference(r"C:\...\LegoClassB\bin\Release\LegoClassB") If things goes well, Python will respond with: <System.Reflection.RuntimeAssembly object at 0x000001BEF230C9C0> 5. Enter the following: from LegoClassB import LegoInterfaceB if there are no Errors, then you are in business. 6. Enter the following one at a time to declare the Lego1 Interface and configure the com port, start and try (Do the same for Lego2, Lego3, Lego4, Lego999 lol, but first lets make it work with Lego1) Lego1 = LegoInterfaceB() Lego1.ComPort="COM1" Lego1.StartLego() print(Lego1.IsRunning) Lego1.Out[1].On=True Let me know how it goes. I think that you should have more luck with having MQTT to run with Lego box at the same time... But still, there might be some surprises...

Here is an attempt to make a script for the first part of your train program (9V train part) . In that script, You have to change the com port, CN_Auto_Speed (I set it to 7), and the LightSp = 550 (Light Setpoint). The light setpoint is very different than you program which is Light < 70. Also, this appears to be reverse than the Value I programmed for the inputs. I suspect that ControlLab software/TC Logo is using a special calculation for the Light sensor. Me, I just take the raw 10 bits value... So might be a good Idea to use the LegoDemoB program to test the your Light8 and Light7 value when a train block the sensor and the value when it clrears the sensor. Then adjust the LightSp variable accordingly. So, in "while not C() and Light8.Val < LightSp :" , when Sensor is clear (sees the light), value is around 480 (For me), and the code is looping, and when Sensor is blocked, it gives a value over 620. So the loop will end when Sensor has a value > LightSp (550) import time Lego1.ComPort="COM14" Lego1.StartLego() time.sleep(1) C=lambda:cancellationToken.IsCancellationRequested LampB = Lego1.Out[out.B] SoundC = Lego1.Out[out.C] MotorD = Lego1.Out[out.D] LampF = Lego1.Out[out.F] MotorH = Lego1.Out[out.H] Touch4 = Lego1.Inp[4] Light7 = Lego1.Inp[7] Light8 = Lego1.Inp[8] LampB.Dir=True LampB.On=True MotorD.Dir=True MotorD.OnFor(20) time.sleep(2) SoundC.Dir=True SoundC.OnFor(20) time.sleep(2) CN_Auto_Speed=7 LightSp = 550 # Light Setpoint while not C(): MotorH.Dir = True MotorH.Pow = CN_Auto_Speed MotorH.On = True while not C() and not Touch4.On: pass MotorH.On = False LampF.On = True time.sleep(1) SoundC.Dir=False SoundC.On=True MotorH.Dir = False MotorH.On = True # backup until trigger light sensor while not C() and Light8.Val < LightSp : pass MotorH.On = False LampF.On = False SoundC.On=False MotorD.Dir=False MotorD.OnFor(20) time.sleep(2) break LampB.On=False Maybe it is because you tried first the code import sys sys.path.append(".\lib") And it worked . Then you change the path but the last one (.\lib) was still in memory (Once the parh is appended, i suspect it remains in the session even if you modify the script or clear the script textbox windows and run the script again with a new path append. But shuting down the LegoSriptB program completly must reset the memory... and when you run it again, or a new version, it will not find the random.py if you only append the ...site-packages folder because random.py does not exist in this folder.

This should work no? import sys sys.path.append("C:\\Users\Gunner\AppData\Local\Programs\Python\Python313\Lib\site-packages") sys.path.append("C:\\Users\Gunner\AppData\Local\Programs\Python\Python313\Lib") import random import paho.mqtt OR MAYBE JUST: import sys sys.path.append("C:\\Users\Gunner\AppData\Local\Programs\Python\Python313\Lib") import random import paho.mqtt

I made a small correction in LegoScriptB because there was a small glitch in the OnFor method... LegoScriptB Link For reference, here is LegoDemoB Link

It still work for me. Is random.py in "C:\\Users\Gunner\AppData\Local\Programs\Python\Python313\Lib\site-packages"? Should C:\\ be C:\ ? For me random.py is in ...AppData\Local\Programs\Python\Python313\Lib\.

I made a big change in the LegoScriptB program and the previous Examples will not work anymore. Please, use the examples provided in the README file. New version LegoScriptB Before: Lego1.SetOn[3] = True if Lego1.InOn == True: Now: Lego1.Out[3].On = True if Lego1.Inp[1].On: This allow us to do the following: MotorA = Lego1.Out[out.A] Touch1 = Lego1.Inp[1] Example: import time Lego1.ComPort="COM14" Lego1.StartLego() time.sleep(1) MotorA = Lego1.Out[out.A] Touch1 = Lego1.Inp[1] MotorA.Pow = 7 MotorA.Dir = False while not cancellationToken.IsCancellationRequested: MotorA.On = Touch1.On time.sleep(0.020) I also added a method in the outputs calle OnFor(Delay) Delay = 0-255 tenth of second. Lego1.Out[1].OnFor(20) will activate Output A of Lego1 for 2 seconds then deactivate it. It will not block the program flow, if you want to block, use after time.sleep(2) to wait 2 sec.

Actually, I'm using IronPython and I'm not sure what version of official Python it is using.

Seems that the Lego script B program does not embed this module. (I'msearching if it is even possible to embed some python modules in the exe...) But from what I found out, In the publish folder of Lego Script B, where the exe is also located, there is a lib sub folder with a bunch of .py modules... So, you could do this: import sys sys.path.append(".\lib") import random print(random.random())

Hello, thanks for your interest! About the RCX, I already owned few of those but unfortunately I sold them all. I should have kept one at least :-) But as far as I remember, the serial/Infrared link between the PC and the RCX was only to send a program to the CPU inside the RCX (and to update/upload the firmware). The user program was running on the RCX in opposite of the lego interface B where the user program runs on a PC/MAC/Raspberry Pi etc. Lego Interface B is like a remote Input and Output passive device linked to a Main Programmable Logic Controller (PLC, yes I have a backgound in Industrial PLC Programming :-) ) RCX, is an integrated PLC that has it's own Local I/O's (Not remote). Unless you can put a firmware in the RCX that will make it acts has a dummy remote I/O gateway that waits for Output commands from its Infrared port and continuously sends sensors values to the IR port? I recall there was custom firmwares back in the days like NQC, (Not Quite C) and more... I did not check since if there was more custom firmwares available for the RCX.

@Gunners TekZone, Thanks for all the details. The logo program already talks a lot by itself without knowing much about this language. It's pretty simple. That gives me ideas to implement few more commands of the lego interface B that I did not yet tested... About the logo "onfor", I understand that this activates an output and deactivates after a delay, like onfor 20 will activate output for 2.0 seconds and deactivate output after the 2sec elapsed. But I wonder if the logo "onfor 20" will prevent any following instructions to execute unti the 2.0 delay has elapsed. So in the following for example, the MotorH will activate after 4 sec ?: (MotorD, which I believe is the track sw, activates for 2 sec, then after this 2 sec, MotorD stops, SoundC activates for 2 sec, then after this delay, sounds will stop and MotorH will activates. tto "MotorD setright onfor 20 tto "SoundC setright onfor 20 tto "MotorH setright setpower CN_Auto_Speed on According to you video and the timing, that's what it looks like. Right? Thanks again.

Nice. Can you paste somehow your TC Logo program? What are the inputs and outputs? I guess a picture of the program would be enough if cannot paste or have a text file... I never used the original control lab software... Maybe I should have tried it to get familiar with the functions. Could have given me some ideas...

I updated the LegoScriptB in the Dropbox link (See my post above). I just added the possibility to use out.A to out.H as the output port number for the output type properties (SetOn, SetFree, SetDir, SetPow). Ex.: Lego1.SetOn[3] , Lego1.SetOn[out.C] , Lego1.SetOn[out.c] are now allowed to activate/deactivate Output Port C. I also replaced SetON by SetOn (Lowercase N) and changed the example codes in my previous post...