@zapta

Thanks for your input, in this thread I figured out, that my main problem was, that the fans are "not" PWM compatible.
That means fiddeling around with the frequency.

Sooner or later, I'll probably switch over to 12V fans. There choice in 24V is pretty limited. Thanks to Duet Hardware, it's pretty easy to run the board with 24V and the fans with 12V (which then can handle PWM).

Then the standard config with M106 should be sufficient.

@dc42 said in Question regarding G10/G11 with tool change macros:

@deckingman if you use G11 in the tpost file then the amount of un-retraction will be the value configured for the new tool. However, the amount of z-hop that is undone with be the amount of z-hop done by the previous G10 command regardless of any tool change that happened in between.

Thanks for confirming - it is all as I hoped it would be.

@jay_s_uk 👍

Do your homing files or tool change files modify the offets or force a position?

@cncmodeller Old thread but since I read some source code today to understand how jerk is implemented in RRF I am giving a shot at answering this: AIUI, the normal limits (max speeds, accelerations, jerk) are applied to the moves in cartesian space before conversion to polar kinematics. When the moves are converted to polar kinematics, they will be further limited as needed to match stepratio and turntable speeds and accelerations as set in the M669 Kinematics setup.

Edit: PolarKinematics::LimitSpeedAndAcceleration

@dc42 for what it's worth I toyed around with volumetric extrusion in SuperSlicer a few years back and I had the exact same behavior. That was still RFF 2.x I think (or maybe even RRF 3.0). Since then I figured it's just a buggy hell and I won't ever need it anyways - never looked back or tried to find the root cause..

@garis said in A good process to tune jerk?:

In essence it can test up to 3 nested for loops of M Code

IMHO there's one golden rule about "tuning": Never change more than one parameter at a time.

Beside that, it seems to be a useful tool to generate test patterns.

@adamfilip I would advise against that. Euclid mounting is extremely reliable, and with the use of the conditional g-code checks you will get a warning if not attached.

You can use the Z-endstop to set 0, then use the probe to 'reset' Z=0 with a G30 S-2 command to redefine Z at the probe trigger height

OR

You can use Euclid as your probe and endstop, and have the hardwired Z-endstop work as a high limit switch via M581 to be your 'failsafe' in case of a malfunction.
See https://duet3d.dozuki.com/Wiki/M581

OK, so I've answered my own question and have a working solution.

Short version - Sending M98 P"PrePrint" will fetch any file from whichever sub folder of .sys which has been selected using M505. So sending M505 P"6Input" will change the M98 path from sys/PrePrint to sys/6Input/PrePrint.

Longer version. I created 4 sub folders of sys so sys/6InputMixing, sys/6InputMultiMat, sys/2Input and sys/SingleInput. Then I copied the contents of sys into each of these sub folders. I edited each of the configuration and homing files to suit each hot end configuration and added an M291 to each file so that I get a message box stating which folder the file has been fetched from. I also made a file called "PrePrint.g" which has nothing but an M291 with a message stating the sys folder name. This was copied to each of the 4 sub folders of sys and edited so that the message reflects the name of the sub folder in which that particular instance of the file exists.

The config.g file which is in sys is as follows

; Configuration file for Duet Gen 3 ; ******CHOOSE .SYS PATH ****** M505 P"6InputMultiMat" ;M505 P"6InputMixing" ;M505 P"SingleInput" ;M505 P"2Input" M98 P"config.g"

By commenting out all but one of the M505 lines, and cycling power, I changed between all of the configuration folders. The I sent M98 P"PrePrint" and confirmed that the file was indeed being fetched from the correct sub folder of .sys.

So now all I have to do is move the proper Pre-Print Macros from the "macros" folder to the sys/subfolders, and change my slicer start code from M98 P"0:/macros/PrePrint.g" to M98 P"PrePrint.g" and it will fetch the correct PrePrint macro from whichever subfolder is selected by M505 to suit the machine configuration.

@owend - thanks! this is very helpful. I'm going to test today this all today, including parking the head.

@quinn post your config.g and homing files so we can see what the printer is trying to so.

It's best if you post them as text using the code snippet tool (looks like </> and is two along from the bullet point button at the top when posting)

@bart1992 I guess DWC 2.0.7 doesn't support multiple bed heaters. Probably that's because the status report that DWC 2 and earlier use doesn't have multiple values for bed heaters. DWC 3 uses the RRF3 object mode instead and does support multiple bed heaters.

@dc42 Excellent!!! Thanks for the update! I'll give it a whirl this weekend.

Here is a video on the topic, measuring the force applied on the hotend by the extruder, in a dedicated test contraption.

https://youtu.be/rrz3bbsnMUI

@topenga said in securly BLTouch deploed as Trigger:

M401 P0 S1 ;Deploy probe

it's not necessary to manually deploy the probe pin. Perhaps this is your problem.

@topenga said in securly BLTouch deploed as Trigger:

M402 ;retrec Probe
G92 Z5.9

Same for retraction.

And you probably don't want to use G92 to force a position if you're trying to use the probe to set Z0.

You should calibrate the Z offset instead.

https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probe

@jujudelta 😆

Good morning and Happy New Year to all,

with reference to this post, I wanted to point out that I have solved almost all the problems by completely redoing the print bed support. For some reason it was deforming due to heat, unevenly and this was creating levelling problems.
At the moment I am using an "aluminium tile", of those commonly used for suspended floors, and this has allowed me to solve the problem of mesh compensation.

Now I'd just like to insert a "dynamic" control in the mesh.g file (I saw it in one of your files but I don't remember who or where) so as to use a 600x600 mesh when the object to be printed is large, and a 300x300 mesh when the object is smaller. maybe @fcwilt was the author... but I'm not sure.

Could you please help me?

@spirit-robotics Hi everyone, weekend was busys, but today I find the time to test. It's work now the electromagnet into the PWM fans. Thanks to all

Best

2022-01-10.png

however I would check the mechanics from the belts to the bearings and the frame, from the graph you can see many peaks of great value, which suggests a significant mechanical instability ... I'll show you my graph by X axisCattura.JPG