Openbuilds XYZ Probe Plus, G38.2 X moves in wrong direction
After 3 days of trying to understand what is causing "G38.2 P0 X50 F100" to seek along X in the opposite direction (it does not matter what the X value is "50" "-50", it only moves to the left), I only figured out that I'm going to need more help...
I have checked the entries of similar probing problems on the forum pertaining to Z going in the wrong direction and have tested various config parameters on my config.g, but G38.2 consistently ignores the direction specified (X50) and moves in the negative direction away from the probe touch plate.
There are no problems with the Y and Z. The macros execute without error using G38.2 .
Some interesting quirks that I encountered was that the tool defined by M563 and the probe defined by M558 could not share the same id number (0) or the DWC would default into Mode:FFF and would not display axis letters or positions in the "Status" area.
Just for fun: "M675 X R8 F100 P0 " - Find center of cavity in X axis fails because a probe was not specified.
Problem: Why is "G38.2 P0 X50 F100" moving (away from the touch plate) in the wrong direction? I can complete the macro if I push the touch plate against the endmill to trigger the probe or let it move 50 mm and report an error. When I use G38.3 it moves in the same direction as G38.2
Probe X macro: (the 'P0' probe number parameter for G38.2 does not make a difference, default probe number is 0)
; Jog-E-X-Probe.g - Eighth (3.2mm) end mill X Probe, jog tool in position to touch plate B4 starting this macro ; G21 ; Metric G91 ; Relative positioning G38.2 P0 X50 F100 ; Seek along X until contact with probe plate G10 L20 P1 X-11.6 ; Store probe offset's in co-ordinates system for X G91 G1 X-5 F300 ; Back away from touch plate G91 G0 Z15 ; Move Z quickly up G90 ; Absolute positioning
Probe Y macro:
; Jog-E-Y-Probe.g - Eighth (3.2mm) end mill Y Probe jog tool in position to touch plate B4 starting this macro ; G21 ; Metric G91 ; Relative positioning G38.2 Y50 F100 ; Seek along Y until contact with probe plate G10 L20 P1 Y-11.6 ; Store probe offset's in co-ordinates system for Y G91 G1 Y-5 F300 ; Back away from touch plate G91 G0 Z15 ; Move Z quickly up G90 ; Absolute positioning
Probe Z macro:
; Jog-Z-Probe.g - end mill Z Probe jog tool in position to touch plate B4 starting this macro ; G21 ; Metric G91 ; Relative positioning G38.2 Z-50 F100 ; Seek along Z until contact with probe plate G10 L20 P1 Z9 ; Store probe offset's in co-ordinates system for Z G91 G1 Z5 F300 ; Back away from touch plate G90 ; Absolute positioning
; Configuration file for Duet 3 (firmware version 3) ; executed by the firmware on start-up ; ; generated by RepRapFirmware Configuration Tool v3.1.4 on Wed Jul 29 2020 15:25:39 GMT-0700 (Pacific Daylight Time) ; General preferences ;M453 ; CNC Mode G90 ; send absolute coordinates... M83 ; ...but relative Spindle moves M550 P"Duet 3" ; set printer name ; Drives M569 P0.2 S1 ; X 0.2 physical drive goes forwards M569 P0.0 S0 ; Y-R 0.0 physical drive goes backwards M569 P0.1 S0 ; Y-L 0.1 physical drive goes backwards0 M569 P0.3 S1 ; Z 0.3 physical drive goes forwards M584 X0.2 Y0.0:0.1 Z0.3 ; set drive mapping M350 X16 Y16 Z16 U16 I1 ; configure microstepping with interpolation U=dummy Y axis M92 X400.00 Y400.00 Z400.00 ; set steps per mm M566 X900.00 Y900.00 Z12.00 ; set maximum instantaneous speed changes (mm/min) M203 X2000.00 Y2000.00 Z1000.00 ; set maximum speeds (mm/min) M201 X500.00 Y500.00 Z20.00 ; set accelerations (mm/s^2) M906 X3000 Y2500 Z3000 I30 ; set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout ; Axis Limits M208 X0 Y0 Z0 S1 ; set axis minima M208 X513 Y385 Z75 S0 ; set axis maxima ; Endstops M574 X2 S1 P"!io0.in" ; configure active-high endstop for high end on X M574 Y1 S1 P"!io1.in" ; configure active-high endstop for low end on Y M574 Z2 S1 P"!io2.in" ; configure active-high endstop for high end on Z ; XYZ Probe Plus M558 K0 P8 C"!io3.in" H20 F120 T300 ; Z probe number - Z probe switch type - probe recovery 1s probe speed and travel speed G31 K0 P500 X0 Y0 Z10 ; Set trigger value - set offset and trigger height - Z probe number ; Fans M950 F0 C"out7" Q500 ; create fan 0 and set its frequency M106 P0 S1 H-1 ; set fan 0 value - Thermostatic control is turned off M950 F1 C"out8" Q500 ; create fan 1 and set its frequency M106 P1 S1 H-1 ; set fan 1 value - Thermostatic control is turned off ; Tools M563 P1 R0 S"Spindle" ; define tool 1 G10 P1 X0 Y0 Z0 ; set tool 1 axis offsets ; CNC M453 S1 C"out1" R24000 Q100 T1 ; set to CNC mode using tool 1 pin=1 max RPM 24000 PWM frequency 100hz ; Custom settings are not defined M564 S1 H1 ; disable jog commands when not homed M140 H-1 ; disable heated bed G54 ; Use Workspace Coordinate System M501 ; load stored parameters
06/05/2021, 17:15:37 M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.2.2 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode) Board ID: 08DJM-956L2-G43S8-6JTDA-3SJ6T-1B0AH Used output buffers: 1 of 40 (10 max)code_text === RTOS === Static ram: 149788 Dynamic ram: 62172 of which 40 recycled Never used RAM 146832, free system stack 130 words Tasks: Linux(ready,101) HEAT(blocked,356) CanReceiv(blocked,927) CanSender(blocked,352) CanClock(blocked,352) TMC(blocked,53) MAIN(running,1269) IDLE(ready,19) Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:34:59 ago, cause: software Last software reset at 2021-05-06 16:40, reason: User, none spinning, available RAM 146872, slot 2 Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a Error status: 0x00code_text Aux0 errors 0,0,0 Aux1 errors 0,0,0 MCU temperature: min 38.4, current 39.0, max 39.5code_text Supply voltage: min 21.6, current 24.0, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0 Driver 0: position 51789, standstill, reads 60407, writes 27 timeouts 0, SG min/max 0/578 Driver 1: position 26524, standstill, reads 60407, writes 27 timeouts 0, SG min/max 0/539 Driver 2: position 11672, standstill, reads 60403, writes 31 timeouts 0, SG min/max 0/591code_text Driver 3: position 0, standstill, reads 60399, writes 35 timeouts 0, SG min/max 0/716 Driver 4: position 0, standstill, reads 60423, writes 11 timeouts 0, SG min/max 0/0 Driver 5: position 0, standstill, reads 60423, writes 11 timeouts 0, SG min/max 0/0 Date/time: 2021-05-06 17:15:36 Slowest loop: 160.77ms; fastest: 0.04ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === DMs created 125, maxWait 89642ms, bed compensation in use: none, cocode_textmp offset 0.000 === MainDDARing === Scheduled moves 70, completed moves 70, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 56], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP* is doing "M122" in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger* is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === CAN === Messages queued 5, send timeouts 10499, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 48 === SBC interface === State: 4, failed transfers: 0 Last transfer: 1ms ago RX/TX seq numbers: 10053/10053 SPI underruns 0, overruns 0 Number of disconnects: 0, IAP RAM available 0x2c8a8 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.2.2 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 36.06 Maximum length of RX/TX data transfers: 2716/688
My M98 P"config.g" - does not display anything on the console.
Just in case a visual is necessary. This is how I set up before I run the macro to probe X. The spindle moves to the left, away from the touch plate.
This post is deleted!
Can you test it in standalone mode to eliminate an issue with the SBC software?
Also, could you test with firmware 3.3 RC1?
@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.
o_lampe last edited by
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,
o_lampe last edited by
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
markz last edited by
@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.
@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.
crossbow last edited by
@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!!
markz last edited by
@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.
@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