Thanks for the reply. It was homed and all zeroed. Then pressed start and z just went straight down till the limit and got the error message.
Spindle moved down and should display plus not minus value? In fusion with the openbuilds post processor. Pretty much the same situation when taking a file from openbuidls cam.
The back, right, UP corner of your machine is the MAXIMUM for each axis, but is set to ZERO in the MACHINE co-ordinate system - as you move away from that corner the MACHINE co-ordinate becomes lower - that is more NEGATIVE. As you move Z down the coordinate will become more negative, not positive. The Openbuilds post processor for Fusion uses the MACHINE co-ordinate system for safety moves at the beginning and end of the job. When you jog your machine X +ve should move right, Y +ve should move back, and Z +ve should move up - is that the case? Alex.
So I found that my z axis was not homing. Reflashed it and now can home it. So the machine and box in the control soft allign. But problem remains that the work itself is placed ontop of the box in the soft. So when the spindle tries to move that high it just hits the limit switch. How can I move the job in my shadow box in the control software?
Hello greetings, comment that the latest version v1.0.354 does not work on linux and I tried it on two different PCs, one with Ubuntu, the one I have connected to the CNC, and the other with Neon KDE and in neither of the two operating systems can I get the program to work. This has happened since the last update. I have been using your software for several years. Thank you.
By Homing and then setting Work Zero properly. Work Zero and Origin in CAM must match of course. We also assume you did work through the Grbl wiki and made sure your homing, including a) jog directions and b) homing dir (which tells Grbl where the switches are) has been done correctly If Grbl is correctly set up, setting home, origin and work zero correctly is the job of the operator (you). Watch the Hello World Video for a rundown
This is a completely unimportant issue but my time estimate when I run a plot is generally really off, sometimes by an hour or so. Is there a way to get it more accurate? It would be nice to generally know when something will finish but also I can easily live without.
The CAM needs to know the cut speed (it does) and how fast your machine rapids (it doesn't) to get this accurate.
Hi Guys, Updated Oenbuilds Control again today and have got another error pop-up on the surfacing wizard. See the picture attached. The surfacing wizard runs but fails with the router not switching off, I have to end the wizard with the OK button, any help is greatly welcome.
The error mentions a Z-0.1 move, but none of your values in the screenshot has 0.1mm decimals? Are you sure those are the same parameters you used earlier? Try another round with the positive values as entered in the screenshot please. If that also errors, please provide the Gcode (gcode editor tab has a save button)
Sorry Peter, give me a minute as I've just left the workshop, I know the parameters are different than before and the error occurs even with positive values. Just heading back to get the gcode.
Using your exact parameters I don't generate any double-minus gcode. I suspect we have different screenshots and files and things causing confusion here. Start fresh, use positive numbers only and it will work as designed. "Depth" is a positive value = you want to cut 2mm deep (but the machine will move to Z-Position of negative-2 for that) so don't enter any -2 or -1 etc values - and it will work. Tested again. If it does happen to you next time - make sure we definately have latest CONTROL (1.0.355 at the time of this reply, but do check future), screenshot of the exact parameters (not similar, exact) and sample gcode file (from that same parameter)
Hi Peter, I will have another go tomorrow, as far as I know I have only entered positive numbers, I have not use a minus before depth per pass or total depth, I've no idea where the double minus has come from, once I boot up the machine I will then run the wizard again and store the relevant gcode. Hopefully it will work.
Sounds like a good plan - I am unable to generate any double minus files in latest CONTROL, with any combination of positive values in the wizard.
in .354 I am seeing --0.5 in the framing pass sections (0.5 is the pass depth), waiting for update to download.... .355 is ok.
All working fine now guys, thank you for the update to sort this out. Double negatives, no one needs them in their lives!!
Got my Blackbox x32. Wrapping my head around this device, worked quite a bit with a Mach3 CNC router. Lots of documentation to review, but hope you all could help. Looking for a GCODE list or manual like you might for Mach (For example) Could anyone point me, or does it exist?
Github.com/gnea/grbl/wiki about halfway down. But just use any Grbl compatible CAM/Post. Easier. See docs.openbuilds.com > Software section
What's the deal with Return to Work Zero first lowering the Tool to Z5 and then dragging it to X0Z0 crashing it into literally anything being 5mm higher than the Stock Material along the way such as literally 99% of the Workholding Methods used by people using this Software? Is this some kind of Plot to drive up sales from broken Endmills or what's the thought process behind it?
That is not a Control problem it's the result of the program you used to generate the G-code. Make sure IT doesn't tell the machine to go down to Z5 before moving to X0Y0.
The 5 mm hits 0% of my work-holding methods. You could always write your own macro having it travel at a higher height.
