@JayT best off getting an accelerometer and measuring it properly.
And ZVD is not the most aggressive input shaper, see the data evaluation info here about the different shapers https://docs.duet3d.com/en/User_manual/Tuning/Input_shaping_plugin#data-evaluation
maybe try ei2 or ei3

@Seba7890 the available PWM resolution depends on the PWM frequency, on which Duet you are using, and on which output you are using. You will get higher resolution at lower frequencies. The maximum resolution you will ever get is 16 bits.

@Esteban :

Well, I admit I didn't think about it, actually it was my mistake, I missed the information in the documentation... On the other hand, I still need the two resistors as in the diagram or possibly a logic step-down?

The IO_ inputs on the 6XD can tolerate 5V so you don't need those resistors. Older boards such as Duet 2 need the resistors.

@jay_s_uk said in Temperature measurement of stepper stator winding:

@shirnschall the kraken motors have thermistors embedded in them so I doubt there's any issues. The ones they use are nothing special

Thank you so much for the info.

@droftarts said in Stall Detection on Duet 2 WiFi and Duet 3 MB6HC:

Have you set up the sys/driver-stall.g macro? Even without this, you should get a message in the console, though motion will continue. If you don't get a stall warning message, adjust the sensitivity; see https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_stall_detection#stall-detection-sensitivity-m915-s-f-and-h-parameters

Yes, the driver-stall.g macro is present in my sys folder. I’ve tried setting the sensitivity value from -10 to +64, but stall detection still isn’t working.

Recently, I tried testing stall detection for a stepper motor on a tabletop setup using RRF version 3.6.0-rc1. Both daemon.g and driver-stall.g macros are present in my sys folder.
Here’s what I did:

I homed the Z motor using the G92 command. Then I moved the Z-axis with the command: G1 Z300 F6000. While the motor was moving, I manually held the shaft to simulate a stall.
However, no stall was detected — neither daemon.g nor driver-stall.g was triggered.

@mendelevium if you're still out there kicking this around
https://forum.duet3d.com/topic/11581/duet-controlled-micro-mill?_=1746675486410

Nice. I was just about to ask a similar question. Feeling pretty good about my 48v/8.5a Flexpower psu from ebay for 30 whole bucks

@oozeBot This is looking amazing! Great job!! Always room for more viewers 🙂

@awitc

echo >"/sys/coef.g" "set global.coef = {global.coef}"

Extending on what @dc42 stated above, it’s fine to permanently store a variable like this, but it comes at a cost. You only need the file storage for some parameters to survive a reboot, reset or shutdown. During runtime, global variables do the job.

Now, if you have two macros, one to store a set of globals, and one to restore these from disk (SD card), you just have to spot some events who potentially lead to a reset/shutdown, such as pause or end of print, and call the ”store” macro on these events.

The ”restore” macro has to be called only once, either at the end of your config.g or when you start a print - whatever suits your needs.

Essentially, you just have to write the ”store” macro, as it creates (by using ”echo”) an executable file which then IS the ”restore” macro. If you need some sample code on how to compose complex expressions, just drop a note.

I completely missed having a G4 P1 executing at EVERY loop iteration.

Well, that’s just a millisecond. However note the usage of G4 at this line in your daemon.g:

G4 P{var.dt} ; loop delay, 500ms, P = [ms], S = [s]

This one is essential for granting time to parallel processes. For details, look up the ”daemon” sections from the links in my previous post.

If a macro has to wait for the completion of some code in the printing queue or from another macro, don’t use a delay, use M400 instead.

@chrishamm
Thanks. Confirmed working with first=0

@DuetUser If the PSU does not connect VIN -V to PE internally, and you don't want to do this (we generally recommend doing this, but some non-standard or faulty PSUs may have -ve floating at a voltage higher or lower than earth), then yes, connect everything that needs to be grounded to the common point on the frame, which itself should be then to grounded to mains earth. Check by using a continuity tester that the metal work is grounded.

So long as the metal hardware that the ptfe tube connects to (ie the extruder/extruder motor) is grounded, I don't think you need to ground the ptfe tube specifically.

Ian

@mrjoneskod you can find the interrupt service routine for SPI transfer to drivers completed at https://github.com/Duet3D/RepRapFirmware/blob/139f16f52cd30a12431bdf5884aee6bc637b26c4/src/Movement/StepperDrivers/TMC2660.cpp#L874. The ISR checks whether a transfer has been completed and if so, reads the status and kicks off another transfer.

On boards other than Duet 2 we use a separate FreeRTOS task to poll the drivers, so as to simplify the control flow and do less work in the ISR.

@umutduman said in Duet 2 WiFi stuck in SAM-BA after SPI firmware update:

@dc42 that is PsoC which is supplying by 3.3v

I don't know what you mean by PsoC. However, when two microcontrollers communicate with each other and they are powered separately, it is important to ensure that when only one of them is powered, the outputs of that one cannot feed more current into the inputs of the second one than the maximum rated injection current of the second one. So my guess is that at some time, your other MCU was powered ands the Duet was not, causing the other MCU to feed injection current into the Duet input. In fact the SAM4E MCU on the Duet doesn't have an injection current rating, implying that injection current isn't allowed at all. Even if injection current doesn't burn out the input pin protection diode, it may trigger parasitic SCRs in some chips that then cause catastrophic damage.

Our Duet 3 main boards use an SPI connection to the optional attached Raspberry Pi or similar SBC and we have to avoid damage when just one of the Duet and the Pi is powered. We connect the SPI signals via buffers that are designed to handle inputs that are referred to a different power rail from the outputs. You can find the schematic and the part numbers of those buffers in Github, for example at https://github.com/Duet3D/Duet3-Mainboard-6HC/tree/master/Duet3_Mainboard_6HC_v1.02.

@martin7404 the M569.1 parameters only affect closed loop and assisted open loop modes, so they should have no effect when performing sensorless homing in open loop mode.

Getting 0.9deg motors working well in closed loop mode can be challenging. In particular, the encoder calibration is more critical and the maximum speed will be lower.

@DuetCDH our support team has no experience with OpenPnP, therefore I have replied in the OpenPnP group thread that you linked to. I can't see any reason why RRF would fail to respond to a command.

If you need to post here again, you should be able to include links now.

@jay_s_uk Yeah, I intend to use this as an opportunity to upgrade the firmware. Thanks

@infiniteloop I hadn't thought of that, I will try a fresh nozzle and upgrade the fan, thanks for the suggestion

@Tech_Sam03 you may not need to reduce the P term by as much as that. Try 50 to 70% of the current value.

Dual IDEX sounds really interesting, I saw a brief glimpse of your printer on Instagram and it looks really good and congratulations on your award.

You might want to consider upgrading to a 6hc board - so that you can run different gcode on the two gantries in parallel.

Would be interested in finding out more about your design - such as the kinematics your are using, bed probing, head alignment etc.