Jump to content

Recommended Posts

Posted

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

chrome_CTdOQk4o9m.png  chrome_KjDxJ50Cwf.png

Posted (edited)

@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 by Toastie
Posted

@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     

Posted (edited)

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

chrome_DpWCmWPyd3.png

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 by Bliss
Posted
2 hours ago, Bliss said:

I can see my led dimming

@Bliss Me too :pir-hmpf:, 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

Posted

@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  

    

 

  

 

Posted (edited)

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

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

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

chrome_jViibiqnQJ.png

Edited by Bliss
Posted
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 ?

Posted
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

 

Posted

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

Posted (edited)

I added a device called VLL Serial.

It is the Lego VLL protocol implemented directly into the Lego Blockly app and it uses a serial port but only for the DTR pin.  (ONLY to SEND data.  NO receive data implemented)
You can use a USB to RS232 adapter and a led wired somehow to the DB9 connector pin 5 gnd to LED negative and 4 DTR pin to LED positive through a resistor maybe.  (1K is standard).
OR you can use a FTDI USB to TTL serial.  But for the FTDI, the DTR signal appears to be reverse, so the DTR goes to Led (-) and the 3.3v goes to Lef (+) (with resistor).

tested both method with a Code Pilot Brick (You have to hit the record button before sending any VLL data.  I think for MicroScout you have to press P?).  I used a White LED.

chrome_Sk6jnBLuXl.png

I also added a block to adjust the Preamble pulse because to send continuous commands to Code Pilot brick, I had to use a 1000 ms (1 sec) pulse between the commands.
But for Micro Scout that I do not own, you may probably decrease this number to 400 or 120ms...  Has to be tested...
You just need to use the Set preamble at the beginning of your chain of VLL send data commands.  Not at every send command...
Internally, it is set by default to 1000.  So no need to use this for the Code Pilot.

chrome_zFbx8cBbqQ.png

EDIT: I also added a block to change the "UNIT" of delay for the smallest pulse.  The documentation says 20 ms (a white or black bar may have 1 or 2 unit large, stop bit has 3 I think), but since I can scan barcode at different speed I thought we could experiment on this unit delay and to my surprise, I event tried with 5ms Unit and it still work with the code pilot and the LED as close to the brick led as possible. 
chrome_xtuQtr0mzw.png

 

Here is an example for sending multiple command to the Code Pilot brick:
chrome_l6gexfrxoB.png

The VLL Data must be between 0-127.

The codes are described at the end of the ScoutSDK.pdf.
https://pbrick.info/index.html-p=184.html

 

Let me know if it works for you.
I would like to hear about someone who can test it with the MicroScout.

 

IMG_7799.jpeg IMG_7800.jpeg

Edited by Bliss
Posted (edited)
5 hours ago, Bliss said:

I added a device called VLL Serial.

It is the Lego VLL protocol implemented directly into the Lego Blockly app and it uses a serial port but only for the DTR pin.  (ONLY to SEND data.  NO receive data implemented)
You can use a USB to RS232 adapter and a led wired somehow to the DB9 connector pin 5 gnd to LED negative and 4 DTR pin to LED positive through a resistor maybe.  (1K is standard).
OR you can use a FTDI USB to TTL serial.  But for the FTDI, the DTR signal appears to be reverse, so the DTR goes to Led (-) and the 3.3v goes to Lef (+) (with resistor).

...

Hello

Why not use same Methode used for Spybotic :

 

image.png.b12af47eed3f9d1149e80b7f3930af82.png

And yes, you need also an TTL/RS232 Level-Translator like the good old MAX232 or compatible ..
 

Jo

Edited by BrickTronic
Posted
2 minutes ago, BrickTronic said:

Why not use same Methode used for Spybotic :

What does this circuit do exactly?

Do I see some light receiver? If yes, I guess this would allow to read VLL as well as Send VLL commands?

I'm not sure I understand what the TXD and RXD are doing since the VLL speed varies...

Is it documented somewhere?

Thank you!

Posted
30 minutes ago, BrickTronic said:

Why not use same Methode used for Spybotic

Because it work with two components, why use more ? :laugh_hard::iamded_lol:

Side note, how can I create a barcode dictionary with the ones I own, other than making a photo ? Because there is some in the manual that are nowhere on the internet...

... I need more serial and ttl devices :facepalm:

Posted
1 hour ago, Wapata said:

Because there is some in the manual that are nowhere on the internet...

Do you mean for the CodePilot or the MicroScout? I have assembled these:

CodePilot:

800x483.jpg

MicroScout:

800x475.jpg

Are there any more? Maybe on the Spybots?

Best
Thorsten 

 

Posted
4 hours ago, Toastie said:

Do you mean for the CodePilot or the MicroScout? I have assembled these:

CodePilot:

 

MicroScout:

 

Are there any more? Maybe on the Spybots?

Best
Thorsten 

 

Hello.

I'm aware of (see png), Jo

