Hello Openbuilds! I am in need of some higher level brain-power as I have run out of some a long time ago... Machine Specifications: OpenBuilds extrusions (500mm x 500mm) V wheels for linear motion ACME lead screw for z axis (Basically, an ox/shapeoko/x-carve hybrid) CAD/CAM software: Fusion360 G-Code Sender (What I've tried so far): UGS BCNC GPANEL (My arduino runs 0.9J GRBL) I am trying to make a project box out of pine wood, but happen to be stuck with engraving - more specifically engraving the letter "O". Before I even go thru what I've tried, let me put up a picture to show what I am mumbling about. Engraved vs Contour Cut Letter "O": [/IMG] As you can see from the above picture, the engraved O's don't align at the arrow marks. However, if I cut out the same letter "O" with a contour cut, I can get perfect alignment. Now, I know what you're thinking - "OP, it's definitely mechanical!" BUT WAIT! If it is mechanical, wouldn't it show up in my contour cut letter "O"? And if I ran the program again, it will trace the same exact toolpath with no difference in result. I have also thought maybe squareness was an issue, but I have squared this to the point of calling it spongebobsquarepants. -_- Lastly, my circles come out great when it comes to boring/contouring/pocketing. It's just engraving that becomes an issue. Any help? If anyone needs to see a YT video of my pain, I am uploading one as you read! I will update this post with a link below. Link as Promised: *NC File is attached* Thanks for any helps!
Hi Joe! Thanks for the reply! I measured my depth of cut and it came out to be .040" (1.01mm) deep. I CAMMed in Fusion360 for the v-bit to go 1mm deep for the engrave. I thought it was lost steps too. But if I run the machine, multiple times, using the same program coordinates (no homing/no zeroing/no tampering with the original set position) it will not deviate from the previous cut path. I've actually run the same holes 3-4 times and they have not shifted or cut out more than the first run.
How about trying another cam program, like, SketchUcam or ESTLCam. I think they are both Free. Run the same sort of workload. If it fixes it then you know it's the Program for some reason. If it doesn't, then you know it's mechanical. Gray
Hey Stan. I watched the video and ran through the code(was at work earlier) and I'm in agreement that it's software related. The problem you're having is with arcs. The engraved use g2 and g3 commands. The rest of the circles are generated into straight line segments. My limited understanding of GRBL says it does support g2 and g3 commands. Places you may want to look next: Are you using the correct post processor in fusion. Are you generating code in fusion with a vbit tool and cutting with a flat end tool. Are you setting up the engraving correctly(fusion is a little tricky). Does your control software support g2 and g3. Is there a setting you missed somewhere in both pieces of software. I don't have the same combination of software/hardware nor all the answers, so maybe someone else who has had this problem will pop in and comment. If you're on a timeline then maybe you could share some modeled images of the project and we might be able to point you in the right direction to getting the job done(as Gray has started to do) and you can worry about this issue later. Joe
Hi Joe! Thanks for the detailed reply. I'm in no rush with this project. It's to house my electronics to protect them against the elements. I also posted this on the Fusion360 forum and they have traced it back to the controller as a possible culprit as well. Your post also helps me realize why contour cut works whereas engrave does not! I will try the switch from grbl to a shapeoko based post processor when I get back home. Exciting stuff everyone!
Hi Gray! Thanks for the suggestion! I believe it to be what Joe referred to as a g2/g3 interpretation issue. The Fusion360 folks were lead in up in the same direction. I will try a shapeoko based post processor and see if it solves this issue!
Hey folks! Tried it again with a post processor (based on Openbuilds actually) for Fusion360. Here is the link for a paper trail: GitHub - Strooom/GRBL-Post-Processor: Start I saw that this post processor converts the g2/g3 lines to regular linear moves. However, I am getting the same results, where the ends of a circle do not line up. I've attached the nc file along with the previous test for people to compare. This leads me to believe it might be the computer/arduino that is having trouble. I will try my laptop instead of the ancient desktop and see if that fixes my problems. If that doesn't work, I will swap out arduino uno's. Now if this doesn't work, I might be at my wit's end trying to figure this out.. -_- Thanks for the support all!
What Arduino boards are you using? There are some that have problems with the USB chip. from Frequently Asked Questions · grbl/grbl Wiki · GitHub you can recompile GRBL with a slower serial rate, that might help if you PC is slow. if your board has an CH340 chip then it may need fixing for reliable communication: How to fix bad Chinese Arduino clones BUT, it always does it in the same place, there is nothing wrong with the Gcode itself (I checked it in NC Corrector), so we are left with backlash. the difference between the characters and the final 'O' is the direction of cut, and some of them have overlapping cuts too, that go in different directions. How about drawing just a simple circle and cutting that, once with 'climb cut' and again with 'conventional cut' selected.
Agreed! Again, the Fusion 360 forum and you guys suggested the same thing! I am planning to do a set of circles with a single pass engrave and then another set with contour (climb and conventional). Next, I'll do it with the federate lowered from 500mm/min to 100mm/min. Many thanks! Btw, read my g-code and noticed my latest code eliminated all g2/g3 arc commands for the OSCP even for the O portion. So it might not be the g2/g3 faulting out.
Alright folks, I did a whole lot of testing the past two days. I will upload some pictures of the results when I get back home. But based from the results and tests, I am leaning towards it not being a mechanical, controller, or software issue for a few reasons: Not Mechanical: -Switched the v-bit engraver to a solid 1/4" endmill. Came up with the same misalignment. Flexing of the bit is not an issue. -Measured position with calipers, move an axis back and forth. Measured again. No change in position. -Rechecked all pulleys and screws for tightness. Not Software: -Switched g2/g3 to linear moves by disabling AllowHelicalMoves in Fusion360's post processor for generic grbl. Same result. -Simulation shows circles are aligned. -Tried enterering different chamfer tool tips and angles with the same result every time. Not Controller: -Visualization in Universal G Code Sender shows circles aligned. -Swapped out arduino Uno's. Circles still out of alignment. -Swapped out computers. Circles still out of alignment. At this point, I am leaning towards this being a driver issue. I run each stepper motor with a single drive TB6600. However, the ones I bought are a newer variant that few people have implemented so there is little troubleshooting available. From what I've researched, the pulse width definitely has an effect, but I have no idea what value to set this from (currently set to 10 usec). If anyone has any experience with setting up this style of driver, I would really appreciate it if you could share!
Have you tried to swap the X and Y axis driver to see if the problem follows? It seems like you only have a problem in one axis.
Great suggestion! Before I posted this problem on the forum, I swapped out each motor to find out if the problem would follow. No change in the shape or shifts in the misalignment. Repeated the same swap with the stepper drivers. No change in the shape or shifts in the misalignment. !! I forgot to mention, this is an upgraded version of my original CNC (I did a complete overhaul of the mechanical/electronics, where I went from a cncrouterparts based design to the v-wheel design). My previous electronics used DRV8825 chips with the Arduino CNC Shield to power the Nema 23 stepper motors. They are good for short (45 minute) projects. Anything longer and they get flaky (thermal shutdown) even with a dedicated fan. However, this setup gave me perfect circles so I know it works. I will setup my machine back to the original DRV8825 chips. If they make perfect circles again, then I know it's the drivers. If not, then it must be something mechanical that I'm not seeing anywhere (flexing in the gantry plates..). You're all probably wondering why I didn't think of this sooner, and I think it's because I never tried engraving in my old CNC setup (only contours, pockets, boring). When I started doing single pass work like engraving, the problem started to pop up and make itself apparent! Man, I keep learning so much.. -_-
Doing some research and found another builder suffering from the same issues I seem to be having trouble with: accuracy issue ooznest ox (what am i doing wrong) Posted to see if OP was able to solve it! Interestingly enough he is going thru the same exact logical steps as I am, haha.
Hey Jimmy! This is a repeat message on the other thread, but I wanted to post here for others in case they are facing the same problem. Looks like I found out what's causing the misalignment! Not the software, not the steppers, not the direction of cut, not the drivers.. It was the eccentric v-wheels! What's weird was that I needed to loosen them NOT tighten, haha. After I loosened them ALL (including the z-axis) to the point of the wheels being able to spin a bit, I was able to get super concentric circles! Thanks you guys for your help!
I tightened each v wheel hand tight. Then turned the eccentric spacer until the wheel couldn't move. I didn't know I needed to make them loose to the point of spinning!
