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

[Bliss]

@Toastie

The sketch I provide is for UNO and NANO (They seem to share the same pins assignment and PWM pins too)  For the MEGA, it should also fit I guess as it has more of every type of IO's...

Now I use only the USB port of Nano and Uno for both programming AND Blockly.
At first I didn't know how to handle the USB port with blockly because the arduino resets the board with RTS or DTR not sure...
But now it work just fine with USB port for both situations, programming, or blockly.
So no need for USB to TTL adapter on pin 0, 1.

Arduino pins used are the only pins that allow PWM on the UNO and NANO.  (3, 5, 6, 9, 10, 11). 

You followed the LVL1 web site pinout for arduino and Int.A connector which is correct.  I guess you also need a couple of 5V and gnd?

For the inputs, I'm questionning the reason behind the use of analog pin as I wonder if Analog Inp is as fast as Dig Inp pins and really, the int.a inputs are on/off only anyway.
I think I read somewhere, it was to accomodate for custom sensors using resisors? I don't even know if int.a would report different value if we use a resistor for inputs...
I was thinking to add some input counters inside the arduino but for now I'm thinking to provide a general all purpose counter block in blockly and this might be enough for now...

Maybe you could do some test with the BK/WH disk wheel to see how fast blockly can read the input using serial protocol without missing a pulse.

Anyway, I'm playing these days with Int.A/B and let you know about the changes to Int.A.
For the moment, I keep the IO pins as is and I'm planning to add a MASK command to turn on / off multiple outputs simulaneously.  (The MASK command will be handled into the Arduino to be as fast as possible)
Because for the "Lego Lines" emulation I did for gunner project, I used a function but was sending 6 serial commands, so it was not realy simulateous.
But even if I manage the mask in the Aduino, it is still internally turn on/off the pins one after the other...  But it should still be way faster than using 6 serial commands...
Int.B already has spectial opCode for Multiple Output commands.
The mask for int.A I want to implement, will be a bit different as it will not need command ON or OFF FLoat etc, 1 will = ON and 0 = OFF., ex.: MASK 0x3C = Output 5, 4, 3, 2 forced ON and Out 1, 0 = forced OFF. 
But I might also implement the same behaviour as the Int.B.  MASK ON 0x03, = Turn ON out 1, 0 but leave out 5, 4, 3, 2 to their last state.  So a 1 in the mask means Do the Command (ON), a 0 means do nothing.
Anyway, i'm still thinking about it.  I don't think Multi Output commands will be used much...  And sending serial command one after the other is quite fast too. 

Today I added for Int.A and Int.B a simplified Output Command where you select the command with a Dropbox.
You drag this new bloc to turn ON a port, then you just duplicate the block (Right click on the block and select duplicate) and change ON for OFF.  Faster than going back in the toolbox to get the OFF block..

  

[Toastie]

@Bliss

Thanks a million!

3 hours ago, Bliss said:

I think I read somewhere, it was to accomodate for custom sensors using resisors? I don't even know if int.a would report different value if we use a resistor for inputs...

As far as I understood the circuit diagram, the outputs of the two sensor channels can only take on 0/1 (i.e., the opto couplers are either high impedance or low resistance, nothing in between), which leads to either almost 0V (emitters are tied to ground and as the diodes are emitting at quite some current, the transistors in the couplers are mostly saturated) or close to +5V (via the 2.2kOhm pull-up resistors, which securely induces a 1/H at TTL load). Thus, it appears that for operation with IntA there is no need for A/D resolved data acquisition.

Once I have everything up and running, I shall do the test. My gut feeling is that the hardware of the light change sensor in conjunction with the sensor input circuitry of IntA will be count-rate limiting. We shall see.

3 hours ago, Bliss said:

Anyway, i'm still thinking about it.  I don't think Multi Output commands will be used much...  And sending serial command one after the other is quite fast too. 

Yes, I believe so too.

All the best
Thorsten

Edited Tuesday at 08:34 PM by Toastie

[Toastie]

@Bliss

Got my Arduino clone to work with LBlockly, that was really easy!

Got to bike to work, quick question: When I turn one of the outputs (Arduio pin 3 wired to an LED), the power setting does not change anything; power 0, 10, 50, 255 => LED fully. LEDs do respond of course differently to PWM as lamps would, but I also don't see any flickering when waving the LED swiftly.

What PWM frequency are you using? I could try to read the Arduino code, as well as using my oscilloscope of course.

Thanks a lot!
Thorsten     

[Bliss]

@Toastie,

I tested the port 0 which is D3, using pwm with the following program and I can see my led dimming.  (Arduino Nano clone here)

So it is really 0-255 range of values.  I'm using a led with a 1k resistor.

What version are you using?  Can you show you blockly program?

If you just put the [LegoA1 Out 0 power x] block in the code area to test (with no loop), you must hit the run button at every manual change you make  in the power value.

Do not use the LegoA1 Out 0 ON with the Out 0 Power x block they must be used independently.

Out ON will force the Output to 255.  

 

Edited yesterday at 12:09 PM by Bliss

[Toastie]

2 hours ago, Bliss said:

I can see my led dimming

@Bliss Me too , sorry!

