Best posts made by kcress

@deckingman

1. Check.

2. Tried M302 P1 four times. It may have allowed the extruder to run on the 6HC but I'm thinking the DWC may have still been blocking the sending of any extrude or retraction presses while it looked only at the temperature before enabling the sowtware buttons. e.g. if I'd have sent the extrude G code it probably would've extruded.

3. Totally get this but because this new extruder has never seen filament and I was in commissioning mode I never even thought about heat at all.

4. Thanks for clearing this up. Makes sense.
   The default temp allowing extrusion is 160C while the default temp allowing retraction is 90C.

Thanks again. This bought me a night of sleep.

Count this one solved.

@kcress After 25 minutes I rebooted the HC's.

Then it left me muddling about since it changed IP addresses. Had to comb the router tables to find Waldo. But it was there and now I get motion too. A little screwed up X,Y move reversed directions but I should have that sorted after some sleep.

Thanks all for the help.
chrishamm; A big thanks for jumping on that configurator issue so fast. Big kudos man!

A come-back note:

Noting that the heaters were reading too low. With the original Vivendo Troodon M308:

M308 S0 P"temp0" Y"thermistor" T100000 B4138 C0 R4700 ; define bed temperature sensor

The temperatures were corrected by removal of "R4700"
which is a compensation for what divider resistor is used on the Duet board or clone. Removing the R4700 and leaving it the default (whatever it is on the Duet 6HC) corrected the temp readings.

@engikeneer Hi!
That's right the S now has to equal the number of Z motors. Thanks for reminding me.

As I mentioned the MACRO I whipped up? That's the G30 with S-1. Works well!

Well no one could tell me how to just drive a specific stepper output...

So, I decided to simply de-allocate three of the Z motors at a time in the M584 line of the config.g and do a Z move of the remaining one after an M564 H0 to allow un-homed movements. SMALL moves!

Doing that I could see which of the 4 Z motors was actually moving as compared to which one I thought should be moving.

Turned out instead of:

; --- drive map ---
;    _______
;   | 3 | 4 |
;   | ----- |
;   | 2 | 5 |
;    -------
;     FRONT

I actually had:

; --- drive map ---
;    _______
;   | 5 | 4 |
;   | ----- |
;   | 2 | 3 |
;    -------
;     FRONT

Which utterly screwed up everything causing the incrementing LR corner error and decrementing RF corner error with each G32 command. The errors even accelerated as with each subsequent G32 the error was greater demanding greater yet miscorrections

I'd traced all the cables manually but accidentally swapped those two even writing which Z motor they were(n't) on the cables.

I swapped those two on the 6HC and then ran HOME ALL and then consecutive G32s.

12/28/2021, 3:06:34 AM G32
Leadscrew adjustments made: -0.757 -0.154 1.087 -1.036, points used 4, (mean, deviation) before (0.024, 0.619) after (-0.000, 0.000)

12/28/2021, 3:07:28 AM G32
Leadscrew adjustments made: 0.099 0.146 0.462 0.296, points used 4, (mean, deviation) before (0.286, 0.104) after (-0.000, 0.000)

12/28/2021, 3:08:30 AM G32
Leadscrew adjustments made: 0.015 0.026 0.055 0.039, points used 4, (mean, deviation) before (0.038, 0.011) after (-0.000, 0.000)

12/28/2021, 3:21:13 AM G32
Leadscrew adjustments made: 0.007 0.005 0.006 0.006, points used 4, (mean, deviation) before (0.006, 0.001) after (0.000, 0.000)

Dang, what a struggle that was.
I do like the results! I appreciate only 0.0003" errors!!

So the lesson with 4 Z motors is this:

If, with repeated G32 (bed.g) runs any one corner increases its error positively while any other corner simultaneously has an increasingly negative error electrically swap those two corner's Z motors.