Which post processor should be used to generate G-Code from Fusion 360 to the xPro? I'm using the Grbl/grbl configuration selection but sometimes get commands that are invalid as well as some unusual behavior from my Workbee 1010 like unexpected plunges and inconsistent depths.
Hi Gary, thank you for the response. So I'm using the correct one? Grbl/grbl? Which means the errors are occurring either with UGS or at the xPro Controller, correct?
Hi Keith, Hard to say without more info, post your grbl $$ settings, and post one of your fusion generated cnc files. Cheers Gary
Hi Gary, Here are my current grbl $$ settings and one of the fusion generated cnc files. On this particular file the Z-Axis plunged into the workpiece while ramping from 0,0,0 to the first cut location - I stopped the operation but unfortunately it had already cut across the workpiece ruining the entire project board. I appreciate your help.
Hi Keith, it's your cut file, something is up with your settings, you have all your rapids inside of the work instead of above.. make sure you have your coordinates set correctly, you want Z pointing Up for up positive. Maybe your safe retract height is negative instead of positive? Also make sure you are zeroing the z at the top of the material. This video might help
Kieth, I also noticed in your cut file you have an M6 command (which throws an error in grbl). I don't think you are using the post-processor that Gary linked a few posts above. Go back and check that link again. It's the Strooom custom grbl post-processor for F360. (If you look in the images folder, you'll see an example of how to tell F360 where the custom post-processor is.) . Should get rid of the errors.
My apologies, did not recognize that Gary's post was a link and not a statement, sorry. So, I did install the post but when I post process it I get this warning; "Invalid Work Coordinate System. Select WCS 1..6 in CAM software. InFusion 360, set the WCS in CAM workspace | Setup-properties | PostProcess-tab. Selecting default WCS1/G54." I did got to the Post Process tab in Setup but found no selection for default "WCS1/G54" so I changed the "Machine WCS/WCS Offset" to 1 and that eliminated the Warning. If this is correct let me know and can you give me an explanation of the warning and the fix. Thanks. Attached is the G-Code of the test file for you reference.
Keith, I haven't used the Strooom post-processor yet - I was just pointing out about the link. (I do plan on using it once my machine is back up - just haven't got there yet.) I do think you have to be careful about where your machine is parked when you turn it on. It uses the G53 non-modal command (which the standard F360 grbl post-processor does not use). Your first line is going to plunge 10 units before it moves to WCS1. I'm just saying take care when testing. (And yes, from what I've read 1 is G54, 2 is G55, 3 is G56 and so on.) . Maybe someone who has used strooom can chime in here and explain more. There's another discussion of some of these issues here: Need knowledge on Grbl 1.1
Strooom is busy updating his post because it does have some issues. It struggles with small lead-in and lead-out arcs which Fusion generates by default. Mine has been working for me for some time..... swarfer/GRBL-Post-Processor (which is based on Stroooms) The stock GRBL post that comes with Fusion is not in fact usable because it issues tool change commands that GRBL cannot process. It also assumes you have G28 co-ordinates set correctly. My post only assumes you have Z home in a safe 'up as far as it will go' position. All you need to do is put the Z up manually and then turn on (or hard reset) the controller. My post also allows you to insert manual Gcode commands between operations...
Hello all - I'm having some very strange behavior on the Workbee 1510. The behavior is confirmed within the Openbuilds controller software as well. Basically it's not handling the circular motion well at all. It's cutting off circles and generally behaving badly. Why? I'm using the swarfer post processor from the location posted above. Attached is the example .nc file that verifies poorly in the controller software and behaves badly at the machine as well. I suspect it may have to do with ramping motion so I will try generating the path without any ramping approaches. I program machines for a living but this is all new to me with the arduino controller, etc. Can someone please try replaying the tool path in whatever way you typically use? For me, circles are not circles and it cuts off oval slots at the circular motion. What's happening here?
Openbuilds CONTROL's simulator wont follow the G2/G3 arcs exactly (not yet at least) - it will do a jump between 3 points. Its cosmetic however, G2/3 code will be updated in the future. Simulator has no impact on actual job run however, we just do our best to try and see where the gcode will be taking us (works for most but not all commands)
OK well that's somewhat of a relief. I will be testing some tool path at the machine today (unfortunately not located at my place - this is for a robotics club application) I had some similar issues with actual tool path though where it was not completing circles and producing some very strange results. I need to do some mechanical troubleshooting also though to be sure it's not a hardware issue such as a slipping belt pulley or something like that. The funky tool path was with the generic post in Fusion though. I will be testing the tool path I attached that was made with the swarfer post.
Out of curiosity, I loaded your file in Estlcam to look at it. I noticed a couple things, but maybe they were intentional. First picture - in the red oval I made - there appears to be a flat spot. When I zoomed way in, there was another smaller change in direction. This may be nothing, and it has been awhile since I have used the CAM portion of F360, but in Estlcam I get errors if my lines aren't closed when I generate CAM from a .dxf file. Zoomed way in:
I have just run that file through bCNC to an UNO with GRBL 1.1 without any issues at all. Note this was not check mode, but actual cut mode, just without any motors attached. So there is nothing wrong with this Gcode. However.... You will want to change your entrance methods. I am not sure how thick your material is, maybe 7mm? and Z zero is the bottom of the material? Anyhow, it looks like the tool may be entering the material outside the cutline as though there is no material there. If there is no previous operation clearing material away this will almost certainly break your 2mm bit instantly (-: I suggest strongly that you run this code on a piece of insulation foam before attempting metal. My post that you are using is a response to Fusion generating entrance arcs that are a fraction of the bit diameter in radius. This causes 'error 33' from GRBL from the default post since there are not enough decimal digits. My post increases the digits AND linearizes very small arcs to avoid these errors. Of course, GUI's like UGS can then break it again by reducing the number of digits before sending the code to gRBL, so make sure that is turned off. Now running in Openbuilds control 1...143 .....no errors, and display look sgood to me too.
Thank you so much for running this code and checking it out! For the record, your PP did a nice job! The material is .250" polycarbonate. I ran several parts successfully last night AFTER figuring out that the X axis motor pulley was loose, and correcting that issue. Someone other than I did some work on that motor and didn't quite get the motor pulley on the flat. These are the first parts successfully cut on this newly built machine. I did end up removing the ramping motion out of the approaches as it generated some "notchy" motion but it did actually work... Just not very well. To answer your concern regarding the ramp plunging of the cutter into the material, this was not an issue at all in polycarbonate. There is a small entry radius that starts outside the desired cut line. When I do try some aluminum, axial cut depth will be reduced. I use CATIA V5 every day for CAD/CAM work. The motion generated in Fusion 360 is top notch and frankly pretty amazing for a product that is available to the hobbyist. I've just begun playing around with what this system can do. It's impressive to say the least. When one considers the other options available, the choice is pretty clear. Thank you for your work on the Post Processor and the help in verifying the code.
Thank you for the thorough analysis! Much appreciated. The part was designed by one of my high school mentees in the robotics club and he seems to have left a flat spot on the radius! LOL. I noticed that myself but I didn't fuss him over it. (See previous post for resolution story on this) Again, thank you gentlemen for the assistance. I don't know what I would do without these forums for reference. It would have been a challenge to find answers to questions otherwise.
Update - Last night I ran some nested parts in Polycarbonate. Everything was going along fine... Until the machine decided to make a right turn prior to reaching its destination for the next corner, chopping off about 1/2" and driving right through a previously cut hole. The only explanation I can imagine for this happening is... Wait for it... I tried to send an email while the program was running? This is exactly when it happened. I had attempted to draft an email, immediately coinciding with the aforementioned "illegal right turn." I wish I had taken a photo to share... I was out of time and feeling very frustrated. Can this possibly be? Has anyone else experienced anomalous tool path when attempting to use the computer (multitasking) while running a program? I've read posts regarding 3D printers going wonky in such situations. I suppose it could have happened in this instance. General rule of thumb: "STEP AWAY FROM THE KEYBOARD WHILE RUNNING G-CODE."
Yes. A few times. And for what its worth, the OB Control rarely shows my Fusion 360 tool paths correctly. It really doesnt like the arcs Fusion creates, but it always cuts correctly if I dont multitask on the laptop.
lol, yeah, just leave it alone to run the gcode (-: (and turn off all power saving, screen saver, auto updates etc) although there is a buffer the buffer can be starved. non-genuine Uno's tend to suffer the most from communication problems too since the USB chip has bugs. I have a lovely NextBook that does just fine until the USB connection between the keyboard and tablet glitches and then weird things happen at the CNC end. I believe it is a dicky connection because the tablet can unplug from the keyboard, and the keyboard is the USB hub, and the mouse glitches at the same time. I switched to an old i7 notebook. I also switched away from a wireless mouse back to a wired mouse, weird mouse glitches that caused a few crashes when I clicked a jog button and the button stuck down (the screen button not the physical mouse button). Which is why people trying to stream Gcode via bluetooth gives me the heebyjeebies (-:
[QUOTE="Which is why people trying to stream Gcode via bluetooth gives me the heebyjeebies (-:[/QUOTE] RIGHT?!?! I really wanted the bluetooth adapter when I was building my machine. Now that I have it running, there's no way I'd use one.
I use an old crappy 11" laptop someone gave me that runs WIndows 7. It is so slow all it can run is Estlcam. Therefore, I don't bother to try to multi-task with it. It never crashes while running g-code. Prior to using that one, I had a better laptop I would use. Every once in a while I would get antsy and open up Sketchup or another program while cutting something and the gcode sender would crash. Best thing that happened to my CNCing hobby was when the hard drive in that laptop died.
Nothing like a new SSD and clean install of Win10 or 7 I just put a 128GB SSD (they are ~$30 now) into my old dell core duo xps, fresh win10 (64bit = for the first time I have full 4GB ram in this old machine!) feels snappy again. Never have had a single glitch running code even trochoidal and 3D 1.5 hour runs i'm sure i just jinxed myself ...
I bought an SSD a while back for the better laptop that had the hard drive crash. I was thinking of putting it in that one, but it needs a wireless keyboard and mouse as well because somebody - I won't name names - (ok, it was me) spilled their beer all over it and the original no longer works. So I may just try it in the old Windows 7 notebook.
Thanks for the reply and sharing your experiences. It seemed like it had to be a pretty crazy coincidence not to be related to the multitasking I was doing. The tool path was looking so good, too!
I was running the NC file with my MacBook Air, which works so flawlessly and fast that I'm always tempted to multitask. That was a tough lesson to learn. I run my 3D printers from an SD card so it's never an issue there.
