I am having a hard time getting the machine to cut at the right height/depth. The short result is that the (edit) tool path doesn’t leave the (end edit) clearance plane/safe zone. Any ideas what might cause this? I don’t know what to include and what might be helpful so I’m tossing in everything I can think of.
The Hardware/Software:
• Inkscape 1.0 (4035a4fb49, 2020-05-01) for Windows
• Estlcam v11.233a-64
• Repetier-Server 0.94.3
• Duet 2 WiFi controller
The Process:
• Design 2D dog hole layout in Inkscape and saved as svg
○ 3/4" (19.05mm) holes in a 5x5 grid spaced every 6"
• Opened in Estlcam v11.233a-64
• Setup/Basic Settings:
• Exported the gcode and saved to Repetier-Server:
Dog Holes v7.gcode (50.8 KB)
• Set the cutter position to the machine origin front left as 0,0,0 and homed it there because the bed is the work piece in this case
• Repetier Printer Settings:
• Started the print job
○ The tool ran the route but seemed to stay in the clearance plane or about half a mm above the work plane.
○ Z-axis never went down
○ Server Log:
2020-11-27 11:23:34: start printjob Dog Holes v7 on printer Duet2WiFi
2020-11-27 11:27:45: Print of Dog Holes v7 on printer Duet2WiFi finished. Send 1179 lines. Printing time: 0:04:11
I’m only an occasional EstlCam user (mostly use Fusion 360), but in looking at your g-code, two things jump out at me. First, no G92 X0 Y0 Z0 is at the top of the file. This g-code is not required, but if you’ve in any way moved your router using electronics (as opposed to twisting the lead screw by hand) and not reset the home/origin, you will have a problem that can be expressed by your behavior. You can edit in this g-code to your file to see if it solves your problem. If this code is needed, then there are ways to automatically include it.
Second, I don’t see any independent feedrates being issued for Z movements. It is hard to be sure since the file is primarily arc commands. But this lack of independent feedrates is an indication that perhaps you did not setup EstlCam as indicated by Ryan. Note that the lead screw of the Z axis cannot move as fast as the belts of the X and Y axes, and steps can be lost.
Thanks gentlemen! Looking into all of the above and will post what I find. This is all brand new for me and the learning curve seems a little steep. I do appreciate this community and look forward to when I might contribute!
As I scanned down the question in preparation to close the window, I noticed another setting that does not match Ryan’s instructions. “CNC Program Start” should be changed to “At origin.” You might want to work your way through all of Ryan’s setup instructions for EstlCam to make sure you have a solid starting point.
Yessir fair enough. I chose that one deliberately in this case (perhaps in error though). Since the bed is actually also the top of the workpiece I wasn’t sure if it mattered. Thanks for catching it though, I’ll swap it and see what gives.
One thing that I can’t wrap my head around is the origin (the repetier-assigned one). Am I right in thinking that the repetier server printer/cnc origin does not matter since the gcode will be setting that immediately? Seems like as long as the bit is parked and immediately homed in the proper location then whatever repetier thinks the cnc’s origin is, is not important?
I have another idea about your problem. You say, “The tool ran the route but seemed to stay in the clearance plane,” but did the bit spiral around at each point/hole? If the bit is not spiraling at each location, then it is likely that something in your pipeline is suppressing or ignoring the G03 arc g-code commands. If so, the most likely culprit is the firmware for your board. If you are running Marlin, take a look at configuration.h to make sure that ARC_SUPPORT is not commented out. If you were running one of the boards supported by Jeff/Ryan, then I would not suggest this as a problem. But since you are running a less common board… The version of Marlin that I’m running (not the latest and for a Rambo board) has an arc support section in configuration that looks like this:
define ARC_SUPPORT // Disable this feature to save ~3226 bytes
#if ENABLED(ARC_SUPPORT)
#define MM_PER_ARC_SEGMENT .2 // (mm) Length (or minimum length) of each arc segment
#define ARC_SEGMENTS_PER_R 1 // Max segment length, MM_PER = Min
//#define MIN_ARC_SEGMENTS 24 // Minimum number of segments in a complete circle
//#define ARC_SEGMENTS_PER_SEC 50 // Use feedrate to choose segment length (with MM_PER_ARC_SEGMENT as the minimum)
#define N_ARC_CORRECTION 25 // Number of interpolated segments between corrections
//#define ARC_P_CIRCLES // Enable the 'P' parameter to specify complete circles
//#define CNC_WORKSPACE_PLANES // Allow G2/G3 to operate in XY, ZX, or YZ planes
#endif
Am I right in thinking that the repetier server printer/cnc origin does not matter since the gcode will be setting that immediately?
I don’t use Repetier Server, so I have no idea of the impact of the origin setting, but I doubt it is at the root of this problem. If you have a display and can run headless, consider running your programs directly from an SD card. This allows you to bypass Repetier Server to help eliminate it as the culprit.
So Robert as it turns out I did need to add this in. It wasn’t the immediate fix but would have caused me some issues if I hadn’t added it. Thank you for this.
I removed the bit, ran the job again, and watched the console. As it turns out the tool was moving on the Z axis as long as it was in a positive space. As soon as the gcode told it something such as “G03 Y22.4032 Z-2.2333 I4.0690 J-7.0477 F180” repetier completely ignored it and threw an error saying that it was out of the bounds of the work area (or the firmware more likely threw the error to repetier).
There is probably a more elegant fix which I will search for, but for the time being I set the design to work from the bed. I added the gcode you mentioned earlier (G92 X0 Y0 Z0) in the setup so that it’s in all files from here out. On the machine side I moved to actual 0,0,0 and homed, and left it there. I started the dewalt and then the code delivery and it worked perfectly-ish. It was going but at a snail’s pace. It was creeping along and said that it would take almost a day for my cuts.
This hurdle was solved by @jeffeb3 (Thanks mate that was spot on). I had originally set everything as recommended in the guide, but at some point that got reset and I missed the bit about telling Estlcam to use mm/min. Fixed that and all is well.
I watched a run with no tool, then cut into high density foam, then in pine. Complete success.
Guys thanks very much for your help - much appreciated.
