Topics created by tom33

@dc42 - thanks for the clarification.

@tom33 Can you also provide an example of when you get that message?

@dc42 I have tried the 3.5.0 rc2 but the problem still persist
as you can see in the picture :
716af1f0-f254-4868-a9c5-770e61c04d16-IMG_0366 (002).jpg

When I turn the machine in open loop mode I don't have problem when I print circle

@gloomyandy

Yes but that reference appears in the section dealing with using a P parameter with G30.

And all of the examples showing Z-9999 include a P parameter.

Since he is using -99999, if it applies in the absence of a P parameter it is just going to be the same as G30 by itself.

Frederick

@tom33 said in mesh bed compensation:

@fcwilt Yes, I have just a system to up and down the second tool head

As you understand the firmware needs to know the locations (X, Y, Z) of the Z probe and the tools, relative to one another.

With a single tool system the tool XYZ offsets are the reference (all zero) and the Z probe offsets/trigger height are set as appropriate.

Typically with a multi-tool system the Z probe is the reference (offsets/trigger height all zero) and the tool XYZ offsets are set as appropriate.

Your are combining both approaches - which will work - it is just unusual.

Where did you get the code in BED.G - there is much there that I don't understand.

When configuring your tools you have G10 L2 P1 X37.60 Y20.00 Z0. Why the L2?

Thanks.

But back to your original problem. Have you updated start.g to include a G30 before the G29 S1? Recall that the G30 used to set the Z=0 Datum should always be at the same XY machine position.

Frederick

Having the same problem here, cant get my Nema34's tuned correctly, incosistent tuning backlash and so on.

motors i'm using: https://www.omc-stepperonline.com/p-series-nema-34-closed-loop-stepper-motor-12nm-1700oz-in-with-with-electromagnetic-brake-34e1kbk50-120
Datasheet: https://www.omc-stepperonline.com/download/34E1KBK50-120.pdf

Ran through the documentation about 15 times now, including the full tuning guide. but still no succes.
It runs in closed loop tho, only with alot of vibrations and oscilations.

@dc42 You solve the problem thanks !!!

@tom33 This? https://github.com/Duet3D/RepRapFirmware/wiki/Object-Model-Documentation#moveextrudersfilament

@tom33 @Phaedrux @dc42
I am facing the same issue. When one axis is not homed, the pause.g and resume.g files are not being run when I press the pause or resume buttons on the DWC. Has this been resolved or is this a bug of some sort? Please let me know. Thank you!

@tom33 you'd have to split the axis into toe (like the old fashioned way of homing multi motor axis in RRF2), set the offset that way, and then rejoin the axis back to one

@dc42 Hi, I tested your files and the homing could be done properly.
Just to confirm I reverted to the public rc1 and the problem happens again, using rc1+2 behaves as expected.
Thanks for the help.

M375 P"/sys/_Printer/heightmap.csv"

You should not load a heightmap in the config.g, only after Z0 is set with the probe.

Can you try doubling your taper height?

@tom33 said in not running pause.g, start, resume,...:

Hi can switch between differents configurations with my machine (due to different toolhead laser, 3D printer). What is the best way to do this ?

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

This will let you have different config folders with their own files and macros and let you switch between them. Each could be configured as a different role.

@tom33 thanks for bearing with the testing. please can you contact warrant@duet3d.com to initiate a warranty return, referencing this forum post.

@tom33 Have a look at M505 https://duet3d.dozuki.com/Wiki/M505

@pcr bad cable/connector, dead driver, controller board that has gone insane...

@phaedrux said in stop movement when endstop is triggered:

@fcwilt said in stop movement when endstop is triggered:

the trigger code didn't execute until the movement completed.

This may be improved by increasing the segmentation of long moves using M669 S T

https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_Parameters_for_Cartesian_CoreXY_CoreXZ_CoreXYU_CoreXYUV_MarkForged_kinematics_RRF_2_03_and_later_only

I will try that.

It may be that my memory is faulty regards triggers and moves and my past testing - that would not be the first time - getting old is not fun.

I just tested a trigger under 3.3 and it does fire while the move is underway.

However I could not find any way to abort the move. M0 and M1 finish any moves in the buffer so that doesn't work.

I tried having a trigger set a global variable exit_loop. I installed a sensor on the X axis to fire the trigger. Then I created this macro

G90 G1 X0 ; just moving to a start position G91 while iterations < 10 G1 X10 if {global.exit_loop} = 1 break G90

The problem there, of course, is the loop quickly does all 10 iterations, putting all 10 moves in the buffer, and the loop is finished long before the trigger is ever fired.

I added a G4 command at the bottom of the loop, which worked in the sense that the loop was still going by the time the trigger fired and was able to terminate the loop but the result was move, wait, move, wait, etc which is likey not going to be acceptable.

I'm glad to test any ideas you might have.

Frederick

Take a look through these threads

https://forum.duet3d.com/search?term=door&in=titles&matchWords=all&sortBy=topic.lastposttime&sortDirection=desc&showAs=posts