Gunners TekZone

OK, I don't know why I never considered this before... But this thing (the three I have are the older LMS-ESP32-v1.0. Same, same) can already "control" an Interface-A and other components, as it has plenty of GPIO pins available. Just need a logic level converter or resistor dividers for the inputs. And I think 3.3v will trigger the Int-A outputs just fine. Hmm, controlling an Int-A from Technic HUBs!! OK, now I need to add that to my "Control Int-A via Sharp PC-G850" to-do list

Anton's Mindstorms offers these technic connection points on their electronic add-ons. Makes for a very easy way to integrate into LEGO designs. (Just look beyond the fact that there is no Int-A involved here )

@Mr Hobbles Very Nice! Nice to se a clean compact adapter that can do LOGO, Python, PF... I like the little touch of making the board physically interfaceable as well. Does the IR run separately? As in just IR, just the cable or both? In case one doesn't want to blast IR out to unrelated PF devices in the vicinity. If you want to sell off a couple of those 1st batch, let me know in DM (I is in Canaderpia). You don't even need to "fix" them 1st as I can handle a soldering iron (well depending on which end I grab first).

Wow, that is some crazy pricing there (and opportunistic at $29 CAD each from the seller with 11 of them)... I am glad I grabbed the three I did back in May. I believe I got them for about $6 CAD each, and while they are the only ones I have, they made my Interface-A's 4.5v "collection" complete.

YES, as is just manual. NO LEGO program (although some simple "ladder logic?" like LEGO Lines could be programmed in) and YES same one on LVL1.

Oh wow! Very nice!! Makes me want to build something similar to fit in my current MEGA with display sandwich (it is already three boards thick including MEGA and display), to add in the Blockly BT option, and a nicer Int-A connection with less dupont. As well as just for the fun of building it Alas... First I still need to find a way to merge the MEGA Touch Screen control and Blockly interface code together... And catch up with all the Blockly changes... But all that requires too much thinking So for now I just lurk BTW... I have noticed that both of my Interface-A's only output 3.7 - 3.8vdc (but it is stable even with motors running) regardless of type of AC or DC adapter connected to them. Can others measure their voltage outputs and let me know what they are? Thanks! I am wondering if I need to do some regulator upgrades in both of mine??

This LVL1 Website might have already been referenced somewhere deep in this "Control Interface-A with Everything" topic? But here it is again. And it is working very well. The touchscreen is a nice "touch" Alas, it is not "programmable"... But I think I might take a stab at modifying its sketch to "hopefully" allow this interface to still respond to touch and control the Int-A as it does, but also display and pass on the Inputs and Outputs generated by running code from @Bliss's Blockly development, in place of the NANO that I have already tested to successfully do that. And here is a short video link of it in action, that I will try to keep around as long as I have space in my Public Dropbox. https://www.dropbox.com/scl/fi/zdk8iptij91zfb25rz5ut/20260410_222147.mp4?rlkey=0whm0j6oniyrun05ws93u67wr&dl=1

Ha... Same question @evank asked when he saw a pic... Yes, the Interface-A only puts out 4.5v so the 9v motors run a bit slower. But as they are internally geared, they still run with more torque (and plenty fast enough) than the 4.5v motors with a bunch of LEGO gearing added. Oh, and as the wires for the 9v cables tend to rot, I learned how to make my own cables. I originally tried this, but was crazy slow, and still too weak.

Um... What? Can't there be a simple LOOP While COUNT INP (6) < (10) and/or LOOP Until COUNT INP (6) (=>) (10) block? (Stuff in brackets can be adjusted) That starts from 0 and internally counts up (via input state change)?

This is a video of Blockly via Arduino Nano, to LEGO DACTA Interface-A, to a little robot arm simulating a welding machine (Unfortunately the old white friction gears in the arm often damp down what was to be more dramatic movements). NOTE: This link will not stay valid forever https://www.dropbox.com/scl/fi/szpsacoz89awqiy3bo5v6/20260408_190056.mp4?rlkey=18l0c233zk9lkzyn54z2wcnh9&dl=1

