Hi All, I have been working with Fusion 360 for a few years now and have made a number of complex items with the Lead 1010 machine using the interface and BlackBox 4 controller. I tried to run what I consider to be a very simple cut today, but it seems that this circle is throwing some wrenches into my plans. What was supposed to be a five minute ordeal has become an all day problem. The program seems to run okay on my computer OpenBuilds Machine Control software, but when I put it in the machine, it sends the z-axis plunging downward way past what the z bottom should be (z runs >50 mm whereas work piece is 19mm thick). I have tried redoing the work in fusion, resetting the origin point, resetting the machine, rehoming (turns out one of my limits moved on me and wasn't triggering), reflashing the jump drive, updating the interface, etc. and I cannot seem to figure out what I am doing wrong here. Could you please take a look and tell me it was something simple so I can feel foolish? I am really hoping it is not something to do with the interface or controller. Did the machine configuration change from what was posted on GitHub? Do I need to redownload that? That's the one thing I did not do in fusion, but when I looked at what I have running, it hasn't been updated since 2021. Is there a new one I am unaware of? Many Thanks, CF
Hi Craig, Thank you for taking a moment to respond. I usually don't have to do that for the machine because I run my jobs off of workpiece origin. That said, I did home the machine for this job to ensure that was not the issue. I had no luck there.
Very outdated, should be on Post 1.0.42 OpenBuilds-Fusion360-Postprocessor/OpenbuildsFusion360PostGrbl.cps at 454321c0e50386b947b14ab6eca6dd10cd031b54 · OpenBuilds/OpenBuilds-Fusion360-Postprocessor and yes should home before setting zero (our post uses mix of work and machine coordinates) Note this line, in your gcode... G53 = machine coordinates. Z-10 in machine coordinates is up and stops 10mm short of Z homing switch. Z should always home upward. Machine coordinates is all negative quadrant)
Hi Peter, Thank you for taking the time to reply and for letting me know both about the post processor and that I should home the machine each time. I guess I can consider myself lucky that I have not had to rehome the machine when running jobs. It has usually been plug in USB and run from origin point. I have had to home the machine a few times, but it's no issue when I have to do it as I usually see the router move away from a programmed path when I run the first test run. You'd think that this would be the problem in this case, right? Except for I homed, and then reran and even redrew and redid the GRBL and faced the same issue. For this particular job, it has not worked in the slightest. I reviewed the G-code and see it bumps it up -10, but it does NOT run up. Instead, the z axis is immediately plunging the cutter downwards greater than 50 mm before I abort the operation for fear of slamming the bit into the waste board. This is why I am confused as to what it can be here. I know I am missing something simple. I will update the postprocessor and see what that does. Fingers crossed. Thank you again for letting me know about the post processor. edit: in reviewing the updated post processor, I appreciate that there is a note that says it requires homing the machine. (sigh) I have been getting lucky this whole time.
GotoZero in Machine coordinates (G53 G0 Z0) via terminal - which was does it go Are you homing upwards? Does it otherwise jog correctly (Z+ = lifts too up, Z- moves tool toward stock?)
____ Hi Peter, When I did go to zero on Machine coordinates, it went up. I am homing upwards. Is this an error? For further info., in my interface, I had the edit GRBL profile for Z dir invert off so that the controller would work correctly (z- drives the bit downward). After updating the post processer you had listed, I see that the job runs, correctly, but in order to do so I now have to invert the z-axis on the interface so that z+ drives the bit down toward the stock.
Home, then test. (Hover over DROs to see machine coordinates) Do have a read through Frequently Asked Questions for more info Z Zero in Machine Coordinates is up at switch trigger point, Z should home upward As mentioned before Homing is not valid if the machine isn't even jogging the right directions So now that its fixed, 1) Does it jog correctly (FIX FIRST) 2) Does it home upward (Fix Second and remember to actually Home too) 3) Does going to G53 G0 Z0 or Z-5 (just a little before the switch) go upward? Then if all these are YES, the Fusion gcode will run fine too No! Z+ = lift up, Z- = plunge down into stock. Cartesian standard Make the machine work to standards otherwise everything will always be wrong
Peter, here are videos of homing the device from interface correctly after figuring out the previous error I listed on item 3 was user error., zeroing with Openbuilds Z-touch plate, and then attempting to run the job with the updated post processer. The G-code, should run downward, but it is running the axis upward. These steps were run in this order. 1. home Machine 2. zero item 3. run Gcode. As you can see the G -code runs 105 mm upward instead of the z-10. That's the issue I am facing when all else seems to be running correctly. As always, thanks for taking the time to respond.
G53 G0 Z-10 is UP. G53 (machine coordinates) has zero at the top, entire axis (all axes) is negative quadrant. Switch up top = 0. G53 's Z-10 up top 10mm away from switch' s trigger point (its an absolute coordinate... Not a relative Z-10 move in work coordinates. Note the G53) Exactly as it should. Clearance moves with fusion post, is in machine coordinate. Z up and away is good for clearance moves (won't hit clamps etc) G53 moves are not like Work coordinate moves. Read G-Codes
Peter, Thank you, I am happy to say that you have helped me feel foolish. This whole time I thought G53 was a movement relative to the workpiece. I usually run my test higher than the work piece so seeing it run up shocked me as it usually does not do that even after homing. After reading your comment, I let the gcode run to see if it would hit the switch and it ran just shy of it and proceeded to run the job flawlessly. Thank you for helping me understand the error in my understanding of the G-code. I owe you a soda. Best, CF
