biasedlogic

I believe I've sent it to you via email already?

Yes, you are. I'm sorry for your frustration, but learning programming is a steep curve and while coding environments come with better or worse documentation (LEGO's nonexistent), no documentation replaces a programming course. LEGO does provide a complete curriculum for various levels and systems in their educational series - WeDo, Spike Prime, EV3. There you get all the basics taught, I believe. Did anyone actually sold you a product with this promise? The LEGO sets your bricks originally came with, come with dedicated applications for controlling their functions. The ability to program these bricks beyond their original set-bound purpose is a boon for users who have an idea what to do with these. I understand it takes a bit of tinkering to figure all blocks out, especially differences between speed-control and power-control blocks, but getting a simple motor to spin and a robot to react to something in its way wasn't a challenge for my 5yo, given, she cut her teeth on WeDo and it's curriculum of robot basics... I think you need to adjust your expectations about learning curve of tools you take a swing at. Even the easiest programming languages take more than just looking at the menu to get the hang of.

Not possible. This must have happened due to intermittent bad contact on id pin. If you want this mode you have to modify the motor by soldering in a small resistor. It will then stop being identified as train motor and instead will be recognized as simple (WeDo-style) motor. You will lose the gradual speed control and gain the bang-bang type of operation. From the app level there's no difference in operation

That sounds good! Happy New Year to you too!

I have compiled a short article on fixing LEGO switches that don't want to switch over to siding, and on possible replacement for the switch spring if this turns out to be the culprit. Full story here: https://www.biasedlogic.com/index.php/fixing-lego-railroad-switches/ Hope you will find it useful. Happy 2021, M.

Glad to hear that you managed to get it running! The heating up of the driver is not surprising - you are losing likely 20-60% of power there, depending on operating point (remember: it's a dinosaur...). What I can't see from the photos is where did you lift the ground reference from? In the photo there are only the two PWM signals visible. Or is the Hub powered from a common battery (+step down) with the motors?

Check if all your axles are straight. Even slightly bent axle at wrong place can be s headache. Had this issue in 8880.

Ad.1: The datasheet current revision has "Jenuary 2000" (yes, there's typo there) on front page, which would date the design at 20 years old, but don't be fooled! The hand-drawn reference PCB layout is a strong indication the truth is deeper yet! The chip has been around since at least 1988, it was actually designed and made by SGS Thomson (1998 renamed to ST), the first public preliminary datasheet was dated September 1988. The design of the chip is older still, the sister chip L297 (stepper driver with 4 channels) was designed around or before 1987... As about what to use instead - it's hard to recommend something, best look at what polulu.com has on their website. The thing is, chips are plenty, but the packages are not breadboard friendly, so best select something that's available in single numbers on a breakout board. Ad. 2: Wires are an issue too, but these are easily replaced when using a custom PoweredUp plug (see https://www.biasedlogic.com/index.php/lego-powered-up-connector/). The problem is the socket in the hub itself. Ad. 3: Again, it's hard to give recommendations. LEGO is quite good at being consistent, i.e. the axles, the gears, the connectors, these all have a breaking point somewhere, and the power of LEGO motors chosen so as not to hit that breaking point. You have to be careful about interfacing LEGO geartrain to anything more powerful. I had some success with using a DFRobot motor https://www.dfrobot.com/product-1617.html but not with PoweredUp, but with Mindstorms EV3. With PoweredUp you are losing position/speed feedback with 3rd party motors, if you want that you have to go down the EV3 route (see https://www.biasedlogic.com/index.php/running-third-party-motor-with-your-mindstorms-ev3-nxt/). For a race car you, however, likely won't care about feedback (remember to code the motor as a simple motor in that case) I'd say the LEGO system is the kind of system you can't really improve on power-wise without changing a lot of elements and then it stops being fun. There's place for mods, but function-wise, not performance-wise. I use, for example, 3d printed O-ring wheels for robots to make movement more precise. Or there are 3d printed railway elements, like crossings, that are not available from LEGO directly. Or there are 3rd party sensors for EV3 that can expand the capabilities of robots. Or, as in the case of aforementioned motor, reducing backlash. best regards! M.

Well, I'd say this isn't the way to go. 1. You are replacing halfway modern motor driver with something ancient, dropping almost 4V at full chooch, leeching 70mA for itself when idle, and to boot slow to switch. If you want to upgrade, get some decent modern mosfet based motor driver and not a slow dinosaur. 2. The PoweredUp connectors are not good for currents noticeably higher than what the original driver delivers. I'd eyeball them at 500mA constant, 1A momentary, going by these being basically goldpin sockets with single-sided contact, single point of contact, contact force provided by the contact alone (no separate spring element). You ssure need to bypass these when increasing motor power. 3. While the internal gearing of the motors sure has some leeway in terms of torque overload, what it does not have is lubrication. You may do a short proof of concept run at high power, but you will be replacing expensive motors fast. If you are going for modding LEGO, give a thought to replacing the motors first. Can be done, needs some basic tooling and/or a 3D printer. If you are chopping up the bricks already, you may give this a thought as well. 4. If you want to boost the hub, better leave it as is, pick the motor PWM signals at the PoweredUp plug. Yes, they are at power levels there, but a simple voltage divider is all you will need. With a bit smarter circuit you could try detecting the free-wheeling state of the driver, but that will unlikely be necessary for performance applications. You can make own Powered-Up plugs or splice the wire to the motor. The power to the driver anyway has to be routed directly from the power battery, so you may leave the brick power at its original batteries, no motor means low battery drain from the brick. Good luck! M.

Thanks for testing it out, in Classroom the line with setting the speed gets ignored. If the line "start motor clockwise" is present, it will run at constant, full (?) speed, if it's absent, the motor will remain stationary

I don't know what the software for Spike Prime etc is called, but this thread is specifically about the EV3 Classroom software, which supports only the EV3 brick. It would, however, help of someone with Spike Prime could check if this bug is present there, if so then it's something in the basics of the language implementation and seeing the python code would help understand what happens Sadly, no. Debugging isn't something traditional enough for TLG to consider in their programming interface. 99% of issues fail silently, the other 1% crashes your system. We are talking traditions here, the fact we don't have to punch our programs on tape is progressive enough or do it seems...

Are you sure? We are not on SpikePrime or Mindstorms 51515 (Technic Large Hub based), the EV3 isn't internally a python machine. I don't see any way to show intermediate code to the user... This may very well be, but is unlikely, as trying to display the result of the math involved or even just the sensor value, displays it as integer, while decimal-point values get their fractional parts displayed. Also, the motor block takes fractional values when input directly (you can type in 25.5% and it will work as expected, even though I doubt if the resolution of speed setting is that fine) Even if this was the reason behind the issue, as the user has no control over typecasting it still is a bug.

No luck. I have medium motors on ports A and C, large motor on D, color sensor on 3, program from my post, none of the motors budge. Is your observation reproducible in your setup? Best regards M.

Then we definitely have a "funny", as NASA used to call these... I'll try again to reproduce your observation, this time using my tablet.

That's a very interesting observation! However, I could not reproduce it, neither on Windows nor on Android. I have Brick with FW. 1.10E and Windows Classroom 1.2.2. I had 4 motors connected to all ports and tried with reflected light sensor connected sequentially to each one of the input ports. I was using the "start motor at % speed" block in a continuous loop, feeding it the sensor readout as speed percentage either directly or via a nested math block. None of the motors cared to budge. What's your setup and can this be reliably reproduced on your system? Anyway this would be a strong indication, that something in the port ordering is FUBAR.