I did Ctrl+Shift+R to refresh... And fooey, I should have listened to that little voice and saved first Anyhow, I had my screenshot to quickly fall back on what changes I had made... Only this time I didn't bother commenting and "cleaning" up unused code... I just broke the connection where I wanted to to end... Which apparently DOES NOT actually break the flow??? Wow... Note to self... Leaving "scraps" of blocks around might affect how the code runs. Anyhow, YES! that adjustment to the input value worked!... And apparently so does the rest of your code ... Albeit the count times are dramatically shorter than they should be. Oh, goody... There is still something to figure out Doubling the count brought it to the expected LL results. Granted, those old friction gears I need to use in the arms are so inaccurate that precision positioning is not possible. So, I am guessing you setup is counting either ON or OFF states, not the transition between states?

OK... This little startup process works, right up until the limit switch. Which IS showing about 4v on the Arduino A0 pin (and on A1, as it happened to land just right on the rotation sensor as well). EDIT: I figured out how to show the Input 6 value... Hmm, perhaps 888 isn't enough to trigger as ON? Odd values, as the switch I am now using is the original 4.5v one that is simple ON/OFF... With no option for any "pressure variance". Perhaps, since the Int-A inputs do not seem to offer much in "range", the Arduino should just use a GPIO and not an Analog pin? That might make any counting (if I can figure out that part) much more reliable as well.

No... I have a bad memory for using KB/mouse combo keys... I just click and drag This is what I mean. I need to see a bigger picture to figure out something in a flow... But with blocks, it gets too small as to be readable for me BUT finally I was able to "see" it... Oh my goodness, there is a Sub Routine at the end that makes the UpdateOutputs block work!! And here I was thinking this was just a progression of blocks going from top down and wrap back up to top right and down again, etc. (as in writing text in three columns). So every time I erased the last part, it messed up those blocks. And for some reason undo didn't bring that group of code back.

@Bliss ARGGG... OK, using your long version of my LL code, I just isolated the beginning routine (adjusted to work) showing how I set and moved my arm with one end stop input and one optical rotation input. And realised that the end stop wasn't stopping the code?!?! (I didn't notice on the robot as the motors simply stalled quietly) and thus never got to the counting part. However, as I was trying to arrange a screenshot (and getting rid of non-relevant blocks, to clear the screen and my mind)... It somehow it mixed up and/or erased (again) the relevant code that I had scrolled away from to get at the rest. And whatever Undo does is well, not what is expected (placed random blocks and comments in odd locations)... And only seems limited to one or two steps back? Bah! And the method of grabbing a group of blocks (no rubber banding?) still confounds me as to where to grab what to do what I expect. Again, Bah... I do NOT like block programming. Another coffee... And then I might try again with something even simpler from scratch, to determine if the sensors are working as I thought they were

Yes, Python part is totally free. The Block part starts at $7.50 CA / month or $79.00 CA for life (perpetual licence). I think I tested the block side once or twice when it was free... And hated it... And have since only ever used their Python side. OK, I am embarrassed to say that I didn't catch on about Blockly being a Google project Now some of @Toastie's comments/questions make more sense.. Doh! Carry on as you were Ah, JavaScript... Yes I learned me a bit of that in Node-Red... The only graphical programming style my mind seemed to be able to work around. Possibly due their more "free" range layouts joined by connecting "wires" conforms to electrical breadboarding? As opposed to Blocks "magnetic" snap (that always confounds me to get correct) and generally vertical progression.

