uArm Serial No.: C8FD19405647
Firmware Version: 3.1.9
Operation System: MacOS Sierra 10.12.5
uArm Controlling Method: Serial port direct GCode commands
Hi there,
I’ve been working on an macOS app to control the uArm through the serial interface and using the provided communication protocol GCode commands based. I have found several bugs when executing some of the commands…
The commands M2120 and command P2220 read different XYZ values for the same arm position. I guess the right values are provided by P2220, or at least is the one consistent with the values XYZ used in the previous move to XYZ command (G0). So, if I move the arm to (0,0,0) in XYZ (this is… G0 X0 Y0 Z0 F1000\n") and then I read the XYZ using P2220 command, the right (0,0,0) values are ontained. But, if I make the reading using the timed feedback, command M2120, the values read are (150.11, 0.23, 67.73), which I do not know where the heck they come from…
Some times, movement commands are accepted (this is… an ok is received as an answer) but no movement happens in the uArm. This happens quite often when the movement is sent in polar coordinates, but also happens when using XYZ. In those situations, the only way to recover the uArm movement (without reset it) is to send a movement to (0,0,0) using XYZ.
Many times, the movement commands using the same target position takes de uArm to a different position. This happens for both types of coordinates, XYZ and polar.
I have never received an error answer, even if I intentionally send an non-existing command. The uArm always answer with ok.
M2120 returns the value received by the encoder, while P2220 returns the target value of previous move.
& 3) Please send us the commands that triggered the errors. We’ll test them and let you know.
It was caused by the initial design of Marlin firmware, which doesn’t have the feature of checking whether a command exist. We’ll see if we can improve that in the future.
According to the guide, M2120 returns XYZ in a timed feedback, and the P2220 returns also the XYZ. Assuming the movement has taken he arm to the required XYZ position, shouldn’t both commands return the same ?
Please, see the following commands sequence (the >> shows the commands sent)…
G0 X0.0 Y0.0 Z0.0 F10000
ok (<- movement done)
P2220
ok X0.00 Y0.00 Z0.00
G2201 S0.0 R180.0 H0.0 F10000
ok (<- switched to polar destination, NO movement)
G2201 S100.0 R90.0 H0.0 F10000
ok (<- movement done)
G2201 S100.0 R0.0 H0.0 F10000
ok (<- NO movement)
G2201 S150.0 R0.0 H0.0 F10000
ok (<- movement done)
It’s known issue of the firmware.
When the command asks uArm to go to a point unreachable, the firmware will still record it and the reply from M2120 & P2220 will be different. You’ll still get “ok” but uArm won’t move (because the point is unreachable).
This is because the original design of Marlin doesn’t have this feature. It will be a big change if we want to fix this.
If I switch on the uArm and make a move to XYZ (100,100,100), the arm moves there, so it is not unreachable. Then, I read XYZ by both M2120 and P2220, and readings are different. The first one differs by a +5 offset as average in the 3 coordinates, while the P2220 returns the exact position commanded previously, this is (100,100,100). There is movement because the target is reachable, but the readings are still different.
And about the NO movement when sending polar coordinates has nothing to do with the target being reachable or not. After several tests, I’ve found that the R coordinate in polars is not working ok. It seems that if the only change in consecutive move commands in polar is the R, then there will not be movement. I have to modify as well the S and/or the H.
I guess that being based in the Marlin firmware was a huge time saving in the development, but I think that there are a lot of small bugs derived from that firmware or its customization in order to be used in the uArm. I hope a big update in the firmware is coming because the uArm, right now, can’t be very safely used for precision tasks since the various small bugs related to the precision location of the arm.
This is a real good hardware… let the software be at his level.
Now an update has been made. We changed the original Marlin and you’ll get “E22” when the point is unreachable. (The problem of polar coordinates is also caused by the “unreachable” problem.)
The latest firmware-v3.1.18 is downloadable on our Github-dev branch now.
Please test it if you want.
Ah, ok, thanks… I would like to test it so… should I upload it through the Arduino IDE ? And, if so, would it be possible to rollback to the current 3.1.9 release?
@Cleo… if I try to get the Flashtool from the new official download page (http://update.ufactory.cc/#/), for the mac version of the tool (but also for win and linux) I always get this message…