vll.png

Posted (edited)
7 hours ago, Bliss said:

What does this circuit do exactly?

Do I see some light receiver? If yes, I guess this would allow to read VLL as well as Send VLL commands?

I'm not sure I understand what the TXD and RXD are doing since the VLL speed varies...

Is it documented somewhere?

Thank you!

Hello,

Reverse-Engineering of this Interface you can find on Youtube

The Spybot uses not IR-Puls like RCX but a RS232--to-(visual)-Light Interface.
There is Read and Write possible (4800Bd, 8-Data, Odd Parity, 1 Stop)
VLL Output is above serial-Interface
There is also a IR-Remote (76kHz 25% Duty) to can control the Spybot (same IR-Protocol as Bionicla-Mana, RC-Train and "Nitro-Flash")

Unfortunately there is very less information available for Spybots (like available Memory-Size for Commands, used uC, Serial Protocoll and used Commands [possibly sub-set of RCX])

So if you want to extend supported PBricks (Programmable-Brick) please feel free ...

By the way, the USB IR-Tower support IR for RCX & Co like also VLL

 

Jo

Edited by BrickTronic
Posted (edited)
9 hours ago, Wapata said:

how can I create a barcode dictionary with the ones I own, other than making a photo ?

 

14 hours ago, Bliss said:

The codes are described at the end of the ScoutSDK.pdf.
https://pbrick.info/index.html-p=184.html

All the codes are in the PDF but there are no barcodes, just the numbers to use in the VLL send Block...

I can make dropboxes too if really needed...

 

Barcodes for 8479 :

http://bbkockaklub.hu/kepek/1085/code_pilot_lego_8479_barcodes.pdf

I also read that there was once, free to download, a LEGO Code Pilot Barcode-Generating Program (item cdplt01)...
I don't know if this software is still available somewhere... 

Edited by Bliss
Posted
2 hours ago, BrickTronic said:

The Spybot uses not IR-Puls like RCX but a RS232--to-(visual)-Light Interface.

That's interesting, but it seems more than just a led and a resistor.

I do add support for some protocols as long as it does not need too much electronic parts and skills...

Already made popular boards like FTDI and Arduino, are ok according to me, but still, not everybody have them or are willing to go there...

In other words, it must be as easy as possible for most people.

To send VLL signals with modern computer, someone just needs a USB/RS232 Adapter, a resistor and a LED as a minimum... 
But still has to wire all this together somehow.  I got myself a DB9 adpter to Screw terminal for easy access to pins...

 

Posted

Little story : I have finally finished to make THE robot of CyberMaster and then try to play with it. You have to hit both shoulders then the front.. ... And it doesn't work. I've opened the brick, cleaned it, checked with blockly and it was fine ! Yeah ! But it still doesn't work in game ... :pir-cry_sad:

So blockly is a great debugging tool, I'm sure everything should work. I will install CyberMaster in English to test, then make a blockly program to emulate the game (but the Lego game have a lot of sounds and voices..)

Thanks again for Blockly ! :steve:

Posted

@Bliss

I did a few time measurements, just with an Arduino and output (0) connected to input (6).

Output 0 is configured as 50% duty cycle pulser (as you have shown using non-blocking timers further above):

640x485.jpg

I simply let this program run for 60s and used the Windows timer to measure the number of cycles as function of frequency = 1/(T1+T2).

Then I used a "sampling" routine like this:

640x490.jpg

The #cycles/60s as shown in the count block are tabulated in the table below:

  • First data entry (column 3) in the table below: All (serial) output commands removed.
  • Second entry (column 4): With the serial outputs.
  • Third entry (column 5): With serial outputs and input sampling (as said: out_0 is connected to in_6 on the Arduino.

400x165.jpg  

What I infer from this table is that I believe running the USB connection to the Arduino as high as possible is beneficial, isn't it? 19200 is comparably low, and can be increased significantly. I also believe that doing the counting for IntA on the Arduino, and then just poll the data would be beneficial as well?

Most 4.5V LEGO Technic models rely on as good as possible counting (rotation sensor = disc + light change sensor) or catching a press on a touch sensor.

And finally: It may be very well, that I used stupid LBlockly programs to arrive at these conclusions!!!

All the best
Thorsten

 

Posted (edited)

@Toastie,

Thanks for testing this.

In the latest version, I increased the baud rate to 115200 baud and we'll see if it is still reliable...  It should, even with the use of an HC-05 FTDI...
I also updated the arduino sketch on my github.

We still have the Blockly internal speed that might affect the Input counting...
Maybe you can run your test again and see if this is improving.  And if it is necessary after that, I could try to implement an input counter on the arduino...

I wonder if the Analog Input are internaly fast enough on the arduino itself.
I wonder if your test would be different if we would use Dig Input for the Int.A inputs...

I'm not sure I understand your test fully...  Specially when you talk about No serial outputs? (Blockly only use serial...)

Edited by Bliss

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...