I hear that!! My "philosophy" here is stick around to do a few confirmation tests and/or suggestions for clarity... To help @Bliss with this incredible achievement. But alas, I am not ready to use Block coding for actual projects. @Bliss On this note... And while it might be a little too late? I am not sure what language and format base you are using for Blockly, or if it is of your own design. But I would like to recommend following as close as possible the block coloring and function that PyBricks uses for their Block code. That way one can better switch between both LEGO programming types (as they simply don't focus on older stuff like the tethered and/or "dumb" Interfaces). But also so one can better assist in development by comparing what works on PyBricks, like counting loops, etc. ----------------------------------------------- Ah, but of course... I now see that their Block programming is behind a paywall... So hmmm... Oh well, it was just an idea

In LL all COUNT commands assume an absolute value starting from 0. I just assumed it can't count further than 255 Yes. Also, I believe it could go as fine as 1/10th of a second.

You are welcome! Re: POC... Yes, "This was a triumph I'm making a note here, 'Huge success' It's hard to overstate my satisfaction" - GlaDOS However, NO, the Blockly code you provided needed some positional modifications right out of the gate. I was working on a shorter one to screenshot what order worked, but got frustrated due things I have explained prior... I will try again today.

From my sophisticated tests using an optical sensor and a wheel turned by hand... Yes, the software appears to count at every change: EG, Starts ON to - OFF - ON - OFF = 3 There is no RESET as I think you think of it... At each COUNT command LL is just counting changes from 0 and comparing to what I have in my code. Once they match (or exceed I guess) it starts or completes a loop as coded. It will probably go up to 255 then loop to 0, being a program for 8- bit computers, but I have never checked as my wee robot arm simply doesn't move or rotate that much.

@Bliss It may have already been mentioned in the details prior... But a simple Loop While/Until Input ON/OFF and a Loop While/Until Input toggle/trigger count = X (with automatic preset to 0 ) should be sufficient for a LEGO Lines type process. Ah... Space... The often impossible frontier in my current universe I am already maxing out the displays and computers I can put into place. I have more in storage.

Need Bigger $$$ And rotating my Surface will make the use of KB and mouse a bit tricky. Yes, it has a touch screen, but again, not natural for me to use when programming. GUI use is another thing though. Thanks all for trying to help. But no worries, I am not abandoning this topic's... well... topic. Outside of doing some simpler testing routines etc., I am simply not going to actually use Blockly as others may.

Now why didn't I think of that... ... Hah. JK. Actually, my brain don't track well doing that. I need to see large chunks of code (or in this case blocks) to follow the flow. And I find I can get more use out of text that way. This is also why I don't enjoy programming as much on my VIC-20's as much as the C64 or even better C128 in 80 column mode. But Block programming just eludes me in the "enjoyment beyond the basics" category. It is a me thing

@Bliss OK... I wired up my Arduino Nano to an Interface-A, and it works quite well with Blockly. I however, do not... OK, let me clarify. This is a ME issue. Always has been with Block programming. I have tried, trust me... I really like working with PyBricks, but MUST ignore their blocks and use Python, else I go bonkers (well, more than normal). As a bit of a visual learner, I can truly appreciate these Block style programming methods, and I do admit they are particularly fun to manipulate with a high resolution touch screen like my Surface Tablet has. However, I find even a slightly meaningful program quickly gets beyond the immediately visible screen real estate. And in order to see enough of the flow, I need to reduce the scale to a point that I simply can't easily read anything and all I see is the confusing patterns of colours @Toastie clearly has better eyesight and appreciation of blocks... Koodos there! But I already said earlier in this topic, blocks are not my choice of programming, but that I can at least do some simple testing... So this is that. Aside from whatever is going on with your counters?!?!?... The binary style UpdateOutputs works very well, and I was able to do some robot arm movements with timers and Loop until Input type logic. Very nice! Up until I clicked on the wrong things a few times while zoomed out and broke my own code (as shown in the pic below). Even a few UNDO's didn't get it back to where I had a short routine successfully running. Oh well Unfortunately, even if I manage to make something meaningful, I no longer keep a YT page and do not have a reasonable way to share video here. And most pictures are only "short term" due my use of limited free space on Dropbox. And no, I do not plan on using other online storage options.

Hmm, I think @evank may be the expert here, if he understands electronics... Or at very least from experience with using the two primary 4.5v sensors that were meant for the Int-A. But I understand the inputs to detect simple continuity of an active (powered) circuit. I don't think there is enough sophistication to determine rising or falling edges? The touch switches just go HIGH when a switch is closed. The optical sensor seems to react to the reflectivity of the built in IR (or an external light source). With the wheel it "counts" at every change between the black and white fans. Thus 8 counts per revolution on the quad fan pattern. Of course that programmatic "count" can also depend on where in the geartrain the sensor sits. And accuracy may be questionable with higher speed. In my Robot arm program, I just manually triggered a motor to run for as long as I needed and counted the "triggered pulses" I saw on the inputs. That became my COUNT value. The Int-A input accuracy may be questionable with higher speed, but this bottleneck will still be inside the Interface, and an Arduino (or other MCU) will not improve that, unless you start using them AS a form of "upgraded" Interface-A... But I suspect that will concern LEGO purists.

That said, unlike the more complex Interface-B... The Interface-A is a ticker tape flow of 8-bit data and commands, so perhaps a more LEGOlines style "programmable block" might be appropriate?