[PUp App] Bug, Limitation or Other?

[kbalage]

8 hours ago, Toastie said:

@kbalage, did your config make it persistently all the way through? Because when it did, it means the behavior @Hod Carrier and I were noticing, it is either our phones, or the L-motor, or the City hub. I believe it is worthwhile to follow up on this, right?

Definitely worthwhile to follow up, I didn't have the time yet to make longer tests to confirm your data. Family also deserves some attention on weekends, not just lego ;) Will try to run the tests this evening.

[Toastie]

Oh, absolutely!!! Family first is the common sense here among all "members" ;) - it is the most important thing and then - for long - there is nothing much else!

I did not mean to push you, please don't feel that way! There is zero need to rush things. I just wanted to make sure, that this remains on the radar, as it may very well be that >I< am screwing things up - would not be the first time, in contrast - when suspecting something is broken or faulty.

Thanks a lot for your reply!

Best wishes and have a very nice day.

Thorsten

[kbalage]

@Toastie no worries, I didn't feel being pushed :) 

So with my iPad Air 2, latest City hub firmware, PU app version 3.6.0 I have the following experience:

• The bug does appear with the City hub and the Large, Extra Large, Large Angular, Extra Large Angular motors, basically the ones with hardware encoder. The wait time is basically irrelevant, crash happens between 3 and 150 cycles randomly.
• The bug does not appear with the City hub and the Medium Linear motor that has software encoder only. I tested it with various wait times until 1000+ cycles.
• The bug does not appear with the Technic (4 port) hub with any of the motors.
• The code does not run the motors without encoder but that's the expected behavior.

So these are some pretty special circumstances to have the bug, but it does exist. I suggest to report it via LEGO Customer Service (an e-mail works), that is the official way. I will also try to forward it through my channels.

[Toastie]

@kbalage, thanks a million!

I am sure that @Hod Carrier is also "happy" that his code was not the cause of this behavior! It is exactly what he and I observed independently.

Well, I think this bug is not that "special": With the City hub, >none< of the motors work with the SetSpeed command: Either it is a linear or a train motor w/o tacho, then the code doesn't even run the motors (which is fine, as it should be like this) - or it crashes.

I also believe that the SetSpeed command is rather powerful ;) In many regards. Surely for trains, maybe for GBCs with critical timing, etc. etc. With a tacho equipped motor, I would not use the SetPower command at all, but rather set speed. But that is my taste only.

Best regards and thank you very, very much again!
Thorsten

P.S.: I believe your channels are much more efficient.

Edited June 6, 2021 by Toastie

[kbalage]

8 hours ago, Toastie said:

Well, I think this bug is not that "special": With the City hub, >none< of the motors work with the SetSpeed command: Either it is a linear or a train motor w/o tacho, then the code doesn't even run the motors (which is fine, as it should be like this) - or it crashes.

Actually the Medium linear motor works with the SetSpeed command and shows no sign of the bug with the City hub, so from the bug's perspective there's a difference between the motors that have hardware zero position (L, XL, L/XL Angular), and the one with software zero only (Medium Linear motor). 

This made me thinking, what about the Boost hub? The internal motors are similar to the Medium Linear motor as they have software zero only. I tested with the Boost hub and the bug does not appear with the internal motors or with the Medium linear motor attached, so this also confirms the difference between the motors with and without hardware zero.

Btw it's not strictly related to this bug, but I found another anomaly during testing - the Technic L/XL/angular motors are not working at all with the Boost hub unfortunately. 

[Lok24]

Hi all,

I can confirm with a Galaxy Tab.

But while in loop you can see the icons flickering, and that stops first,  motor is running, but connection ist lost app 20 sec later, motor stops

So app isn't running any more....?

 

[Toastie]

3 hours ago, Lok24 said:

But while in loop you can see the icons flickering, and that stops first,  motor is running, but connection ist lost app 20 sec later, motor stops

Yes, exactly.

Well, it could be that when the code crashes ("program irregularly terminates" with exit code "bad"), then there is some watchdog that realizes bad things happened (or a simple time-out) and simply shuts off the BLE connection.

Best
Thorsten

[Toastie]

On 6/7/2021 at 9:06 AM, kbalage said:

Actually the Medium linear motor works with the SetSpeed command and shows no sign of the bug with the City hub, so from the bug's perspective there's a difference between the motors that have hardware zero position (L, XL, L/XL Angular), and the one with software zero only (Medium Linear motor). 

Just "talked" to @Hod Carrier in private:

I believe that we need to include the PUp train motor here as well. Because this is what he is using in his setup - I believe I have one PUp train motor somewhere without cut PUp connector and if, will test.

Also, @Lok24 may have used a PUp train motor in his tests as well, is this correct?

That means that

