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:

1. Passing some processed value from a sensor directly to a command that writes the value to display - works. 
2. Passing the same processed value to a motor block as speed value - doesn't, fails silently.
3. 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.

I was able to reproduce this bug. I also had additional motors plugged in and I was surprised to see that the motor on port C moved instead of the motor on Port A. So I think what is happening here is that the motor block is using the port from the sensor block (3 = C) for some reason (since the sensor block is "in" the motor block, so to speak). But the workaround you came up with to move the sensor reporter block outside of the motor block does indeed fix it.

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 used the same program as in your blog post with motor on port A and color sensor on port 3. But also with additional motors on ports C and D. Same firmware and EV3 Classroom version.

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.

 

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.

Could there be an issue with what type of variable you are trying to use as motor power?

In Python the variable you use as motor power has to be of the variable type INT otherwise you get an error message.

Maybe the Classroom app is changing the variable type to FLOAT, when doing math operations and then changing it back to INT when saving the result in a variable?

Isn't there a console window with error messages?

Cheers Carsten

The classroom-project is converted into python before loading, so you could check there what happens.
Simply wrong, sorry !

Edited December 14, 20204 yr by Lok24

There is no Python involved in EV3 Classroom.

13 minutes ago, Lok24 said:

The classroom-project is converted into python before loading, so you could check there what happens.

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...

20 minutes ago, Munchkin255 said:

Could there be an issue with what type of variable you are trying to use as motor power?

In Python the variable you use as motor power has to be of the variable type INT otherwise you get an error message.

Maybe the Classroom app is changing the variable type to FLOAT, when doing math operations and then changing it back to INT when saving the result in a variable?

Isn't there a console window with error messages?

Cheers Carsten

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.

 

Ah, sorry, I mixed that up.

So Classroom is only for the EV3?

 

Edited December 14, 20204 yr by Lok24

4 minutes ago, Lok24 said:

Ah, sorry, I mixed that up.

So Classroom is only for the EV3?

 

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

 

13 minutes ago, biasedlogic said:

Isn't there a console window with error messages?

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...

Edited December 14, 20204 yr by biasedlogic
Suggest cross check with Spike software

I made this program in Scratch for Spike Prime, and it works as intended. The motor is stopped when there is no reflected light and moves at full speed, when the light sensor is measuring against a white piece of paper.

The value of reflected light is meassured in percent, with a range from 0 til 100.
In order to do some math and to provoke a non-integer value for the power setting I use a muliply by 1.2 math block.
There isn't any start motor at power block, instead power is set before staring the motor.

Cheers

Carsten

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