Project: Programs to allow interactions between old Lego Control Interfaces (RCX, Lego Interface B, others?)

[Toastie]

5 hours ago, Bliss said:

As for your error msg, can you tell me what firmware you are using? is it an RCX 1.0?

Just to recall: All RCX PBricks (hardware) run fine and behave exactly with the same firmware. The RCX 1.0 had the (wonderful) power jack, TLG saved some money be removing that power circuit in version 1.5. The 2.0 RCX is just a 1.5 RCX with newer firmware ^^.

So the best RCX ever is the 1.0

Best,
Thorsten   

[Gunners TekZone]

OK... looks like it might be a python version thing... I had a "Doh!" moment and realised I have more serial IR towers, so can quickly swap the script and RCX between PC's for testing.

Tested on Win10(64) with Python 3.12.8 and it recognised the button press.

 

from legorcx import RCX
import time
rcx=RCX("COM2") # use the com port for you IR Tower.  
rcx.snd(1) # should play BEEP BEEP
rcx.sensor(1).type(rcx.TypeTouch) # configue input 1 as a touch sensor
rcx.mot(rcx.A).pow(7)  # Set power to max
rcx.mot(rcx.A).on()  # run lamp on output A
print("Dimming... Press button to step")
for x in reversed(range(8)):
    print(x)
    rcx.mot(rcx.A).pow(x)
    while not rcx.getval(rcx.SrcSb,0):
        pass
print("A = OFF")
rcx.mot(rcx.A).off()
time.sleep(.1) # needed to give prior command time to process before next command
rcx.close()

 

Dimming... Press button to step
7
6
5
4
3
2
1
0
A = OFF
Shutting down.

Edited January 20 by Gunners TekZone

[Bliss]

@Gunners TekZone,

Could you please try the new version I just put in the dropbox?

I modified the getval method with a little more proofing and it's not dependant of a fixed delay for the reply reading. 
Also added some timeout if it does not find the correct reply and will return "None" if it does not find a match.  (Meaning that you could check the value return == None to make some actions)

I modified the version numbering.  I adjusted it to 2025.01.20 and fits with the acutal day for now but the last number is really an incrementing number.  So if I put another updated file today, this number will be 21...

Let me know how it goes.

Thank you!

 

44 minutes ago, Gunners TekZone said:

OK... looks like it might be a python version thing... I had a "Doh!" moment and realised I have more serial IR towers, so can quickly swap the script and RCX between PC's for testing.

Tested on Win10(64) with Python 3.12.8 and it recognised the button press.

 

I guess that means that I used some python functions that are not anymore compatible with the python version that works on Win7...

I'll try to find which functions...

I'm using the Thonny's default python version 3.10.11 to achieve my tests... 

 

Edited January 20 by Bliss

[Bliss]

@Gunners TekZone

I updated again to version 2025.01.21.
You may try it again in win 7 who knows...

 

[Gunners TekZone]

11 minutes ago, Bliss said:

You may try it again in win 7 who knows...

Nice!  That worked on my original script right away 

And, yes you are correct... No need to the pauses in the switch routine.  Now more responsive in the stepping.

Edited January 20 by Gunners TekZone

[Bliss]

I updated again cause I added the following commands:

rcx.pwroff()  # Powers off the brick

rcx.sensor(rcx.inp3).clear() # clear the counter associated with the sensor.  A rotation sensor for exemple.

 

[Gunners TekZone]

6 hours ago, Bliss said:

So if I put another updated file today, this number will be 21...

How about  2025.01.20.x  With x reverting to 0 on next day?

Reason I say, is that I already used the file creation data to try and determine if I am running latest version or not.  Might as well keep the internal script version labeling the actual date of update (else confuse the snot out of people like me... "Whhhaa?... Did I sleep through the last few days or something?"  

[Gunners TekZone]

21 hours ago, Toastie said:

With regard to PBricks (of all kinds), I like them to be "autonomous" in their own micro-environment

I don't think this is the intent of Bliss's process... But it would be nice! 

That said, from a little Googling, running Python or even MicroPython onboard might not be a possible, or feasible, option on these little ol' yeller bricks   Too slow and not enough memory.

But as there are already many onboard OS options (Too many... I gets confused, thus never managed to use any of them), I would be happy with data/control/interaction sharing between an onboard OS of some flavor, and a PC running Python, handling communication with other newer devices running PyBricks.

Edited January 21 by Gunners TekZone

[Bliss]

I updated the legorcx.py.  (version 2025.01.21.0)

Added "alive" command (rcx.alive()) which returns True if RCX detected, False otherwise.

But I also rewrote the Read / Write engine.
It was originally taken from lego interface B python module that is using multithreading.
This is not needed for RCX as it is a Send command, read reply sequence.  Commands/Replies must execute one after the other as I can see.
So I had to syncronize between threads and I concluded that multithreading was not relevant for remote comm. with this brick.
The code is simplified so might be more efficient...

Let me know how this version works for you...

Thank you!

Bliss

Edited January 21 by Bliss

[Gunners TekZone]

5 hours ago, Bliss said:

Added "alive" command (rcx.alive()) which returns True if RCX detected, False otherwise.

Test file seems to work as indicated   On both my OS / Python versions.

[Bliss]

I just created a new topic about Lego Interface B and ESP32.

I thought it would be better in a new thread.