• all hardware rotation sensor equipped PUp motors hooked up to the City hub do crash a program using the SetSpeed command repeatedly,
• the train motor hooked up to the City hub does that as well,
• the train motor does not crash the program; it does not do anything; the loop runs forever
• the linear PUp motor does not,
• the internal Boost motors do not.

Is that summing it up correctly? Because devs need to know as many details as possible (as far as I can tell from troubleshooting a modern mass spec ;))

A question I have: What is a "software" tacho/rotation sensor? Does it assume 0 = stop and full speed = 100? (or whatever scaling factor is used?). Such a thing is not built into the motor, right? It is a piece of software in the hub, correct? If so: Why does the train motor crash the program? That one is for sure dumb as brick. But when Hub software is doing the work, then I don't get, why there is a difference in behavior between the PUp linear motor and the PUp train motor.

Oh well - the world is becoming increasingly complex , beer always helps. 

Best
Thorsten

 

Edited June 8, 2021 by Toastie

[Toastie]

@Hod Carrier, @Lok24, @kbalage,

sorry for bringing this up again: I have hooked up a PUp train motor to the City hub and updated the info in the bulleted list above:

The train motor does not crash the program upon using SetSpeed: It does not react, but the program loops forever; replacing it with the SetPower command on the fly works as expected; using both commands in the same code loop works as well - it appears as if the SetSpeed command is simply not executed; SetPower is.

Best
Thorsten

[kbalage]

@Toastie that's the expected behavior of the train motor, since that one does not have an encoder either.

About your question regarding the hardware/software zero position - all the tacho motors have a sensor that measures rotation in degrees. The logical zero position will be always the "power on" position, that is used as a zero initially, but that can be updated in the app. The L/XL/Angular motors have a physical 0 position additionally, so the motor can measure the actual position relative to that physical zero mark. 

[Toastie]

@kbalage,

ahh - it all begins to make sense:

1. PUp motors without HW rotation encoding: No problem; they do (correctly) not respond to the SetSpeed command, but (correctly) to the SetPower command
   These are: The linear motor (45303), the train motor (88011) - is that it? I am asking, because all other motors, including those in the MoveHub, are described on the LEGO website as "precise position motors"
2. PUp motors with HW rotation encoding (all others): Problem with SetPower command on City hub.
3. Move hub (is that boost?): Internal motors = working with SetPower, external motors as in 1) + 2)?
4. Technic hub: No problems at all.

Is this summing it up correctly?

Best
Thorsten 

[kbalage]

@Toastie almost :) There's the Medium Linear Motor (88008) that you missed, it has no hardware encoder so it falls in the same category as the internal motors of the Move hub (not affected by the bug).

And the problem is with the TachoMotorSpeed block, the MotorPower block works well with all hubs and motors.

[Lok24]

2 minutes ago, kbalage said:

@Toastie almost :) There's the Medium Linear Motor (88008) that you missed, it has no hardware encoder

 

How doest it work whithout encoder?

[kbalage]

2 minutes ago, Lok24 said:

How doest it work whithout encoder?

Sorry, I phrased it incorrectly. It has an encoder but no physical zero position, it is similar to the internal motors of the Move Hub. The motor will only provide a logical zero position to the hub.

[Lok24]

I see. Threre are three types of motors  I think

- Nothing  (simple, train)

- tacho (Move hub, 88008, technic L / XL)

-tacho and zero (the angulars)

 

Edited June 8, 2021 by Lok24

[Toastie]

5 minutes ago, Lok24 said:

- No encoder (simple 45303, train 88011)

- Hardware encoder but NO HW zero (Move hub, 88008)

- Hardware encoder and HW zero (L, XL, the angulars) 

 

@Lok24 I edited your list. @kbalage Is this what it is?

I still don't understand what a "software encoder" is. This means there is no rotation measurement hardware within the motor, or is there? If there was, I begin to understand ;)

[Lok24]

13 minutes ago, Toastie said:

@Lok24 I edited your list. @kbalage Is this what it is?

 

No.

the technic L/XL are identical to the 88008

Onle ythe angulars have Zero.

13 minutes ago, Toastie said:

@Lok24 I edited your list. @kbalage Is this what it is?

I still don't understand what a "software encoder" is. This means there is no rotation measurement hardware within the motor, or is there? If there was, I begin to understand ;)

There is no "Software Encoder".
To get information about rotation and Speed rotation you would not need HW at all , but for getting the angulars you need.

PS: here's a picture of the XL:

https://bricks.stackexchange.com/questions/15031/what-is-inside-the-technic-powered-up-xl-motor

Edited June 8, 2021 by Lok24

[Toastie]

4 hours ago, kbalage said:

The L/XL/Angular motors have a physical 0 position additionally, so the motor can measure the actual position relative to that physical zero mark.

 

6 minutes ago, Lok24 said:

