Powered Up motors: L vs. XL

[Andman]

6 hours ago, nerdsforprez said:

This may one benefit for the use of XL over L for the above reason.  Not due to power per se but rather braking.  I have built and experimented with many crawlers to find that the benefit of an XL over a L is in its resistance.  Even if this resistance is only slightly greater than a L motor, it can save a lot of crashes.

Do you mean the C+ XL and L. If yes, i made exactly the opposite observation. The C+ L motor has more resistance when you try to turn it manually. So for rock crawling the C+ L motor would be a better fit since it stop faster than the C+ XL.

BTW, which word describes the behavior of a motor when you turn off the power supply and it still turns for some time? Is it also "to overshoot"?

[nerdsforprez]

11 minutes ago, Andman said:

Do you mean the C+ XL and L. If yes, i made exactly the opposite observation. The C+ L motor has more resistance when you try to turn it manually. So for rock crawling the C+ L motor would be a better fit since it stop faster than the C+ XL.

BTW, which word describes the behavior of a motor when you turn off the power supply and it still turns for some time? Is it also "to overshoot"?

no.  I already answered this.  I was referring to PF motors. I do not know about PU.  

[FoxOne]

44 minutes ago, Andman said:

BTW, which word describes the behavior of a motor when you turn off the power supply and it still turns for some time? Is it also "to overshoot"?

I would call it "inertia", because "overshooting" is more specific and implies missing some predefined target end state.

Elaborating on this, I can think of 4 possible factors:

1. Moment of inertia, considering "a load"
2. Same, but regarding massive / oversize rotor
3. Gearing ratio
4. Braking method (there are 3 at least for DC motors)

My observations on inertia movement of PU L vs XL are the same as yours, and I attribute it to #3  -- L motor is more geared down.

But I'm not sure if it's applicable to the case of downhill braking, if we choose to apply active, "electric" braking; would be grateful for explanation.

Edited December 30, 2021 by FoxOne

[Zerobricks]

XL motor also has a flat motor with a larger rotor which contributes to the higher intertia.

[gyenesvi]

1 hour ago, FoxOne said:

DC motors RPMs are controlled by voltage changing (or PWM signal, but that's the same effect).

I'm not an expert at the physics background of it, but as far as I understand that's only true for PF, but not any more for PU! The key is the position encoder in the PU motors. In the PU protocol, the motors can be run in PWM or SPEED mode (along with SERVO mode). In PWM mode it is as you write, speed and torque is proportional to voltage. But in SPEED mode, you can specify the target speed and the target power at the same time independently of each other. So it can run using high power but low speed, because the speed is regulated through the position encoder by the motor controller electronics (at least that's how I imagine). I tried it with PU models, they can climb firmly at a really slow speed (you can try it with stock models, like the Zetros). It's very useful, and the wheels are also less prone to slip.

The same advantage is true for SERVO mode when steering, where you can specify a target angle, and speed and power to get there. So it is able to turn small angles with high torque. That was not true for the PF servo, because the angle is controlled by the PWM signal so low angles resulted in low torque and it could not steer precisely on rough terrain if the model was heavy. But with PU L motor, I never had a problem steering on rocks even large wheels with a heavy (2 kg) model.

I think these aspects of the PU system are not well known and appreciated by PF fans who are reluctant to switch to PU. They expected that PU motors would be more powerful than PF, but in fact Powered Up is about more control, not more power.

[Zerobricks]

2 minutes ago, gyenesvi said:

I'm not an expert at the physics background of it, but as far as I understand that's only true for PF, but not any more for PU! The key is the position encoder in the PU motors. In the PU protocol, the motors can be run in PWM or SPEED mode (along with SERVO mode). In PWM mode it is as you write, speed and torque is proportional to voltage. But in SPEED mode, you can specify the target speed and the target power at the same time independently of each other. So it can run using high power but low speed, because the speed is regulated through the position encoder by the motor controller electronics (at least that's how I imagine). I tried it with PU models, they can climb firmly at a really slow speed (you can try it with stock models, like the Zetros). It's very useful, and the wheels are also less prone to slip.

The same advantage is true for SERVO mode when steering, where you can specify a target angle, and speed and power to get there. So it is able to turn small angles with high torque. That was not true for the PF servo, because the angle is controlled by the PWM signal so low angles resulted in low torque and it could not steer precisely on rough terrain if the model was heavy. But with PU L motor, I never had a problem steering on rocks even large wheels with a heavy (2 kg) model.

I think these aspects of the PU system are not well known and appreciated by PF fans who are reluctant to switch to PU. They expected that PU motors would be more powerful than PF, but in fact Powered Up is about more control, not more power.

The SPEED or SERVO modes are controlled by the hub, not by the motor. Motor only reports the position back. And for all modes you need to use PWM.

[J159753]

So, unconstrained by market realities, what would be some sets / use-cases that actually released the potential of PU? I'm still stuck in PF world myself, but I get the impression of an enormously complicated/capable (delete according to your worldview) system that just isn't being served by its controller software (& documentation) or official sets.

[Toastie]

Phew - a lot of things are discussed here - but these need to be sorted out, as far as I am concerned. I build/love trains (and switch points ;)) - and electronics to make them go around or simply work - so forgive me if I sound stupid. You guys are making things that I cannot comprehend.

OK. Now. PF: No motor "control" at all. You supply voltage (with electronics that can sustain that voltage under load) - and the thing does what you want. Under load: Amperage may (will) get to a point, where a) the controlling device (the PF receiver) cannot cope with the current flowing and thus the voltage goes down, or you have gearing installed that simply saves the receiver to get to that point.

In the train world that is 1, 2 or even more PF XL motors. Or any other variety of motors geared down to the point that the trains just crawl. PF train motors can't be geared - so just add them up to your needs.

Break on any motor - regardless of make - simply means: Shorten the wires. Induction is at work here.

Float on any motor - regardless of make - simply means: Leave the wires at high resistance or better: Open. Not connected at all.

And this is it for PF. No "hold".

PUp: All of the above + hold: That a) demands you to use a "tacho motor" = >non< PF, but PUp L or XL or some others ... motors. They need to have the rotation feedback supplied to the driving source = PUp hub. b) You need to use the speed and NOT power settings on a PUp hub to get that going.

