Posts made by gloomyandy

@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.

@justGuner I'm a little confused, you said earlier that with just "stock" drivers installed you had no problems is that not the case? Has this board with drivers ever worked correctly? When you get these errors does the m122 output show the drivers are being detected correctly? In your case 1 above are you saying that you only had two 5160 EZ drivers in the board with no other drivers installed and no other drivers configured, but still got errors?

How quickly do you see these errors, it sounds from your later report that you are seeing some of them as soon as the board is used? Has this always been the case (because your earlier posts seemed to indicate that things were working)?

I've really no idea what is causing the faults you are seeing they all sound pretty odd and we have not had any other reports of those sorts of issues. Note: With this board it never makes sense to mix unmodified stepstick 2209 drivers with 5160 drivers as the spi signals will be connected to pins that are not intended to have spi signals connected to them.

@justGuner A few points that may or may not help....

1. It's not a good idea to operate drivers without a motor attached, you will get various "random" errors reported.
2. If SPI based drivers are reporting random errors it may be because of noise or other devices on the spi bus, there is no checksum or crc checks of errors reports over spi. Take particular care with drivers that are external to the board and extend the spi bus via cables.
3. It is very unusual to get spurious error reports from UART based drivers as the messages from the board are protected by a crc (which is checked by RRF). If you get an error from a UART driver there is a good chance that the driver module is reporting that fault (for whatever reason).
4. Remember that the spi signals are always connected to all driver sockets on this board, so it is important when testing to remove any driver modules that are not being using or they may cause problems with the spi bus signals.
5. When using external drivers it is important to keep any wiring to the modules as short as possible and to route it away from any motor wiring.

So it is important to distinguish which drivers are reporting the errors (and the type of driver).

We have had reports of errors being reported with external ez drivers before over on our discord server. Unfortunately the thread is not easy to follow and I'm not sure if it was ever fully resolved. See: https://discord.com/channels/711873626080804914/711873626080804917/1309486826146238474

What drivers are "stock" in your above post? Are they unmodified 2209 stepstick modules? If so I'm surprised that they work, but your modified 2209 modules do not.

@cdoe A quick update, it looks like this is actually a bug in RRF. The rp2040 expansion boards are actually operating in pio mode, but RRF is losing track of that information. It's only obvious if you have a rp2040 based board or are using a mainboard in expansion mode. Current Duet toolboards do not use dma for the led output so they will generate a pause anyway.

The fix is here: https://github.com/Duet3D/RepRapFirmware/commit/5127e951e9b89b9d213de74b66e0dfc261a8ea40 and should be included in furure releases.

However it is almost certainly a good idea to reduce how often you set the led state if you can.

0 dc42 committed to Duet3D/RepRapFirmware

Fixed clearing of DMA-capable flag in M150 to CAN-connected boards

@cdoe As explained here in the M150 documentation:

However, when using an output other than the dedicated LED output on Duet 3 boards, in order to meet the precise timing 
requirement of Neopixel LEDs, RRF waits for all motion to stop and then disables interrupts while sending the LED data.
During this time input data from UARTs may be lost, especially if there are a lot of LEDs to update. Therefore you should use the dedicated LED port if available.

If the output device is not able to use dma to update the pixel then motion will be paused. I don't think any of the existing toolboards (either Duet3D ones or the boards supported by teamgloomy) are configured to use dma output. I think that in theory the rp2040 based boards should be able to use pio mode (a form of dma i/o) to update the pixels but that is not currently the case. I'll take a look at possibly enabling that capability in 3.6, but I will need to verify that it works ok.

For now I suggest that rather than setting the state of the pixels every time through your script loop you modify the code to track the current state of the pixels and only call M150 when things change. That should reduce how often your print needs to pause.

@bug2k22 It looks like the roto board has the ability to load calibration data from NVM, I wonder if the values it is picking up are correct? Might be best to wait for one of the Duet folks to comment further before trying any recalibration though.

https://docs.duet3d.com/User_manual/Connecting_hardware/Temperature_connecting_thermistors_PT1000#semi-automatic-calibration