Onle ythe angulars have Zero.

And now what?

[kbalage]

7 minutes ago, Toastie said:

@Lok24 I edited your list. @kbalage Is this what it is?

I still don't understand what a "software encoder" is. This means there is no rotation measurement hardware within the motor, or is there? If there was, I begin to understand ;)

Yes this list is correct. 

2 minutes ago, Lok24 said:

No.

the technic L/XL are identical to the 88008

Nope, they are not identical. See details below.

First of all about the wording, sorry if I used mixed / incorrect terms, that happens if there's no official description or guideline. These are the different categories, the terms below were used by one of the Powered Up hardware team members:

• "simple" motors have one mode: Power control - (simple 45303, train 88011)
•  "tacho" motors have 3 modes: Power, Speed, Relative Position (Relative position "zero" is wherever it is from turn on/reset, and it endless in degrees ) - (Move hub internal motors, 88008)
• "smart" motors have 4 modes: Power, Speed, Relative Position, Absolute Position (Absolute position has a mechanic zero, and range of + 179/-180 degs) - (Technic L/XL, Angular L/XL)

In the Powered Up app we don't have access to the Absolute Position at the moment. Only the Angular motors have a marking of the physical zero position on them.

[Toastie]

9 minutes ago, Lok24 said:

PS: here's a picture of the XL:

Yeah, I posted it here as well some time ago. It also shows the way they encode the rotation data.

 

[Lok24]

7 minutes ago, kbalage said:

In the Powered Up app we don't have access to the Absolute Position at the moment. Only the Angular motors have a marking of the physical zero position on them.

Ok, that makes it clear and I was wrong, sorry for any confusion.
I didn't find the information for the technic and absolute zero... 
 

[Toastie]

20 minutes ago, Lok24 said:

sorry for any confusion.

Oh man, don't feel sorry!

The whole PUp thing - without any real technical documentation at hand - is so confusing to me, that the level of my confusion was completely unaffected by your comment! In contrast, your comment cleared-up things rather quickly. To overcome chaos, one simply needs bold actions. And then watch the outcome. "Yes" and "No" are usually good bold actions, regardless of being true or false. 

And it worked again!

So thank you and all here for clearing this mess up in a swift and to the point approach!

All the best, have a nice day
Thorsten

[Hod Carrier]

I finally got a reply out of LEGO in response to the issue. After a year of waiting the answer I got was short and succinct. Basically the Large Technic Motor (PN:88013) is only compatible with the Control+ app and not the Powered Up app, or so they say.

So I went and downloaded the Control+ app to see what's what, but it appears that it only comes pre-loaded with control profiles for existing large Technic sets and doesn't have any facility for creating your own custom profiles. Brilliant!!

When morning comes around I shall be sending LEGO a long and distressing missive asking them just what the heck they were thinking releasing a line of products branded as Powered Up that are not fully compatible with the app; an app that, I shall be reminding them, includes programming blocks that take advantage of the tacho motor functions. I will want to drill down more into this issue and see what the truth of it is, because frankly it smells fishier than a Grimsby trawler.

More later...

[Gimmick]

5 hours ago, Hod Carrier said:

I finally got a reply out of LEGO in response to the issue. After a year of waiting the answer I got was short and succinct. Basically the Large Technic Motor (PN:88013) is only compatible with the Control+ app and not the Powered Up app, or so they say.

So I went and downloaded the Control+ app to see what's what, but it appears that it only comes pre-loaded with control profiles for existing large Technic sets and doesn't have any facility for creating your own custom profiles. Brilliant!!

When morning comes around I shall be sending LEGO a long and distressing missive asking them just what the heck they were thinking releasing a line of products branded as Powered Up that are not fully compatible with the app; an app that, I shall be reminding them, includes programming blocks that take advantage of the tacho motor functions. I will want to drill down more into this issue and see what the truth of it is, because frankly it smells fishier than a Grimsby trawler.

More later...

The Krokodil train set uses a 88013 with PoweredUp App ;)

I don't know if they use power or speed settings, but it has to be compatible. Or "is not compatible" is a strange phrase for admitting the bug ;).

Have you tried to set the power level right before re-asigning the speed? Sometimes things like that help to clean things up.

[kbalage]

6 hours ago, Hod Carrier said:

I finally got a reply out of LEGO in response to the issue. After a year of waiting the answer I got was short and succinct. Basically the Large Technic Motor (PN:88013) is only compatible with the Control+ app and not the Powered Up app, or so they say.

That's complete BS. Unfortunately LEGO Customer Service has very limited knowledge about Powered Up hardware and software, which is no surprise since they are not properly documented (not even for internal use). There are still several bugs in the PU app, some of them exists since the introduction of the system. You either live with them and try to find a workaround, or you can switch to a platform like Pybricks that has way more agile developers.