Instead of input shaping, for global vibrations one could also create vibrations in opposite direction like a noise cancellation system for earphones. Maybe Piezo based, using LIS3DH as source of information.

@nuramori
@dc42 said, I could change the whole kinematic model 'on the fly', so it's worth a try..
Some parameters can't be changed mid-print, it would be nice to have a table about those do's and don'ts

@o_lampe said in M98 P"macroname" for debugging?:

@dc42
Good news!
What about a syntax-check going through all the lines and sub-macros?

That would be a lot more complicated to do.

@o_lampe said in subdirectory /bin to tidy up sys:

@resam
Just to be sure: I still download the .zip file to /sys, but it get's decompressed in /firmware?

Yes, when the firmware is 3.3beta1 or later, and DWC is sufficiently recent.

@o_lampe
Yes, you are right, my g-code is wrong, i only tried to show idea that for continues rotation distance does not matter, you need only speed and direction.
seem the most correct way will use new M code for that purpose for example:
Mxxx Xnnn; start to rotate axis X with speed xxx (non blocking command!)
Mxxx A-600; rotate axis A (setup A as continuesly rotation in config) with speed 600 counter-clockwise

@jens55 thanks for your work on getting this macro right.

I just tried using what you shared here. For my use case I see an issue with the macro:

1. I have configured my "rough" trigger height, then start a print
2. During the first layer I realize I want to adjust the trigger height slightly
3. I apply the desired change through baby stepping
4. I execute the macro to write the change to config-override.g

As far as I understand this will then reset the baby stepping on my current print and will bring me back to the initial trigger height I had at 1.)

This means the updated trigger height will be only applied after I restart the printer and would not persist for the print I have ongoing at that moment, is that correct?

My ideal scenario for this macro would be:

1. Start the print with per-configured "rough" trigger height
2. Fine tune through babystepping during the print
3. Execute the macro to save the new trigger height to config-override.g
4. Continue printing at the adjusted trigger height (taking the baby stepping I applied into account)

Now I know this could probably be solved through simply removing the M290 R0 S0 command but I would like to have the option to to another round of adjustments through baby stepping if needed and save it again with the macro. Problem here would be that if the reset is removed, I would then adjust my trigger height by the value I have adjusted originally + the value I have adjusted with in my second round of baby stepping adjustments which results in a too small or too big trigger height value. (e.g. first save was baby steeping +0.02, second adjustment is +0.04 which will then save a total of +0.06 to the value I have saved after my first round of adjustments).

Does that make sense? Do you have an idea how I could solve this?

If not, I only see the following options to achieve what I want to do:

a) Use the macro as shared above and always run a specific calibration print to fine tune the trigger height, save it, restart the printer and then kick off the print I actually want to print

b) Remove the reset of baby stepping and only save it to config-override.g when I am 100% happy with my adjustment, so I would not have to do it a second time throughout the print

@jay_s_uk said in Bed PID tuning cycle adjustment:

Currently, tuning a bed can take forever and still fail at the end of it.
Can the number of tuning cycles be specified to reduce the time required?
The new algorithm is great for tools and look ahead regarding fan usage but is too complicated for beds with the old method being more than adequate.
Can the phase messages also be adjusted to remove reference to fans when tuning a bed?

I fully agree +1
It anoys me since > v3.2. that such a basic feature works now that bad.
For the tool/hotend it works great, no question, but for the bed heater maximal bad at least with insulation.
2021-03-23 14_04_46-Window.jpg

@DanS79

; deployprobe.g
; called to deploy a physical Z probe

M280 P0 S10
G4 P200

wait for it to be deployed
as Z Endswitch i use 2000 on mesh 1000

@Phaedrux said in Anyway to view current mesh compensation Z adjustment:

I don't think so. Moved to the wishlist.

Thank you.

Frederick

@mkudzia You can cycle through the available tools quickly, which activates them all. Activating each subsequent tool sets the current tool to standby before it's heated at all. If you don't want it to run tool change macros, select each tool with the P0 parameter, eg T0 P0, T1 P0, T2 P0. Then end with T-1 P0 to set the last tool to standby, too.

Ian

@oliof I keep badgering @dc42 about this, I’d like to see it too! I think it was originally planned for 3.2, but has got bumped. Haven’t heard anything about it for 3.3, so possibly 3.4?

Ian

In principle yes, however I will need to do a little work because in some places the axis number is stored in only 4 bits.

up!

I really want this feature - or a workaround - as well 🙂

@Phaedrux Thanks!

@oliof M0 at the end of the print file to execute stop.g is not sufficient?

RRF3.3beta2 has resolved this issue. G30 now probes at full speed due to changes in M558 F parameter.

@astrn Which Discord server and Facebook group would they be then?

@oliof In the future we'll do coordinated (pre-)releases again - 3.3-b1 was an outlier, sorry for the confusion there. In general it's best to keep the SBC up-to-date by using apt only, else I cannot guarantee that the combination of DSF and RRF will work as anticipated.

@T3P3Tony said in Command to turn heaters active/standby/off?:

@fcwilt may I ask why you need to turn off (as opposed to set to zero) tools?

One use case that I would need it for would be a pause in printing.
Since you are not always on site I would like to switch off T0 and T1, but without changing or losing the set active and standby temperature.
So that when you continue printing, the correct temperatures are available without having to make this setting.

Sounds like a good candidate for a DWC/DSF plugin.