G-code Ripper : scales, rotates, splits and wraps G-code 2016-03-30

I know that this post has been here for a while, so I'm not sure if anyone is watching it. But, Is there any way to get this to work with the Openbuilds Control software and blackbox? When I use G-Code Ripper to create a file to probe the surface of an object and then run the g-code in the Control software, it bombs out on the lines with the hashtags (#). I am assuming that those lines are the ones that are writing back to the text file with the probe locations. The Ripper software only lists LinuxCNC, Mach3 and Mach4, but I am wondering if there is a way to make this work or is there another piece of software that will accomplish the same result of being able to carve on uneven surfaces?

 

You could try bCNC, I know that's written specifically to allow various types of probing, canned cycles, other more advanced stuff that grbl specifically avoids. If it can probe, it can presumably write to file. It'd be some minor messing about with python, but once it's installed it's cake. bCNC can do some transforms and probing natively, so I don't know if you'd technically need the Ripper software, probably depends on specifically what you're doing.

BlackBox is essentially an Arduino Uno and four stepper drivers in a box with some pre-wiring and convenient plug sockets (sounds flippant, but that's probably worth $30 more than they sell it for), so you can use it with any g-code sender that interfaces with grbl. CONTROL is designed to be clear, simple, and get people up and running quickly, but I don't know if it's designed to be enormously extensible. That would be a question for @Peter Van Der Walt.

 

Thanks Rob. I appreciate your help.

 

That was my first thought as well, but I think # actually denotes variables. This is clearly intended more as a LinuxCNC thing, but with a properly equipped g-code sender it could be done with grbl too.

 

yeah, I was just digging into it a little more. the software has to be able to prompt you for the location of the text file where it writes the differences in Z height, which is beyond the capabilities of Control. I'll check out BCNC. Thanks.

 

Well, not so much grbl-incompatible as CONTROL-incompatible. All of the advanced, non-motion control features are deliberately devolved to the sender software, and the design philosophy of that software dictates what features you get. CONTROL is clean, simple, beginner-friendly... Not attempting to be a Mach 3 alternative!

(I'm not explaining the design philosophy to the designer - just clarifying narration for anyone following along here)

 

Thanks for the replies. Would LinuxCNC be compatible with the blackbox? and I totally realize that is probably a Noob question that has been covered by your previous responses. Just pretend like i'm an idiot and spell it out for me Thanks in advance.

 

All a G-code sender has to do to replicate the probing routine is do a whole bunch of G38.2s and between each one, query G38.3 and write it to a file. That's it.

...Which, if you look up bCNC's AutoLevel routine, looks to be exactly what it does: vlachoudis/bCNC (never used the probing personally, looks handy for something though)



LinuxCNC is both the program and the custom Debian distro that includes the realtime kernel and all the other tools that you need. Normally, it makes the PC into the controller, where it generates all the steps in-software on the main CPU (hence the need for the realtime kernel, or else OS/program stuff would interrupt your machine) and outputs them to the stepper drivers and stuff via the parallel port. In some cases, eg. with Mesa boards like I'm using, the PC is more of a G-code sender (and maybe acceleration planner) and the step generation occurs within an FPGA on an I/O board, allowing you to use a slightly lower-spec machine. This can either be a PCI[e] card or an Ethernet board. You then get further daughterboards and breakout boards from there, which interface further with drivers, encoders, probes and limits, etc.

Grbl uses the host PC purely as a sender. The G-code sender software's only job is to keep the buffer as full as it can be of G-code blocks, while grbl offloads them, acceleration-plans them, then generates the steps all within the Arduino/ATMega328 device. However, that host PC can also query grbl in semi-realtime to acquire information back. The probing routine in the bCNC wiki above is an example of that.

 

Oh sure, what's then DONE with the probing routine is another matter. Fairly simple vector transforms, but certainly a good amount of it, plus, as you say, reliability and resiliency concerns. But the actual probing itself is trivial.

Edit: If it's really smart software, it would actually do vector calculus (maybe even vector field calculus, might be easier, if a little more complex) to approximate the "true" shape of the bed, and then apply that as a transform to the G-code, so it wouldn't actually need to be broken up at all, but I suspect most software would just break things up sufficiently to use the approximate linear interpolations. (It's been a good while since I did either of those things though. )

 

Just to close out my question, I ended up going with bCNC and have been very happy with the results. Once I figured out that I need to change the $10 value in the blackbox firmware to 3, I could see all of the info from the machine on the software. Still a bit of a learning curve, and it is not as intuitive as the CONTROL software, but there are plenty of tutorials to help with that. I was able to carve the "natural" wood that I was working with and put some pretty detailed v-carvings on there all with sharp edges and straight lines on the uneven surface. It turned out great! There are a lot more features that I want to get into, but I'm off to a good start. Thanks for everyone's replies.