And behold: The latter is - amazing. For trains, at least: Hold (or SetSpeed, same thing) means you set the speed you want, not the power. The power (= motor voltage, if the hub can provide that under the current load) supplied to the motor, is controlled by a pretty nifty algorithm running on the hub. 

I believe this is all there is. But I may be wrong.

Best
Thorsten

 

Edited December 31, 2021 by Toastie

[gyenesvi]

8 minutes ago, Zerobricks said:

The SPEED or SERVO modes are controlled by the hub, not by the motor. Motor only reports the position back. And for all modes you need to use PWM.

Yes, that's what I meant by motor controller electronics, that's in the hub, and makes use of the position data coming back from the motor. But great that you chimed in, as you probably understand the details better. So am I correct that the PU motors can in SPEED and SERVO mode move with slow speed / small angles and with high torque because of this control loop?

[Toastie]

8 minutes ago, J159753 said:

use-cases that actually released the potential of PU

As said above (maybe merged), for me, it is (and it makes >all< the difference) that PUp hubs can control the >speed< (= axle rotations/per time) by monitoring that number (speed) and then swiftly adjusting power to the motor(s) to attain that speed you want. You can set max power to be delivered, and many other things (e.g. how the motor(s) ramp up to controlled speed).

Best,
Thorsten

[Zerobricks]

1 minute ago, gyenesvi said:

Yes, that's what I meant by motor controller electronics, that's in the hub, and makes use of the position data coming back from the motor. But great that you chimed in, as you probably understand the details better. So am I correct that the PU motors can in SPEED and SERVO mode move with slow speed / small angles and with high torque because of this control loop?

They can do basically anything you program them to do. That is why there are so many paramerters available in BuWizz app for center steering for example. Another example if you set constant SPEED mode, the controller will adjust PWM to hold that speed regardless of the load.

[Toastie]

2 minutes ago, gyenesvi said:

So am I correct that the PU motors can in SPEED and SERVO mode move with slow speed / small angles and with high torque because of this control loop

I don't know about BuWizz (as I have none, but I believe so) - but all the LEGO hubs do exactly that, when you select "speed", but not "power" in the controlling program (I am using Legoino/ESP32, but I tried it with the PoweredUp app and it works).

Best
Thorsten

 

1 minute ago, Zerobricks said:

regardless of the load.

... when the supplied (sustained) voltage/the electronics can cope with the load, correct?

Best
Thorsten

[Zerobricks]

5 minutes ago, Toastie said:

I don't know about BuWizz (as I have none, but I believe so) - but all the LEGO hubs do exactly that, when you select "speed", but not "power" in the controlling program (I am using Legoino/ESP32, but I tried it with the PoweredUp app and it works).

Best
Thorsten

 

... when the supplied (sustained) voltage/the electronics can cope with the load, correct?

Best
Thorsten

Yes, Lego hubs allow power, speed and angle regulation. We are planning to add speed regulation in the BuWizz app too, would be useful for models where constant speed is required.

Yes, the motor can regulate speed only up to it's maximum power, anything more and well... It can't do more than full power.

Edited December 31, 2021 by Zerobricks

[Toastie]

3 minutes ago, Zerobricks said:

It can't do more than full power.

Then I understood all that, I believe.

4 minutes ago, Zerobricks said:

would be useful for models where constant speed is required.

Oh yes. I don't know about all the wonderful Technic models; you guys want to challenge and wantc to cope with these challenges.

When it comes to trains though, you want speed setting. And also acceleration and deceleration profiles. I have no clue, why TLG put that feature into every hub's firmware - but it is there. TLG's train theme is basically dead - but when you equip your train with tacho PUp motors, it makes all the difference. Not at high speed - but when slowly approaching a station or climbing a slope with some 10++ carriages.

Best
Thorsten

 

[FoxOne]

33 minutes ago, gyenesvi said:

