Hello folks, I'm hoping someone on here can help me out. I have several setups in a 3D job, just did adaptive clearing, which worked fine, 12 pieces in one board. And now the parallel job is whacked! I tried posting grbl and opening in both Chilipeppr and UGS nightly on both mac and pc and same results. It seems to be a glitch in Fusion. One setup is fine, the adaptive, but the parallel and all subsequent cam ops are adding these crazy tool paths. They simulate fine in Fusion. I've tried posting with Fusion's grbl generic and with the Openbuilds GRBL with the same results. I'm getting some errors in the cam ops. Here is one set of errors: Warning: One or more pockets were not machined because they are too small to be reached with given ramping constraints! Warning: Lifting retract plane to safe plane. Generation completed with 1 warning(s) in 1.4s. Error: Top B: WCS origin has 1 missing selections. Warning: Lifting retract plane to safe plane. Generation completed with 1 warning(s) in 1.5s. Warning: Lifting retract plane to safe plane. --------------------------------------------- Also, it is referencing "Top B" setup above, which has long since been deleted. I created a new setup and chose WCS properly, etc. I think it's a Fusion glitch, but I don't know where to go from here. I hate to waste this piece of wood that already has the first adaptive cut done. To re-create the layout from scratch would be terribly time consuming, especially since I don't want to risk duplicating or copying any of the current setups or ops. Also tried updating to latest grbl.cps from autodesk site for Fusion 360. Ug. This is a first for me. Anyone have any ideas of where to look? This first image is showing the crazy tool paths in UGS visualizer and the second is the adaptive that is working in the same file. I compared and contrasted setting between setups and operations, and made many changes in hopes of finding the issue. Thank you! Tyler
OK, so I found the issue. When I turn smoothing on, it all goes to hell, smoothing off, it's all good. The problem is that I rely on smoothing to knock down the code, otherwise my intensive 3d code jams up and stalls UGS. I've submitted a post on Fusion HSM post processing forum. I'll post back if I find a solution. Anyone else having any issues?
please try this post swarfer/GRBL-Post-Processor you only need the file OpenbuildsGRBL.cps and put it somewhere Fusion can find it for posting. the default GRBL post in Fusion is not very good, whoever wrote it has never used GRBL! Fusion has a habit of making very small arcs which confuse the fusion post and then GRBL. My post tries hard to prevent these issues but since I only use millimeters it needs testing in inch mode.
this means you need to adjust the ramping constraints your retract plane is too low you need to select a WCS for that setup you need to be SURE that UGS is not filtering out valid Gcode commands. UGS makes it very easy to 'ignore' lines which then breaks your job.
David, thank you for all the feedback. I'll try your grbl.cps today and post results. I tried the open builds version and that didn't fix it. I have to learn more about lead ins. Wood is so forgiving that I don't pay much attention to them to be honest. I'm going to have to up my game when I start milling metal with a cnc! The retract error seemed to be glitchy to me, my heights checked out in the op. I hope this fixes it. I lost a solid day trying to get some work out. Cheers!
Also, without smoothing, UGS was failing about 10% into a 2 hour complex operation. I switched to g-code sender software, which is very basic, I think the total file size of the software is less than 3MB, and it worked like a charm with no smoothing. I actually like entering codes to make the machine reset zero values and move around, vs buttons so it's a preferred way to work for me anyway.
David! You are my hero! Once I posted the op, smoothing on, with your .cps file, boom, no explosion! Thank you so much! Now I can get back to work with a bit more confidence. I'm going to post a link to your cps over on the Fusion site as I have an open issue. It says at the top of the post that it's optimized for GRBL V0.9j. I'm using v1.1f. Is there anything I should watch out for in the latest version of grbl, in terms of using your .cps to post?
I like UGS only for initial setup of GRBL. My preferred GUI is bCNC which I run under Linux (it does do Windows, being Python based) on a laptop that has no harddrive, just boots from a SD card. bCNC has nice buttons AND makes using the command line easy so I get both worlds. I tool like to type commands but the macro buttons in bCNC are also useful.
thanks. nice to know it is working well. yeah, it is just fine for V1.1 which is what I use, I should update the text (-: thing is I tend to make code work first and get around to the 'make it nice' later. My OX just loves 2D adaptive in plywood (-: To talk a bit about why Fusion and GRBL have this issue..... There are defaults for most values in the Fusion CAM menus that use formulas like 'bit-diameter*0.2' for the radii of the leadin and leadout moves. This means that the smaller your bit the smaller the leadin radius is. The default post does not output enough digits of precision and GRBL calculates that the start and end radiii differ too much and you get error:33. I secondary issue is the the default post does not always output X and Y for the arc moves. Yes, I know the standard allows for omitting them but I was getting errors from GRBL until I forced X and Y for every arc move. The last issue with the default post is it's use of G28. It can be disabled but the default is on and many GRBL users do not have home in a safe position and since G28 defaults to home this can cause scrapped parts. My post uses G53 instead. There are various other settings that can also cause or solve problems, like minimum arc radius and minimum chord length. Thing is that no all combinations work well together but I think my post now has a sensible default set of settings.
