Amazing work I’m very interested in all of these CNC builds. I tired to make one myself but I seem to be getting an error. It seems the ABC kinematics is not playing nice its trying to declare axis twice could you guys send in your config files so I can check against it? Here is the error:
mux endpoint motion_report/dump_stepper name stepper_x already registered ({‘stepper_x’: <bound method DumpStepper._add_api_client of <extras.motion_report.DumpStepper object at 0xf6148eb0>>, ‘stepper_y’: <bound method DumpStepper._add_api_client of <extras.motion_report.DumpStepper object at 0xf6148fe8>>, ‘stepper_z’: <bound method DumpStepper._add_api_client of <extras.motion_report.DumpStepper object at 0xf6148688>>})
Hi there! No experience so far with foam cutters from my part, but it sounds cool.
If you happen to have a link to the GCODE they use I may be able to check if it can work (and/or add compatibility). Maybe @GregNuspel would like to contribute as well.
Best!
PS: perhaps it would be ok to setup a small discord server to share updates. Let me know if you’d be interested.
I did try it thankyou for the suggestion didnt work unfortuantly. I will try to troubleshoot further. I see that the kinematics calls XYZ twice shouldn’t kinematics_abc call ABC and not XYZ?
Tracked down and fixed the issue. It seems to work on the 6-axis SimulAVR setup; I don’t have access to a physical machine ATM. I’m sorry about this problem, I had been messing with a new toolhead class and forgot to cleanup the original.
You’re the man! No more errors! Still not getting motion but I need to check my config file it seems the log is not throwing any errors. Ps do you have any sort of tip jar so I can contribute to your efforts?
Glad to hear that the errors are gone. Let me know if you still don’t get motion, and in that case I’ll setup a physical test rig.
If the project turns out to be useful to you, I’d appreaciate it. I’ve just setup a sponsorship “” button on the GitHub repo. Do consider donating to upstream Klipper as well.
Okay update I got motion that is smooth but it seems look ahead is not happy. Going around arcs or any sort of G1s introduces glittering and A (which I’m using for a tangential head) seems to not want to rotate smoothly. Any ideas? I never updated Moonraker for this fork would that be an issue or is the only reason I should change the config and file is to be able to update your the forked moonraker from mainsail?
Motion is now smooth, but I see arcs (G2/G3) do not work as the code doesn’t account for additional axis in gcode_arcs.py. I’ll look at the file and see if I can implement a solution.
I will be following this topic. I am currently building a Lowrider CNC 3 from V1 Engineering and would love to use Klipper and mainsail like I do on my 3DPrinters.
I follow klipper (original), pwm_sync_channel, and your channel on github.com.
Anyway, I have an older model CNC (some type). I am going to try to set up a Recore A5 on it w/ your source extracted from klipper and added on to. First, thank you. Second, I will be reviewing your build online to see if indeed I can use it.
on Gcode Arcs do any of you experience y motion moving slower than x. Half way though the motion from y to x axis motion it tappers up and vise versa. I don’t know what I’m doing wrong. Any ideas?
Hello everyone, new here. Thank you so much for making this. I’m doing first CNC, and started with Lowrider 3 last year. Insisted on using klipper, tried multiple repos, failed, stuck and abandoned. Finally starting past few months on MPCNC and successfully running it on klipper using this repo. I’m happily running XYZ Probe using the G38.2, finallyyy!! Thanksss a lot.
Now i only start with basic 3 axis CNC, and XYZABC is probably out of my understanding for my limited programming knowledge for now. But may get there later after getting more basic experience in this.
I’m facing few bugs though, any help will be greatly appreciated as i cant figure out the cause due to my limited understanding of programming.
I’m getting “mcu shutdown: missed scheduling of next digital out event” at the end of all my milling. Successful, but at the end move, it shows error everytime. I’m using Fusion360 and postprocessor from flyfisher604 github. Kinda troublesome when i wanted to continue my next job from previous coordinates. I’ve attached my klippy log and any suggestion to fix this?
I tried the printer.cfg config for the [printer] kinematics section. It shows error and i cant start klipper. I tampered a bit and probably may be in a funny / wrong way, but it works.
Instead of specifying:
[printer]
kinematics: cartesian
instead i use:
[printer]
kinematics: cartesian_abc
axis: XYZ
I attached my printer.cfg for reference. I don’t understand why i got the error, and why this works, but it does. CMIIW please.
This last one is not a bug, but more of a cool feature i wish klipper may have for CNC. Expanding on G38,2, one cool thing i like from ESTL Cam is the ability to fix misaligned stock / probe position.
I guess probably it uses G68 & G69 G Codes: CNC Coordinate Rotation, which exists in Marlin but not in klipper now. I don’t know what it takes to make that happen but it will be really cool to have.
That’s about it for now, thanks a lot for making this happen. Finally Klipperized my MPCNC, woohoo.
Understanding Marlin’s code is currently beyond my capability.
Options:
If the extra axes are expected to move linearly along the arc (i.e. as the Z axis would in an XY arc, resulting in a spiral move), then it’d be easy for me to implement it.
In the meantime, avoid using G2/G3 commands. Some GCODE post-processors can turn arc moves into a lot of small linear moves (instead of having klipper do it). This might cause GCODE streaming problems.
If a more complex behaviour is expected for the extra axes during an arc move, perhaps we can get one of the gurus to implement it.
That’s correct. sorry about that. I just pushed an update that raises an error on anything but “cartesian_abc” (or “none”).
I can fix “cartesian” but since the other one works, and does mostly the same thing, this is not a priority.
Hmm I don’t recall facing this error. Some hopefully relevant questions:
Is the error related to the [output_pin TOOL] section? The last bits of your GCODE may also help me figure it out. The entire file would be better of course.
Yes, you are correct A axis is tangential to arcs and rotates along the z axis. The A will turn around the arcs and is implemented in code just as the extruder is done in arcs. Segmentation of movement based upon the amount of G1s that klipper cuts the G2/G3 into. I’ve figured that portion out and ill provide that code shortly but I’m sure you can develop some better code. The problem I’m experiencing is motion going into the arcs on the Y axis it starts slow and then as the arc goes into the X axis it ramps up and vise versa. I have no idea why this would happen even if I don’t use A and it is just an X and Y movement it does the same. Have you experienced this at all?
Marlin’s G2,3 should also select the xy plane, yz plane, and xz plane like general machining centers and perform circular motion only in them. You shouldn’t be able to do any exercise related to the ABC axis. If you really want to do it, you need to create a G code divided into minute sections with CAM.
I’ll be really busy this week, I’ll trace the cause in a few days.
” button on the 