But in SPEED mode, you can specify the target speed and the target power at the same time independently of each other. 

Full disclosure -- I'm not quite familiar with all the intricacies of PU protocol.

But this case of controlling speed and power seems suspicious. I suppose these are some kind of specially defined metrics, or there must be some kind of underlying constraints.

Deep down inside there's still a DC motor. Yes you can do some tricks with a clever control signal and a feedback -- good point, I get it. But you can't beat the physics, for sure -- and for DC motor there is a torque-speed curve (and it's a linear function). See, we even haven't touched upon a [mechanical?] power, completely different function.

 

 

 

[Toastie]

3 minutes ago, FoxOne said:

and for DC motor there is a torque-speed curve (and it's a linear function)

With PID control, you can at least challenge that function.

Best
Thorsten

OK, lame - but here I programmed RCX bricks (10+ years ago) to do exactly that:

https://www.eurobricks.com/forum/index.php?/forums/topic/45440-lego-train-control-using-rcx10-pbricks/

Edited December 31, 2021 by Toastie

[FoxOne]

2 minutes ago, Toastie said:

With PID control, you can at least challenge that function.

I suppose you can go *under* that curve, for sure -- supplying less of torque and / or speed available.
But if you are to go *above* it, you should somehow override power constraints.

Please correct me if I miss something.

[Toastie]

1 minute ago, FoxOne said:

Please correct me if I miss something.

Nope, you did not miss anything!!! . As @Zerobricks said:

22 minutes ago, Zerobricks said:

It can't do more than full power.

Best,
Thorsten

[gyenesvi]

45 minutes ago, J159753 said:

what would be some sets / use-cases that actually released the potential of PU?

That's an interesting question. In a sense, these features are present in official sets, it's just rarely advertised and reviews don't touch on these details; they measure things like max speed and climbing angle, turning radius, but rarely check how precisely it steers or climbs slowly on rocks (as they are meant for indoor use). And also to show the benefits, you'd have to compare them to PF electronics.

I think a nice use case could be a trial competition where all these details could matter. It would be nice to see the same build with PU and PF electronics and how they fare agains each other.

11 minutes ago, FoxOne said:

But this case of controlling speed and power seems suspicious.

I think I get what you mean, I had the same feeling. But from the answers above I think it's getting more clear; they trick is that you don't set the actual power (and speed at the same time), but the max power that the controller is allowed to use to regulate the speed. So it CAN use high power to move with slow speed if the load is high, and if not, it uses less power; it does not always use high power to move slowly, only if necessary. I hope that describes it more accurately. Is that what you mean by going under the curve?

[Toastie]

3 minutes ago, gyenesvi said:

I hope that describes it more accurately. Is that what you mean by going under the curve?

You described it absolutely to the point.

Best
Thorsten

[FoxOne]

10 minutes ago, Toastie said:

With PID control, you can at least challenge that function.

Sorry to bother, but why you stress PID in this case? As I understand, PID is a method for "smooth" and "proportional" output in control systems (yes it's a simplification).
But we're talking on a level below, DC motor physics. So, you can manipulate voltage (incl. PWM and other signals) and can constrain available current. I believe these are only controls available.

PID, on the other hand, operates above this and adjusts the control signal.
Are we on the same page here?

[Toastie]

Yes we are - I guess.

PID - as you know - reads a signal, which is linearly monitoring the control signal, e.g. rotations/sec of an axle for the variable "speed". The algorithm tries to minimize deviations from the user defined "set point" = desired "speed". It does that by adjusting "power" within the hardware limits. PID is just an algorithm. You can do with PI, even with P. I just believe that when the average parameters are known, PID is the most efficient way to achieve "hold" (speed). And it is software. Of course, to work correctly, you have to define the P/I/D parameters very carefully, depending on the whole "system" (response rate, moment of inertia, available power, and so on). But I found that with some average parameters you get quite far.

In summary: I don't know what the feedback algorithm in the LEGO hubs is, but is seems to work quite nicely (at least for my trains, operated with PUp L motors using the SetSpeed command of the LWP3.0 protocol.

Best,
Thorsten   

Edited December 31, 2021 by Toastie

[FoxOne]

8 minutes ago, gyenesvi said:

I hope that describes it more accurately. Is that what you mean by going under the curve?

Yes and no, thanks.
We share the understanding of max available power and "going under curve".

But I can't be sure what means "setting power". As I've mentioned above, I understand manipulating voltage / signal, and maybe constraining current.
As for power, I'm not sure. At a glance, seems like a simple term to grasp for users, but need to understand the underlying method.

[Toastie]

6 minutes ago, FoxOne said:

I understand manipulating voltage / signal, and maybe constraining current.

Current is constrained by the PUp hardware - if it can't deliver, it simply maxes out. To the point that it shuts down for some time (fractions of seconds, up-to seconds)

Best
Thorsten

[FoxOne]

3 minutes ago, Toastie said:

Current is constrained by the PUp hardware - if it can't deliver, it simply maxes out. To the point that it shuts down for some time (fractions of seconds, up-to seconds)

Current cutoff, exactly.
But how "power setting" control is implemented?