Posts made by gloomyandy

@glenmo What board are you using? Might also be worth posting your config.g file.

@fcwilt Before you go too far down the rathole of building firmware and bootloaders, are you sure you actually need to build either of them? From other comments in this thread (and your previous one), it would seem that the standard build for the Sammy-C21 board may do all that you need. If you only want a set of firmware that allows the Sammy to do whatever it is you need, then please provide details of the functions you require and hopefully we can help work out if you need to modify/build the firmware or not.

Of course if you want to build the firmware/bootloader "just because" then ignore this message and carry on (good luck!).

@cemu Can you post some pictures of your printer showing the print head at the "front" and "rear" of the bed?

@sankafola If it is getting that far through the G29, then I doubt very much if there is anything wrong with either the probe or RRF. I sugest (as I mentioned above) that you increase the settling time with something like R1 or even R2 and see if that allows the scan to complete.

Sorry I can't really help with this, I don't have either a smart effector or a delta and have never used either. The only thing I can add is that we have not had any other reports of issues with the stm32 firmware with this sort of setup from any other users. Given that it sounds like the probe works for G32 I think that means that the basic probing functionality is working.

I'm not sure you really answered the question that DC42 asked above. Before you start the G29 is the green LED on or off?

How far through the G29 sequence do you get before you get that message? Does the print head move at all? Perhaps you can post a video so we can see what is happening.

If when you run G29 you get that error part way through the sequence you may want to change the M558 R parameter to something much higher (like R1 oe R2), just to see if that helps.

Also are you sure that the input pin for the probe needs to pullups enabled (you have ^c.15), the Z-MAX input on that board already has a 10K pullup on it. It also has a 10uF capacitor which may be causing problems with the output from the probe, so you could try using the BL-Touch input instead.

But as I said above I really have no idea about using this type of probe. The above or just general suggestions.

@darylprice Are you running in SBC mode or standalone?

@T3P3Tony If you have analogue inputs free (or can free one up), you may be able to create a set of switches with some sort of resistor ladder that allows you to identify which switch is open/closed. How easy it would be to do this will depend on if more than one switch can be "active" at once.

@micaheli said in Duet Scanning Probe and Independent Z Leveling:

@dc42 thanks a lot. I'm surprised the accelerometer wasn't used for this.

You may want to take a look at a discussion about this over on the Klipper discourse and Github:
https://klipper.discourse.group/t/proof-of-concept-using-accelerometer-as-probe/4854
https://github.com/Klipper3d/klipper/issues/3741

They sort of gave up on it. Just to be clear some of the problems associated with using an accelerometer are also issues with touch homing with the szp. But one of the plus points is that it looks like it is possible to use lower speeds (than those discussed in the above links) when tapping the bed. I've been running some tests on the current code (along with DC42) and it looks promising, but probably still needs a little more work and fine tuning.

Apsu created this issue in Klipper3d/klipper

closed [FR] Use accelerometer as Z probe #3741

@fractalengineer I'd be checking to make sure that you are still in relative extrusion mode when running your stop.g file (might be worth adding M83 in there to be sure). It sounds a lot like you are in absolute mode and that G1 E-3 will be retracting all of the previous extrudes to get back to -3.

@aetherialdesign You need to connect to the expansion 6HC directly using a USB terminal (or via the network interface if you have that set up) and then run M122 directly on the expansion board. That will return a lot more information about any possible shutdown.

@justGuner That's very odd, it must be something specific to your board/driver/wiring/steppers/config because we must have loads of users running with stealthchop and not getting random short to vin errors.

@Dave2025 Did you try just connecting to <hostname>.local ? That will usually work on most networks without needing any router support. You may also want to upgrade your WiFi firmware, 2.2.0 is I think the current version for Duet boards.

@Dave2025 From the M550 documentation:

The machine name is also used to allow local network discovery using mDNS local network discovery. Rather than
remembering the ip address of the printer to connect to, or having to find it if assigned by DHCP (mDNS works both with fixed
ip address and DHCP), you can use it's name. Using the example name above, in your browser connect to the DWC with
http://Godzilla.local.

In terms of DHCP you may need to reboot the board (or depending upon your router even wait for the DHCP lease to expire), but it should eventually show up. But really that does not matter if your network supports mDNS.

@Dave2025 See M550 in the Duet GCode documentation: https://docs.duet3d.com/User_manual/Reference/Gcodes#m550-set-name

@gloomyandy Sorry no idea about G38.2 I've never used it.

@SanderLPFRG Sorry I should have said you will need to also swap over any axis steps/mm, limits etc. (I didn't say it would be easy!). Good luck!

@gloomyandy Just to be clear I mean do the following... Move everything around so that everything is set up to do the probe operation, swap Z over to be on V/W do the probe then swap everything back again...

@SanderLPFRG Just a random thought, but what's to stop you from switching the axis around so that your V/W axis is actually mapped to Z? Not sure if remapping the axis will clear the homed state, but if it does you can probably just use a script to transfer the current position over.

@justGuner Sorry I really have no idea. As I said previously it is very unusual to have 2209 drivers report spurious errors, that almost certainly means that the driver is actually signalling that fault (for whatever reason). If these errors were the result of some sort of random data from the 2209 I would expect to see many read errors being reported and that does not seem to be the case.

If going back to your previously working setup of all 2209s is showing problems that is not a good sign. Has anything else changed? Is there any chance that the 2209 drivers have been supplied with 48V?

@justGuner I'm still confused are you saying that if you go back to a setup that only has 2209 drivers (which was working before) you still get errors? Also when you run these tests are you removing the drivers you are not using from the board? So as I asked above, in test one did you only have the two 5160 drivers installed in the board and you still got errors.