Topics created by Dutchprinting

@Dutchprinting if long straight moves are jerky, this usually means that you are using mesh bed compensation and the maximum Z instantaneous speed change set in M566 or M205 is too low to permit the required reversal of Z direction to apply mesh bed compensation.

If straight moves are K but curves are not OK, this probably means that the X and/or Y instantaneous speed change allowed is too low to follow the segments that the slicer generated for the curve at the speed requested by the slicer.

If the nature of your printer and print requires the Z axis to move other than for the purpose of implementing mesh bed compensation, then I guess the Z axis M566 setting may limit the speed even without mesh bed compensation being used.

From your config.g file I see that your M566 settings for Y and Z are rather low. We normally suggest at least 600 for X and Y.

Bear in mind that the resolution of the curve in the GCode file also has an effect. If the curve is made from longer segments, the direction change will be greater at each point between segment boundaries, so the slowdown will be greater. If the GCode was sliced from an STL model then the segment length will have been set in the STL file; so if you want shorter segments then you may need to go back to the program that generated the STL file and reconfigure it to generate shorter output segments (i.e. higher resolution output).

@dc42 Good Morning, Thank you for your reply.

The GND connection between X11 and the 1XD worked, a day later i had another issue with another 1XD but this time outputting step/dir signals.
I think the whole problem is/was that i had the machine turned on for 11 days straight and there must be too much static (pellets conveying to the extruder have alot of static (the hopper and conveyer tubes are grounded).

For the 1XD with the The step/dir signal problem, the signal was irregular and 'missed steps' all of a sudden, it became worse and worse. I unplugged power to the board and plugged it back in, it was working fine right away. So last night i turned off the machine and turned it on this morning. Now everything works fine for the past 2 hours.

Do you think this is a grounding issue? with static buildup in the whole machine being the issue?

@Dutchprinting you could use MQTT to send a message from the duet when something happens (using M118) otherwise its a case of polling the duet for data and looking for the change.
NodeRed has a node written for RRF that would be an easy way to get the email functionality

@droftarts Thank you for the reply, that answers my question!

@T3P3Tony Thank you! i think this is the way, i didnt think about the Deamon file. i'm going to try it out and update this thread!

@Dutchprinting said in Large format printer axis stops for a few seconds.:

10x5x4m

Okay, I think that's about the biggest printer volume I've heard of. Good job!

@Phaedrux He added solution to his first post, Y axis motors skipping.

Ian

@Dutchprinting said in Nema34 closed loop tuning on megaprinter??:

If you have experience, maybe you could come play around with the setup with me, i'm in the great city of Elburg.

Maybe I do that, I wanted to visit Flevobike in Dronten anyways. Alas, my experience with big printers is marginal and closed loop stepper on RRF even less.
But I often use an anti-racking technology, which is wide spread amongst huge machines.