Openbuilds XYZ Probe Plus, G38.2 X moves in wrong direction
-
@phaedrux Thank you for taking the time to reply. I have read a lot of posts in this forum and I see that many of your moderator posts have a similar approach (first level problem resolution) to resolving the problem. But, before I spend the hours setting up to run standalone and or upgrading, could you tell me if there is a known issue with the SBC software, or my current Duet 3 firmware, concerning my problem with G38.2? Has one of the administrators looked at this issue and has duplicated the problem on a test rig?
From a previous post from another member "Yveske" (Duet 3 6HC with Openbuilds XYZ Probe ) that had a M675 problem that one of the admins was able to resolve in 3.3 RC1, I am reluctant to go there (I'd like to stay with the production release) unless my G38.2 problem is a known issue that was resolved in 3.3 RC1.
So are we targeting known issues or are we throwing stuff against the wall to see what sticks? I'm comited to doing all I can, but I just want to understand the approach.
-
@max3d the G38 code has been partially rewritten in RRF 3.3, so there is a good chance that it has been resolved. If you test with RRF 3.3RC1 and find that it hasn't been resolved, then there is a good chance that we will be able to resolve it before the 3.3 final release. OTOH if you don't test RC1, then if the bug is still there it will also be there in the 3.3 stable release, unless someone else reports a similar problem with 3.3RC1.
After installing 3.3RC1 from the unstable package server, please upgrade RRF to 3.3RC1+1 using the binary at https://www.dropbox.com/sh/dlb58vkmu1u4fkx/AAAelkXSfRKVwI6_yqRnhGHPa?dl=0.
-
@dc42 Thank you for the reply. I will get right on it and report back with the results.
-
@max3d, we expect to release 3.3RC2 later this afternoon, so you may wish to wait for that release.
-
@dc42 Thank you, I will wait ...
-
RC2 is now available: https://github.com/Duet3D/RepRapFirmware/releases/tag/3.3RC2
-
@phaedrux Thank you ...
-
@dc42 Sorry, late start due to GF wanting me to spend more time with her instead of my robots ... I was unable to complete the update to RC2 using the DWC. I had to restart after receiving a message that the "DUET3 window was unresponsive" after 3 hours of the DWC displaying the "wait while update" banner. Reboot came up with a "DCS not started" error message, so I ran the "sudo apt get update" and "... upgrade" on the Pi (SBC). I decided to go the "erase main board" option and run BOSSA off of the SBC (BOSSA will not run on my Ubuntu or Powerbook and connect to the DUET3), but I cannot find my Pi USBC power supply (I think my GF took it), so I just ordered a replacement off of AMZ to be delivered tomorrow.
So, before I get going down the wrong path again, what should I do to get the main board back up? Should I use the RC2 on the main board and leave the SBC alone or do I need to update the SBC with RC2 as well?
-
-
@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.
-
@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!!