Openbuilds XYZ Probe Plus, G38.2 X moves in wrong direction
-
@max3d Please use the MB6HC firmware binary from here when you flash it again with bossa. You should have DSF 3.2-RC2 installed on your SBC as well from the unstable package feed, see here for further information about how to upgrade from 3.2.2.
Duet software engineer
-
@chrishamm Thank you.
-
@chrishamm I have not been able to flash the mainboard. I can enter "~/BOSSA/bin/bossac -e -w -v -b /opt/dsf/sd/sys/Duet3Firmware_MB6HC.bin" on the Pi terminal and it takes about a minute to run and ends with a "SAM-BA operation failed". I reset the board and run again and receive the same error. I power off and erase (solid red no flashing and the 3.3 and 5v LEDs are lit) the mainboard and run the "bossac" command again and receive the same error. I even tried to flash with the SD card inserted on the mainboard. I have disconnected everything on the mainboard, the only connection is the USB from the Pi. I have used a couple of USB cables and still receive the SAM-BA failure.
I cannot use my laptops (Powerbook or Ubuntu) to flash the board because I cannot connect to the DUET 3. A strange issue with the Pi is that it cannot connect to the mainboard unless I use a USB hub. Pi is powered by the USBC power supply.
-
@max3d
Is there something wrong with the power consumption of the Duet? Can you measure the 5V rail if it's really 5V?
Maybe unplug everything that might draw current. From my experience, flashing a MCU requires stable power. -
When flashing with Bossa, the MB6HC is very sensitive to the type of USB cable and the USB port it is connected to. So try a different USB cable and a different USB port.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 After reading some of the other posts regarding flashing the mainboard. I have done just about everything, including using all the USB micro cables I have, as stated in the above post. I am thinking about performing a ritual animal sacrifice to the Duet3D Gods (praise the board...) using my neighbour's Chihuahua, but before I do that, I have ordered another two USB cables with the latest USB standard. If that does not work the Chihuahua is toast ... Cables are on the way.
Thanks for the reply,
-
@max3d said in Openbuilds XYZ Probe Plus, G38.2 X moves in wrong direction:
If that does not work the Chihuahua is toast ... Cables are on the way.
C'mon be honest, secretly you hope the new cables will fail. Giving you an excuse to do something, you wanted long before
Keep up the humor
-
@max3d Iām not sure where you are with this but i just had a g38.2 go the wrong way, scoured the doc and realized it always goes towards the origin (0) per doc. So, now I zero it near the contact point first.
Mark
-
@o_lampe You are right. I'm looking for an excuse to toast that pup. A sand flea could fart on a far away isolated beach in the Seychelles Islands on rainy night at 12:03 A.M. and that dog would hear it and bark for 31 minutes and 17 seconds. A lass the pooch has been spared. I just completed a successful erase and flash of the main board ...
Thanks for the support and kind words.
-
@dc42 After multiple erase and flash attempts with various methods in powering the SBC and main board with several different cables, I finally got it to flash. I do not know what the issue was, but I don't think I want to do that again.
I am going to reconnect everything and run the update to get it running on RC2.
-
@markz Thanks for the reply. After the update to RC2 we shall see if the G38.2 is going to behave. If not I'll give your solution a try.
-
@markz I've just been playing with G38.2 myself on my Workbee and realised that it behaves quite differently in relative and absolute positioning modes.
Under relative positioning X and Y both move towards zero regardless of the sign of the relative movement you enter (which I think is probably a bug).
Under absolute positioning X & Y move towards the position you enter (correct behaviour according to the NIST spec).
I've just got to get my head round the coordinate systems now!! -
@crossbow Huh, I didn't realize that about the relative. Thanks also for improving my comment. I use X and Y with no coords (a value of 0) since it's in a macro that's simplest and forget that's not the full use.
Mark
-
@chrishamm The problem with G38.2 persists with the update RC2 from the link you posted for the main board and the unstable update for the SBC. I will try to use the M675 command in a macro to probe the cavity in the probe plate. I think the RC2 solved a problem for user Yveske - https://forum.duet3d.com/topic/21025/duet-3-6hc-with-openbuilds-xyz-probe
-
@crossbow Since I have updated to RC2, I can get G38.2 to move in a negative and positive direction on Y and Z, but X still ignores the parameter and moves to zero under the G91 relative positioning. I was able to do this with Y and Z under the stable release as well.
-
@max3d I am still using 3.2.2. What I did was to use absolute positioning using machine coordinates (so I didn't exceed machine limits in the reference) with commands like this which worked for me:
G90
G53 G38.2 X550 F100 ;probe to some distant X to make move in forward direction using machine coordinates
G10 P1 L20 X-11.5 ;set X offset in WCS 1 to thickness of probe plate edge + 1/2 bit diameter -
@max3d check out https://forum.duet3d.com/topic/21025/duet-3-6hc-with-openbuilds-xyz-probe/48
Apparently G38.2 uses absolute coordinates. That is why you cannot get X to move in the direction you want. @dc42 suggested this instead:
G38.2 Z{move.axes[0].userPosition-25} -
@cthulhulabs Sorry for the late reply, went on Holiday... The command did not work in absolute or relative positioning. But, what did work were the commands that "crossbow" posted above. Thank you for your reply.
-
@crossbow Sorry for the late reply, went on Holiday...
And the winner is?
I ran the same code you suggested in 3.2.2 and it did not work. When I am testing I leave the code changes in the macro and just comment them out so I can keep track of what I tried. The difference was that I stayed with "G53 G38.2 X50 F100" and your code increased the X value by 500 and that made all of the difference. I can now zero the workpiece on the X axis with G38.2.
Just for kicks, I lowered the X value to 100 and it works the same as the 550 value. I lowered the value to 90 and the tool moves in the wrong direction (under 90mm, about 20mm) this time and then the pinky-orange dialogue box appears with the following message: "Error: Probe was not triggered during probing move". Testing method: I do not reset the board each time, but I "HOME ALL" after each test jog to position and run macro.
I do not know if this is just a bug for X, because I can control the direction of Y and Z without any problems in relative coords. For X the parameter value for X needs to be 100 or above ie. "G53 G38.2 X100 F100" in absolute coordinates (G90).
Many thanks to you, and everyone, for the help.
-
I'm necroing this because while it's an edge case it's still a problem.
There's a bug report on git hub that was closed because no one replied in time and it says to open an issue in the forum if it's still a problem, but I'd rather keep a discussion going rather than clutter things with new issues on the same topic. Needless to say generally having a move command not respect what type of move you're commanding and moving unexpectedly is a problem, moreso in the CNC world than the printer one, and my post on the bug details exactly how this has impacted me (my own experience is quite similar to @Max3D 's but I was lucky enough to notice why sooner). I would request that we get some attention to this soonish.
