Topics created by SanderLPFRG

@Notepad @droftarts ,

My goal is to test a shitload of probes, and see how much it starts to deviate after thousands. Your script might actually work, let me test

@gloomyandy said in Trying to fix my dual markforged (HAQ-XY) kinematics:

at it is probably not a good thing

Ill redesign the belt tensioning mechanism and the belt mounting, when measuring it indeed looks to be too loose
WIll see what this does

@cosmowave No, Markforged (HAQ-XY) kinematics

@SanderLPFRG what hot ends are you using? Modern hot ends such as Revo heat up much faster than older ones.

@gloomyandy really interesting and a very good article! I have not seen it before.

Funny to see they first chose the ADS1263 but later moved back to the HX sensor. It does seem effective, but probing at 1mm/s is less than we aim for (we have a bed size of 600x500 with a probing grid of 11x11, (if we probe the entire bed)

Therefore we now plan to read the signal directly at the microchip

Expanding on what @stuartofmt has said, it's unlikely that there would be a significant difference in temperatures if your bed conducts heat well (which it should). But in the unlikely event that there are significant differences, then cold spots would likely cause problems with first layer adhesion whereas hot spots are unlikely to cause any significant issues. Therefore, it would make more sense to use a single temperature sensor located at a known cold spot.

@SanderLPFRG You could try keeping the G91 + G1 Z1 in your tree, but then in tpost you could set up a restore point move?

https://docs.duet3d.com/User_manual/Reference/Gcodes#g1-controlled-linear-move

Example - G1 R2 Zxxx , with xxx being your Z-hop height, and then follow that with G1 R2 Z0. Likely would want both lines at the end of your tpost. This would restore the print head to the position stored before the tool change, but offset by Zxxx. Then it would restore down to an offset of Z0 from the restore point (thus completing the Z-hop).

@SanderLPFRG in the following I will assume that the engraving was done using back and forth scanning in the X direction, so adjust axis names appropriately if not.

Measure the X offset between adjacent lines in that engraving. Then try jogging the X axis back and forth a distance smaller than that and see if the tool head moves as expected.

Alternatively: construct a GCode file to engrave a short line in the Y direction, then move X a short distance (less than or equal to the offset), then engrave another short Y line, then move X back to the original position and engrave another Y line. Check that the X offset of the middle Y line from the outer two Y lines is the correct amount.

Another possibility is that the tool head is rotating about the Y axis as the belt or leadscrew pulls/pushes it first one way and then the other way. Such a rotation will affect the X position of the laser spot on the workpiece.

@SanderLPFRG

Why doesn't it put the variables correctly in the arrays?

It might help to study the GCode meta commands. In the section „Use of expressions within GCode commands“, exactly your case is demonstrated with an example (and why your expression would have worked with RRF 3.2 back then). From the documentation:

If a parameter of a G- or M-command requires multiple values and you want to use expressions for some or all of them, then when using RRF 3.3 and later the parameter must be expressed like this:
{ <expression_1>, <expression_2>, <expression_3> ... }

@jay_s_uk Wow I seriously have read over that 10 times I think. sorry for the unnessecary question
Thanks all!

@SanderLPFRG if you're keeping the 5v powered throughout you'll be fine cutting all 24v.
If you're cutting the 5v power as well then you "may" have corruption issues on the pi. But saying that I have never properly turned off any of my pi's (running a mixture of SSD's and SD cards) properly and haven't managed to corrupt a system yet

@deckingman said in X and U axis move in when homing Y-axis:

e first move will set the homing flag, then you can use H0 or simply omit the H parameter for the second step where you move away from the endstop. So either G1 H0 Y-5 F3600 or

Thanks, done that and now it works

@SanderLPFRG Make sure you have specified the correct sensor orientation. This is critical so the Duet knows which accelerometer axes match your printer axes.

Check the documentation here:
How to set the orientation

and here:
https://docs.duet3d.com/User_manual/Reference/Gcodes#m955-configure-accelerometer

@SanderLPFRG https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_Accelerometer

@jay_s_uk That's a timely reminder. I said I'd test these macros out once I got my printer build finished but then forgot all about it. I'll do it in the the next few days and report back on your main thread.

@Herve_Smith
i did, but it kept giving errors, I switched back and forth between stable and unstable, reset date/time, and it then worked.

IS is working in beta4 on markforged kinematics, so it indeed was a bug in beta2

Did you ever find a solution to this? I'm getting ready to setup my orbiter filament sensor.

@ctilley79 Having a mesh can interfere with IS, but that typically happens with a fine mesh, low acceleration and higher target speeds. It is certainly worth trying with the mesh disabled to see if that makes any difference. As I mentioned earlier using M669 (move segmentation) can also stop IS from being applied to some moves.

@OwenD I did exactly that yesterday late afternoon. It is working now.

; Custom buttons M950 J1 C"^io2.in" ; define logical input for E1 filamentsensor M581 P1 T2 S0 R2 ; define trigger for filament auto load (trigger2.g) M581 P1 T4 S1 R1 ; define trigger for filament runout (trigger4.g)

Thank you very much both!

@SanderLPFRG Yes.