I am always using the latest version of LBlockly (first thing is starting Chrome, go to your website, wait a few seconds, close chrome, and start the app. 

My bad: I was following TC Logo logic: 

tto 0
setpower 4
on

setpower does not turn the output on, it just changes PWM. on does not change pwm, it just turns the output on with the latest PWM setting. 

I thus used: The "LEGOA1 out 0 power 3" block followed by the "LEGOA1 out 0 ON" block.

So I quickly was overriding the power setting block (which in parallel turns the output on) with the ON block, which I believe turns the output on with PWM = 255 = permanently on, right?

It does work nicely!

One more thought about PWM: 255 power levels are absolutely fine and really smooth. However, throughout the LEGO electronic devices I have (IntA/B and all PBricks), the power levels are 1 - 7 (IntA) or 0 - 7 (RCX etc., some software uses 1 - 8 and 0=off).  

1 - 7 for TC Logo + IntA; 0 = off): For the 4.5 motors as well as incandescent lights that is good enough, as these have a rather nonlinear behavior towards linear duty cycle changes. I believe this is the reason TC Logo has this also rather non-linear PWM 1-7 range.

When using NQC with the RCX, the power level is 0 - 7, with 0 = lowest PWM. You have to use off to turn it off.

But as said: 0 - 255 is nice!

All the best
Thorsten

[Toastie]

@Bliss

Another thought on the inputs of IntA.

As said, they can only take on 2 values 0 or 1. It thus does not provide any L/R information, in TC Logo counters (named 6 and 7) just count up upon change from false to true (= touch sensor pressed, or light sensor goes from bright to dark). They can count to a certain value, I have to check; this is a 16 bit value so quite a bit I guess. They either roll over or have to be reset. However, the models that are built in 4.5V Technic world hardly ever reach any critical count rate before they are "controlled" reset. When changing the spinning direction of a motor, the counter is simply reset, and then it gives you the same information as if it would count backwards automatically. And as said, every ms, TC Logo checks for changes of the inputs, and counts up accordingly.

If you want to catch these changes in LBockly, then I need to poll the inputs as fast as possible, using the "value changed" or "one-shot" blocks, correct?

If so, wouldn't it be better to count such 0/1 changes in the Arduino, all the time it runs? It can do that on the fly, couldn't it? And LBlockly just asks for that number? This could even be done in tasks? In the Arduino, the counters could simply roll over - when, e.g., 65535 is reached on a 4.5V LEGO model, something went wrong. Or can be easily taken care of by resetting the counter using LBlockly?

In TC Logo I reset the counters every time I start a program, same in QBasic with my counters. BTW this is one reason that I was polling the Arduino as fast as possible.

Or am I on the wrong path?

All the best
Thorsten  

    

 

  

 

[Bliss]

@Toastie

Each type of devices have their own protocol and different output commands...
For now, I implement the Device blocks according to each device own protocol...  So it'S not always the same.
Int.B has a separate Set Power Command and Out On/Off Command...
WeDo has only speed command -100 - 0 - +100 that's it...
Int.B, well, I made the block according to LVL1 protocol.  It one serial command that does it all which is more efficient.

In the futur, I might try to uniformize the input/output blocks, so all devices would use the same set of blocks in blockly, but behind the scene there would be conversion logic to send the commands according to each device's own protocol...
I'll note this on my ToDo list :-)

By the way, I did not yet change the version, but there is a new general purpose counter block in the Control Category (it is not a Counter inside the Arduino of Int.A).  It's not 100% ready yet but seems to be functionnal.
Please, to try it, you may have to do Ctrl-Shift R to force an update.

When the counter block is to my taste, I will change the version number of the app.
EDIT: I implemented the auto reset and changed the version number.

For the moment, the counter is not auto reset so you have to reset it in your program, but in the final version, the counter will be auto reset when done by default but configurable.

In the following example,  I just use an Int.A Input: So it will count only on raising edge i.e when input goes from 0 to 1. 
Note that Pre = Preset of the counter, i.e. the count you want to reach.  the Acc: is the accumulated value that you will see live.   When Acc = Pre, the counter is "Done" and output the boolean true.
So you can use it directly as a condition in Wait and If etc...

In this other example, I added a Value Changed? block to the input.  So now, the counter will count Raising and Falling edge which would give more resolution for the encoder disk.

I used the counter with the wait block but you can also use it in forever loop with "IF" as it is non blocking.

Edited 21 hours ago by Bliss

[Wapata]

9 hours ago, Bliss said:

I might try to uniformize the input/output blocks, so all devices would use the same set of blocks in blockly

If the idea is cool there is also a big risk of destroying previous program that happily worked before. Is there a way to reach a particular version in chrome ? In the saved program (in didn't looked if it is human readable with notepad or so) is there the version number used saved too ?

[Toastie]

33 minutes ago, Wapata said:

If the idea is cool there is also a big risk of destroying previous program that happily worked before.

That is true.

However, I believe we are, OK, @Bliss is, in a rapid development process were fundamental issues are still not sorted out. Right?

Best
Thorsten

 

[Bliss]

I do not have a test enviroment for the moment.

So I test new blocks code directly in the production web app page.

I do mess up the app once in a while but I quickly debug and fix it, or if it is too long, I will revert back to the previous working state...

Usually I do not change the version until the new stuff is working.

But, since I implemented auto update, sometime you may see some bugs sometime but it means that I'm on it and should be back soon...