I believe I have found a FW bug in the implementation of the output subcommand 'GotoAbsolutePosition' for virtual ports (both commands 0x0D and 0x0E) when using immediate execution that happens to discard a previous command. The symptom is that the command starts executing and moves the motors past the desired position but never stops.
In line with that, when observing the output command feedbacks, starting from an 'idle' state, executing a first command moves the system into 'in-progress state'. Then a second immediate command discards the first, and leaves the system in 'in-progress' state, but afterwards a 'completed' feedback may never be received (neither a 'discarded', in fact, no feedback may be received afterwards). Another command sent in immediate mode can discard it, but then the next command never completes again. I was able to reproduce this behaviour by sending commands from my own custom bluetooth client and also via the Powered-Up app, which makes me believe that the error is not on my side.
The same command works well for non-virtual ports (single motor). The problem only seems to manifest itself when the command is sent in immediate mode and the previous command is still executing and is thus discarded. If I wait for the first command to finish and then send the next one, everything seems to be working fine (the second one also completes). Tested with Technic Hub with 4 ports, FW version 1.1, two technic XL motors (linear) on ports A+B.
The setup is as follows.
Create virtual port A+B (command 0x61)
For both ports A and B:
Set input format (command 0x41) to mode 3 (the same results with mode 2), delta=1, notify=true
Preset the port (via WriteDirectModeData, tried both mode 2 and 3)
Set up the input format for the virtual port A+B (command 0x61)
Preset the virtual port (command 0x14)
Also tried setting up the virtual port after setting up the individual ports A and B.
Then a series of GotoAbsolutePosition commands are sent (0x0D or 0x0E) in response to moving a slider. Tried to use various speeds with the same result.
In the Powered Up app, I could reproduce it as follows:
Create a coding project with one motor command item in it: the one that moves a motor to a given angle using a given speed (green item with three slots).
Set the first slot to AB, the second to some speed, e.g. 50, and starting from 0 degrees, move the motors to 180 degrees for example by hitting the play button.
When it completes, set it back to 0 degrees, and hit play again.
If one waits for it to finish, it works fine; it stops at the desired angle.
However, if one hits the play button 2-3 times in rapid succession the motors may not stop (unless one hits the stop button).
The same problem does not appear when only one port (say A) is selected
Did anyone experience a similar problem? Could anyone make synced motors go to absolute position properly in such a scenario?
I believe I have found a FW bug in the implementation of the output subcommand 'GotoAbsolutePosition' for virtual ports (both commands 0x0D and 0x0E) when using immediate execution that happens to discard a previous command. The symptom is that the command starts executing and moves the motors past the desired position but never stops. In line with that, when observing the output command feedbacks, starting from an 'idle' state, executing a first command moves the system into 'in-progress state'. Then a second immediate command discards the first, and leaves the system in 'in-progress' state, but afterwards a 'completed' feedback may never be received (neither a 'discarded', in fact, no feedback may be received afterwards). Another command sent in immediate mode can discard it, but then the next command never completes again. I was able to reproduce this behaviour by sending commands from my own custom bluetooth client and also via the Powered-Up app, which makes me believe that the error is not on my side.
The same command works well for non-virtual ports (single motor). The problem only seems to manifest itself when the command is sent in immediate mode and the previous command is still executing and is thus discarded. If I wait for the first command to finish and then send the next one, everything seems to be working fine (the second one also completes). Tested with Technic Hub with 4 ports, FW version 1.1, two technic XL motors (linear) on ports A+B.
The setup is as follows.
Then a series of GotoAbsolutePosition commands are sent (0x0D or 0x0E) in response to moving a slider. Tried to use various speeds with the same result.
In the Powered Up app, I could reproduce it as follows:
Did anyone experience a similar problem? Could anyone make synced motors go to absolute position properly in such a scenario?