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.

I actually had the same idea after replying to your last post, I sent them emails through that form too (on the Powered Up issues as well as on the ev3 Classroom issue I described in separate thread). I'll keep you updated in case I hear back from them... ?

I sent three of them (before discovering the #3) to googleplayapps@lego.com ; the address provided in the PlayStore as developer contact. If there's a better way of reporting these I'd love to know.

Hi, playing with the all-new Classroom programming app I found some funny behavior. I have described it in detail here: https://www.biasedlogic.com/index.php/lego-classroom-for-ev3-bugs/ In short: Passing some processed value from a sensor directly to a command that writes the value to display - works. Passing the same processed value to a motor block as speed value - doesn't, fails silently. Saving the processed value to a variable first, which then in turn gets passed to the motor block as speed - works, so that's not an issue of bad value in itself. Anyone with similar observations? best regards, M.

Hi, I have found a few quirks with the Powered Up app, I consider these bugs. I have made a post about these on my microsite: https://www.biasedlogic.com/index.php/lego-poweredup-bugs/ In short summary: While LEGO advertises the Large Technic Motor (not only) as having an absolute position encoder there's no way of getting this position in the Powered Up App While all data ports in the Powered Up app support very large numbers without a hitch, you can't type in / read out anything beyond 9999.99. Annoying as position for motors can be only specified in degrees and 9999 degrees is less than 28 turns. Specifying negative relative distance for a motor to move makes it still move in positive direction (WTF?) Logic functions have only AND and OR, but not XOR or NOT, especially the missing negation is hard to understand. For some issues there are workarounds, I have described them on my site with pictures, I don't want to redo the work in the forum and pictures are worth 1000 words... Am I missing something or these are actual faults? best regards, M.

And I do think this is the key thing. Less gearing down means more internal motor torque. For the same power output means less motor speed (speed before gearing). Even at the same actual power available at shaft this should mean much longer life at full load. It's a bit like the thing with engines in cars vs. boats. I have in my car a 2.0L diesel providing 100kW power, but if you want a marine diesel at 100kW it will be a 6.0L unit - three times the size/displacement. The difference is while my car diesel can provide the same 100kW, trying to take it continuously will wreck the engine in no hours at all, while the marine diesel can put its 100kW Monday to Sunday round the clock.

Yes, thank you, i will have a closer look later today.

By the way, I just tested: Re-coding the powered-up train motor with 2.2kΩ resistor on ID1 line makes WeDo recognize it as own Medium Motor (was to be expected) and thus enables to control a train with a WeDo set. It remains compatible with the rest of the Powered Up family, but the handset remote will control it in bang-bang mode instead of fine power increments - still, you can use the powered up app to control it as you wish. It's all pretty much stating the obvious things from the documentation, I just tested that it works in reality.

I bet it is protected in some way, but you can't just 'patent a connector'. If we talk patent, we talk some novel property or solution. The plug of LEGO PUP isn't novel in the technical solution - it's just a modular crimped connector in a bit unusual shape, but the shape itself also does not solve any old problem in a novel way. You don't get through the European patent office with something like that easily. What is easier, is to protect a pattern, like you protect a logo or a trade name. But this has to be recognizable pattern for your company and does not necessarily refer to the technicalities. Getting around a patent for a crimped connector is not so much of a problem - see my design, it's not crimped and the technical solution to obtain the necessary form is vastly different from LEGO's Getting around a protected pattern is a bit harder thing, because it depends on what is exactly protected. It may be as easy as making the back of the plug round, leading cable sideways out and making it all lime-green so it looks nothing like LEGO, or something entirely impossible, if the actual shape of the contacts is protected pattern... I don't have time now to poke around and find the relevant IP, but if someone has it on hand I'd love to have a look. greets! M.

What did you do to burn them What are the symptoms? How do you know they are 'burnt' and not, e.g. the gearbox has failed? What motors are we talking about? There are the Large and the Medium motors? Did you entertain the thought that if four motors failed at you you might be doing something wrong? Some info on the EV3 motor interface and using third-party motors is on my site: https://www.biasedlogic.com/index.php/running-third-party-motor-with-your-mindstorms-ev3-nxt/ Maybe for your use case a different brand of motor would be more appropriate. But you give us nothing to go on... Best regards, Marek

Hi gals and guys... I'm new around here and after reading this extremely interesting and useful thread I registered to add my own $0.02 to it. I have worked out a way to 3D print a very usable plug that fits the Powered Up connectors and can provide a way to connect Power Functions motor to a Powered Up hub (it will pretend to be either a WeDo motor or a train motor). I have posted an article about it on my microsite https://www.biasedlogic.com/index.php/lego-powered-up-connector/ This is how it looks like. I'm a bit cautious about releasing the design files on a publicly available site as I'm not sure if/what parts of the connector are somehow protected by TLG IP. Beyond that, to actually print them right you do need a very well tuned printer, which my experience on Thingverse indicates, seems as rare as hen teeth. Anyway, if someone is interested in this approach, comment or drop me a message. Best regards and thanks for this informative discussion!