Can we please have a toolboard we can solder fans/steppers/heaters directly to? I’d rather solder than rely on those God awful crimp connectors that make me want to strangle innocent children. That would probably save money on your end too; fewer components.

I've tried helping @carcamerarig on this issue, maybe I can give my take on what's going on. We believe we have homing with stallguard figured out, but that's not the main issue.

The issue is during fast moves, the printer will stutter causing a thump sound, resulting in a layer shift. The nozzle is not hitting the print or other obstruction.

I thought originally this may be caused by the switchover from stealtchop to spreadcyce. However forcing the machine into spreadcycle after homing did not alleviate the issue during a print. @carcamerarig Can you post a link to the video showing the problem?

I've noticed in the gcode dictionary that M568 will be the preferred method to set temps going forward. I have a suggestion to make this command more comprehensive. Currently there are too many ways to set temps and M568 could be more comprehensive to consolidate things a bit more.

1. It would be nice if we could add a W parameter to wait for temps instead of following the command with M116. The existing behavior doesn't incentivize using this command over M104 or M109. It's not any cleaner.

2. It would be nice if this command would include parameters for the bed heater. M568 is an easy way to set and activate standby and active temps for the nozzle, and the bed needs the same ability other than M140.

@carcamerarig A method that doesn't require an oscilloscope would be nice.

@argo the bang issue is the more pressing concern. It’s enough to cause layer shifts. Even when locked in spreadcycle by specifying mode 2 instead of 3, OP still gets the slight banging on both 0.9, and to a lesser degree 1.8 motors.

I've been delving into tuning input shapers using the plugin, and I've made good progress. However, I've been guessing about parameters, algorithms and developing a comprehensive process. This thread could serve as a guide for others who have a lack of understanding.

• May we have a brief explanation of IS algorithms, their drawbacks, and what situations you would pick one over the other?

• It's mentioned that jerk should be just high enough to guarantee smooth curves. What are some basic values for that? My printer is a Voron V2.4 300x300 and I have jerk set to 720 mm/min for both X and Y. What jerk is appropriate for different modes? eg CoreXy, Cartesian, Delta etc?

• Do you need to reanalyze resonance if you change accelerations and speed, or is a printer's resonance constant regardless of those variables?

• Can we get a better explanation of damping factor? When analyzing resonance frequencies, what do we look for that would indicate that damping factor needs to be altered?

• In the plugin there's a field for the number of samples. What's the maximum number of samples that is useful and what are the limitations of the toolboard's ability to record samples?

I'm sure I'll have more questions as time goes by, but hopefully this is a good start.

@sebkritikel Perfect. Thought it was an admin setting and not a user setting.

@jay_s_uk Thanks!

@LB said in Microstepping (interpolation):

@PeterA

keep in mind that the more microsteps you introduce the more you divide your overall-torque into smaller incremental-torque. So basically this certainly gives you resolution but only maybe gives you accuracy. Of course if money is no objective to you, you can increase the microstepping endlessly and just buy a "stronger" stepper to have your "old" incremental-torque matched even with more microsteps Calculation-formulas for that are provided e.g. here https://www.faulhaber.com/fileadmin/user_upload_global/support/MC_Support/Motors/AppNotes/Faulhaber_AN015_EN.pdf

Isn't this a little misleading if you're in interpolation mode? The driver is essentially running at 256x. The microprocessor is only generating 16x of them, but the driver is dividing those out into 256, so essentially the torque will be the same, the only difference is the computational load on the microprocessor increases on higher step rates right?

I know this is probably a nitpicky issue, but it would be nice to have an automatic trigger so you don't have to call M0 in the slicer end code. I try to decouple as much from the slicer as possible, so there are a couple use cases where this could be polished. start.g and stop.g is one of them.

@dc42 Onto 3.6!! What’s next on the feature roadmap? Any hints?

@jay_s_uk Thanks Jay. That'll work. I appreciate it.

@Phaedrux That'll remove it on the status page but not the dashboard. I don't want it connected directly to vin running at 100% because it's loud. My option is to buy a less powerful fan or convince you to create a boolean parameter in M106 or M950 lol. I understand it would be low priority. It's not that big of a deal but it would add a little flexibility.

@Phaedrux On a duet 3 mini5 which output is an always on port?

I have a case fan that I set up as an always on fan. Is there any way you can set a flag to hide this fan from DWC? I tried searching the forum but didn't come up with much.

@ctilley79 seems the ramping moves may need firmware support.

@Exerqtor Have you had a chance to see what gcode that option produces? You could slice a small model and see what's injected with firmware retraction checked and unchecked. Who knows, it may grey out the firmware retraction option. I haven't looked yet but plan to. I agree that it may be as simple as omitting the Z parameter in M207 depending how the slicer places the G10/G11 gcodes

@oliof said in Orca slicer and Duet:

@omni it doesnt work without Bambulabs' proprietary libraries so I am very wary about this poisoning of an open source project with binary blobs.

You sure? I'd like to investigate this myself. Are you sure the binary blobs aren't specific to the bambu printers themselves? They mentioned that the tweaked slicer algorithms were open sourced and had to be to satisfy those license requirements

@gringo those are short segments where input shaping is not being applied. 3.5 RC1 attempted to fix that but I’ve found that there are still moves where input shaping is ignored. My understanding is RRF’s input shaping may receive another overhaul after 3.5 is released.

For that reason I installed klipper on my duet boards and can confirm klipper does not have the same limitations. I look forward to coming back to RRF because overall, I do love RRF much better and the hardware is just much higher quality. My goal however is to print faster without the reduction in quality, and right now klipper provides that with exceptional results.

@ctilley79 I have an older 6HC and plan on getting a 32v power supply and run it alongside a 24v power supply for fans. Since IOs are ground switched PWM, you can use different PSUs as long as the two power supply's grounds are tied together.