Posts made by NeoDue

@droftarts @dc42 thanks a lot - and my apologies! I keep forgetting that your forum software only searches in post titles by default.

The accelerometer method is great though. That means I will be able to use it once it is ready

I was really happy to stumble upon this line in the RRF3.6.0 beta changelog:

[Duet 3 MB6HC] Drivers can be switched into phase stepping mode. See the new M970 command.

Is there already any information available about how to tune this? Or is that part still a work in progress? Here in the forum, I only found this thread: https://forum.duet3d.com/post/334718

@dc42 said in Software bundle 3.6.0-beta.1 now available:

@NeoDue no we haven't implemented that yet, it's separate from input shaping.

Thanks! Then I will wait until 3.6 is final.

@dc42 does the new input shaping algorithm also mean that something similar to the Klipper "minimum cruise ratio" (https://www.klipper3d.org/Kinematics.html#minimum-cruise-ratio ) is supported by RRF 3.6.0?

@droftarts Thanks! I can only state that it did indeed work on my old printer as well (on 3.3 or an early 3.4 release). Let's see what some testing will yield.

@droftarts Hm, on my mobile phone there are about 6cm distance and three fan sliders between them. I cannot fully rule it out since I admit I was tired at the moment, but I hope my brain was not that offline...

Currently I am printing the parts I need once more - this time without touching those sliders. When that is done, I can start testing

Just to be sure: can you confirm that the slider only sets M220?

@oliof It is still the same - IDEX, Duet 3 6HC and no toolboards, no SBC or such . I will add or link to everything in a possible bug report of course.

A clog or insufficient cooling was my first thought as well, but the Duet should have detected that within short due to the filament sensor that triggers every 2mm of filament. The amount of material that was or rather should have been printed was a generous multiple of that. Therefore and due to the fact that a start of another print after letting everything cool down did not cure the issue (while manual extrusion via PanelDue worked fine at the same time) but a reboot did, I am somewhat tempted to rule out something mechanical.

But I want to test more first before I bother the team here again, and if DWC really only sets an M220 or M221 value, this should be easy to confirm, hence the question.

I tried to use the "speed" slider (or rather the buttons controlling it) in DWC yesterday for the first time. The reason was to find a printer speed that makes the printer more silent since the print took longer than expected and you can hear some of the machine moves from our bedroom. Therefore my intention was to move down to 80%, then 70%, 60% 50% and listen a while.

1st observation: the buttons reacted rather laggy and the displayed value went down with each click by 5% (as it should be) but then went up again by 5% after maybe half a second or a little less.
2nd observation when I went so the printer: at one step it seemed the extruder speed got out of sync, if I interpret the result correctly: the print head moved perfectly fine, but the material that came out of the nozzle was just enough for cobwebs. When I increased speed again to 100%, more came out but still far from enough. The filament sensor did not cause the Duet to complain though even if it should.
I stopped the print and started a new one, and extrusion was still far from where it ought to be. A restart of the whole printer however immediately cured the issue.

For now, this is a one-time error which I need to recreate first, but I would like to know what those DWC buttons do to be able to check the values set by them via the console if that happens again to be able to file a decent bug report.

Could anyone explain this to me?

@droftarts you are right, "elif" works as well - and is easier. Thanks!

But I would add the note nevertheless, in case someone relies on the input variable for something else.

If you use nested M291 commands with a messagebox mode S4... S7 (the ones that create an "input" variable), the last message box overwrites the initial one, which may result in the wrong initial task being executed:

Here is a quick example. If you choose "load filament into left hotend" which is the first option in the initial message box (--> input = 0) and then choose the option not to wipe or clean the hotend nozzles, then the input variable changes to 2 which causes the option "load filament for both hotends" of the initial message box to be executed.

M291 S4 K{"left","right","both","back"} P"Please choose the hotend to load" R"load filament"
    if input = 0
        ; do stuff... 
        M291 S4 K{"wipe","manual clean","done"} P"Wipe or clean the hotend nozzle?" R"load filament - left"
            if input = 0
                ; wipe and finish
            if input = 1
                ; move to a convenient cleaning position and request cleaning
            if input = 2
                break ; finish
    if input = 1
        ; do stuff... 
        M291 S4 K{"wipe","manual clean","done"} P"Wipe or clean the hotend nozzle?" R"load filament - right"
                    if input = 0
                        ; wipe and finish
                    if input = 1
                        ; move to a convenient cleaning position and request cleaning
                    if input = 2
                        break ; finish
    if input = 2
        ; do stuff... 
                M291 S4 K{"wipe","manual clean","done"} P"Wipe or clean the hotend nozzles?" R"load filament - both"
                    if input = 0
                        ; wipe and finish
                    if input = 1
                        ; move to a convenient cleaning position and request cleaning
                    if input = 2
                        break ; finish
    if input = 3
        ; finish

This behaviour is logical if you keep in mind that the message boxes fill the variable "input" which only exists once per macro, in opposite to the "iterations" loop counter.

But since I did not think this through and kept searching for some typo for days until the penny dropped , I hereby vote to add a corresponding remark to the notes of M291 in the Gcode dictionary - something like this maybe: " NOTE: If you use more than one message box with mode S4... S7 within the the same macro, keep in mind that the same input variable is used for all message boxes, which means it only shows the input from the last message box."

@Thalios On my printer, the z homing sensor is at maximum z., therefore I do not have any issues with homing with a print.

But the Duet saves the z position at shutdown. Therefore, if you have the usual lead screw for z which stays where it is, it should suffice to just reload the z value with a G92 command as suggested here: https://docs.duet3d.com/en/User_manual/Tuning/Resume

If anyone happens to have the same issue: use the file name as variable. That complicates somewhat the code in resurrect-prologue.g (you need to check for each possible file name if that file exists and recreate the associated variable(s) instead of just executing it), but shortens the string significantly:

M913 X0 U0 Y0 Z40 E0:0 echo >{""r""^global.Modus} G91 M83 G1 Z1 F12000

(I added "r" as a bit of luxury to place the file close to "resurrect.g", since the variable only consists of a number in my case. Using only the variable gives you six precious characters more)

@gloomyandy Just 80 characters... that explains it. Let's see how I can keep that. Thank you!

I want to save one global variable in case of a power loss since this is not done automatically, and I expected this code to do the job:

M911 S22.0 R23.5 P"M913 X0 U0 Y0 Z40 E0:0 G91 M83 echo >""Modus.g"" ""set global.Modus = ""^{global.Modus} G1 Z1 F12000"

(double quotes are set for every quote as noted by @dc42 in this post)

But I get a "string too long" error - and I wonder why. The whole command has 99 characters which is well below the 256 characters maximum of RRF 3.5.1. Can anyone point me towards my error?

@dc42 Thanks, that one works as intended

In order to make axis limits tool-dependent (see here), i wanted to define the X and U limits on my IDEX printer as follows:

; config.g
if !exists(global.X_Limit)
    global X_Limit = {-175.5,151}       ; X limits
if !exists(global.U_Limit)
    global U_Limit = {-151,175.5}       ; U limits

;[...]

M208 X{global.X_Limit[0]}:{global.X_Limit[1]} Y-101:101 Z0:209 U{global.U_Limit[0]}:{global.U_Limit[1]}

That resulted in the error "M208: U axis maximum must be greater than minimum".

The same happens if I define only the U or the X values to shorten the command.

If I use the old separate notation however...

M208 S0 X{global.X_Limit[1]} Y101 Z209 U{global.U_Limit[1]}
M208 S1 X{global.X_Limit[0]} Y-101 Z0 U{global.U_Limit[0]}

...it works as it should, except that the variables are not replaced by their values in the console output.

Can anyone confirm this behaviour?

@dc42 Issue is created: https://github.com/Duet3D/RepRapFirmware/issues/979

One offtopic question, if I may: from your standpoint, is there anything I might add/contribute to clarify or increase understandability of https://github.com/Duet3D/RepRapFirmware/issues/915? I just want to make sure that the feature request contains everything that might be of help in case it might be chosen for implementation some time in the future.

When I had created that one, I had several other issues to fight with, therefore I admit I do not consider that data I presented there to be really optimal.

Braintoe created this issue in Duet3D/RepRapFirmware

open [FeatureRequest]: allow more than one keep-out zone #979

Braintoe created this issue in Duet3D/RepRapFirmware

open [FeatureRequest]: Add "suppress message" G30 probe option #915

@droftarts Depends on what the diagram shows... if I were to present this feature somewhere, I would probably go for a three-dimensional representation of where the keep-out zones are in the axis coordinate system... correct?

That might be indeed quite some help for any people who are not used to imagine three-dimensional objects in a room. I would suggest to add such a picture or a link to it to the gcode dictionary.

@dc42 @droftarts thanks a lot! I had focused too much onto the example code.Then I will check Github later today!

@dc42 I see, and M30 as it is is probably originating from Marlin, right? Then i I guess they will stay both and it is up to the user to use them. Thank you!