Topics created by BeosDoc

@beosdoc If you actually get different ringing frequencies per tool, I think you could set different values in your tpre/tpost macros.

@chrishamm said in Restart DuetControlServer (SBC):

@BeosDoc What I find odd about your report is that you do get occasional transfers (albeit with bad checksums) so I'm wondering if there is something wrong with the SPI peripheral either on the Pi or the Duet. Can you run the spidev_test procedure as described here? I'll update the docs with better troubleshooting instructions soon.

Here's the results:

pi@duet3:~ $ RDY=22 CS=24 ; { > gpio -1 mode $CS out > gpio -1 mode $RDY in > gpio -1 write $CS 1 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" > gpio -1 write $CS 0 && echo "(Pin RDY/$RDY) `gpio -1 read $RDY` should equal `gpio -1 read $CS` (Pin CS/$CS)" > { ~/spidev-test/spidev_test -v -s 8000000 -D /dev/spidev0.0 && echo RX should equal TX. ;} | tail -n3 | cut -b-100 ;} (Pin RDY/22) 0 should equal 0 (Pin CS/24) (Pin RDY/22) 0 should equal 0 (Pin CS/24) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D RX should equal TX. pi@duet3:~ $

SPI should be working, I've done several prints. Also, this isn't a good test, it shows that it's working but 32 bytes isn't long enough to see if there is any errors during a long transmission .

Is there a SPI test for the Duet 3?

Yes the limitation for assigning multiple drivers to a single axis will eventually be going away once the config tool switches over to using the object model.

@gloomyandy

Yes that fixed the problem.

Thank you

I've just checked the RRF source. It only looks for the colon items when an "extruderLetter" is being processed. So it will be ignoring them on Z(hence no error). I'm not really sure what DSF is doing though.

for (size_t axis = 0; axis < numTotalAxes; axis++) { if (gb.Seen(axisLetters[axis])) { if (!LockMovementAndWaitForStandstill(gb)) { return false; } seen = true; #if SUPPORT_CAN_EXPANSION axesToUpdate.SetBit(axis); #endif const unsigned int microsteps = gb.GetUIValue(); if (ChangeMicrostepping(axis, microsteps, interp, reply)) { SetAxisNotHomed(axis); } else { result = GCodeResult::error; } } } if (gb.Seen(extrudeLetter)) { if (!LockMovementAndWaitForStandstill(gb)) { return false; } seen = true; uint32_t eVals[MaxExtruders]; size_t eCount = numExtruders; gb.GetUnsignedArray(eVals, eCount, true); for (size_t e = 0; e < eCount; e++) { const size_t drive = ExtruderToLogicalDrive(e); #if SUPPORT_CAN_EXPANSION axesToUpdate.SetBit(drive); #endif if (!ChangeMicrostepping(drive, eVals[e], interp, reply)) { result = GCodeResult::error; } } }

Edit: DC42 beat me to it, with a much clearer explanation!

@BeosDoc said in 4 Z motors M671 and bed.g true bed leveling:

But if you put those same coordinates in the bed.g it ignores the end stop location and try to go past because of the z-probe offset.

In bed.g you want to place the PROBE at a location as close as possible to the lead screw. So don't use the location of the ACTUAL lead screw in bed.g.

@Phaedrux

Thank you

@BeosDoc yes. Using meta code.
So when the switch is triggered, the code would then check if that particular tool is active.
https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands

@dc42 said in Toolboard extruding wrong direction after restart:

Try adding a G4 S1 command in config.g, somewhere near the start

That worked so far, tested it multiple times.

Thank You!

It was always my fault with my macros not beeing resiliant enough.

Thanks for the script but my point was a different one,
With the BLTouch we have a sensor that is able to detect and report a malfunction, which i think is a good feature.

IMHO it would be good if RRF could make use of this and be enabled to recognize when a malfunction is reported and to respond..

There is already specialised code for the BLTouch so this would "complete" the current implementation and close the feedback loop.

@aquilux thanks, I have added that to the hardware specification and description of connections in the docs:

https://docs.duet3d.com/en/Duet3D_hardware/Duet_3_family/Duet_3_Toolboard_1LC#description-of-connections

@BeosDoc said in BLTouch not deploying RRF 3.0:

Out of Curiosity, why don't you use the Z_PROBE_MOD pin on the Wi-Fi version like you do on the Maestro?

We designed the Duet WiFi before BLTouch existed, and we didn't make the MOD pin PWM-capable.