Topics created by oliof

@chrismbp thanks for your report.

We have the possibility of using separate input shaping for the Z axis in RRF 3.6 or later if it turns out to be useful.

@oliof Link to new version: Conditional G Code best practice.pdf

I'm discussing with @T3P3Tony how to best incorporate this in the wiki.

Ian

@dc42 Submitted #975, thanks.

@moth4017 try the echo keyword in comditional gcode. Failing that M117 display message.

@dc42 I've yet to design a proper way to mount my rat's nest of components, the amplitude error goes away when I hold the coil some millimeters above the print bed.

Considering the individual cost of a Sammy C21, LDC1612, and an accelerometer, the SZP is both cheaper and more convenient (-:

@oliof I have updated these pages with info on connecting SZP and accelerometer, and written the SZP calibration page:
https://docs.duet3d.com/en/Duet3D_hardware/Duet_3_family/Duet_3_Scanning_Z_Probe
https://docs.duet3d.com/en/Duet3D_hardware/Duet_3_family/Duet_3_Roto_Toolboard
https://docs.duet3d.com/User_manual/Tuning/scanning_z_probe_calibration

I'll check them when I get an SZP and Roto, hopefully early next week.

Ian

@gloomyandy the values I quote are as used in my config.g, so yes there is a unit confusion error here. Which would put massive limits on e acceleration (although it is not entirely clear to me what happens if E acceleration exceeds the limit of E jerk/PA).

EDIT: OR the limits are to be computed as above and the unit confusion is irrelevant. One for @dc42 to clarify.

@dc42 great, I was searching for "slot" and "position". Even better!

@oliof last time I looked, Marlin used fixed width fonts, although that might have changed by now. RRF uses proportionally spaced fonts.

The point is to avoid daemon.g and globals due to the side effects (SD card wear and delayed reaction to changes).

An SBC plugin would be an interesting first approach. It might even be one where I would consider SBC mode useful ...

@oliof yes, I saw their blog post and twitter thread:

https://twitter.com/Duet3D/status/1649257952723730432?s=20

I expect it wont be quick to integrate into our documentation site directly. potentially something to look at when WikiJs graduates to 3.0.

In the mean time I will play with it in the next few weeks to see if its hostable in another sensible way.

@tas no worries. In your case I would have assumed bad signal, but your signal strength is pretty decent at -55dBm. Nonetheless, if your antenna is in an enclosure or close to a wall, consider reloacting it.

@oliof thanks for reporting this. It will be fixed in RRF 3.5beta3 and 3.4.6.

@sebkritikel my individual IDEX heads are pretty light (two EVA toolheads, can run 20k and more acceleration on other machines) and only run in X (its still an i3 style bed slinger), so I think I am good on the weight front.

I guess I need to actually put an accelerometer on mine since the Klipper test print shows almost nothing in terms of ringing. if that gives me weird graphs, I will go hunt for things that move when they shouldn't.

@oliof thanks, I understand what you are asking for now.

@oliof thanks for confirming what was going on!

@T3P3Tony thanks, I will give it a whirl and share something here.
@sebkritikel that is the plan, get "toolmode" from slicer or prompt for it in start.g using the new M291 method, and then swap things around.

@droftarts I like the active search thing as well, that part I wasn't complaining about (-:

@dc42 also from the Marlin discord

Prusa MK3 firmware's thermal modeling is making some great advances, able to detect thermal anomalies that could indicate a blob of filament building up on the nozzle, and allowing for continuation. We'll get those enhancements into MPCTEMP and our own thermal protection at some point. Prusa developers on Slack are a little cagey about when they will contribute Marlin patches, but at least they are asking about it.

Are you planning any work towards this?