I've just built a Zen Toolworks CNC and am using the grblshield which works great with it, I've only tested with gctrl so far but was wondering what software is best used to send gcode to the cnc and possibly view toolpaths.
Best Workflow
grbl offers a ruby script in the /script directory to feed files to grbl. We (Synthetos) are also working on a console program to be released shortly that will work with both grbl and with TinyG, but it's not public yet. Neither generates tool path preview, and I've not explored what's out there for this - but there are a number of Gcode previewers out there if you hunt around. If you find a good one please post.
There is a Processing sketch that I've been using. It's available here:
https://github.com/damellis/gctrl
I made a little video about my workflow:
http://www.youtube.com/watch?v=mHmDhi2u2BE
Wow! This is amazing. Really nice work. How long have you been working on this? I hope you don't mind me putting this on the grblshield wiki projects page. - Alden
Yes, feel free to post it. I've been working on it mostly over weekends for the last month or so.
I probably would have bought a mini-g for this if it was available, but since it's not ready yet, I thought the GRBLshield would be fun to try. It's really neat, thanks for making it!
BTW, I'm going to admit that my message above shows that I'm an idiot and didn't carefully read the OP's message. He's already using gctrl and is looking for something better.
Thanks for the note. You may notice that grblshield is really just 3/4 of TinyG, minus the Xmega and USB. Coincidence? (not).
I'm inspired that you got the Rong-Fu working with it. I've got a Grizzly G0619 that I've been spooked to convert for some time now. If you don't mind, I'm curious about your conversion. Did you work from plans or do it on your own, and do you have a parts list or even some sources you recommend? (I can add any sources to the HacDC suppliers page - which is a nice resource: http://wiki.hacdc.org/index.php/Suppliers). I particular, what motors did you use, and did you find you got enough torque with your gearing?
We just got the first production TinyG boards a couple of days ago. They will go out on the site soon. Riley is putting the finishing touches (initial finishing touches; finishing initial touches?) on a really nice Python control program that drives both grbl and TinyG. It won't do a drawing preview (yet) but it does most everything else we've wanted. In the mean time, TinyG implements XON/XOFF protocol and I've worked with the author of CoolTerm (Roger Meier) to get CoolTerm working really well with it (native on Mac and PC). You can run TinyG from the command line and also stream files down to it. Beware - right now only the beta (v1.4x) works for streaming files - there was a really nasty bug that Roger fixed - but I'm not sure it's made it's way out to the general release of CoolTerm which I think is still 1.3x It bears repeating that while you can use CoolTerm to issues commands to grbl, you can't use it
to stream files (no XON.XOFF). Riley's program will work with either system.
As you see from the video, the GRBLshield will work with a fairly large mill, but it really is pushing it. While those aren't the largest motors that I could run with those driver chips, they're close. They're 1.7 amp motors from here:
http://www.phidgets.com/products.php?category=23&product_id=3308
As you see from the video, I'm trying to get extra torque by running at relatively high voltage (27V). If I were doing it again, I might go a little closer to the current limit with these:
http://www.phidgets.com/products.php?category=23&product_id=3307
I was worried about thermal load on the chips, but with the fans going it seems to work just fine.
I made all of the motor bracketry myself using the mill in manual mode. The x and y axes had tapped holes available that looked like they were meant for mounting a power feed, so I attached to those. Since I still wanted to use the handles, I machined extension shafts that bolted on to the pulleys and attached the handles to those.
The belts and pulleys are pretty standard 1/5" pitch timing belts. I used to build a lot of motion control equipment and had a bunch lying around, but you can get them from Stock Drive Products:
https://sdp-si.com/eStore/
The power supply came from Jameco.com. The fans and switches came from recycling obsolete equipment, and the case I mounted it all in is an old hard drive enclosure.
The down side of all of this is that it can't run very fast. The time lapse shots in the video of the mill cutting are sped up 20x. I suspect it would run a bit faster than that, but I was being a little conservative since I didn't want to ruin a piece with a motor stall. To get it to run faster, I'd have to use bigger, torquier motors, but that would have bigger torquier drivers and much higher cost.
I'm looking forward to seeing Riley's python control program. Gctrl works, but leaves a lot to be desired. I started writing one too, but it wasn't done in time for my video and I've put it on hold now that i got all of those brackets finished. My program does some nice things like estimating total program execution time, and stripping out comments from the g-code (since comments make g-code much easier to read, but GRBL chokes on a g-code command that includes a comment). You're welcome to have any of it (or my path plotting code ) if it is of any use.
Thanks for the info. I'm inspired to do my conversion. AFAIK the higher to voltages don't actually mean any more torque, but they do make the motors and chips run cooler as there is less time in switching - which is where the power is consumed (wasted). We have driven the drivers over 2.5A with fan cooling, but they are not happy about it (they get hot, but still work). Below 2.5 a is good - assuming you cool it well. We also have found some nice heatsinks for the little chips; they will go on the site soon as well.- Alden
The python script that I have been working on is available here: https://github.com/ril3y/ConsoleLoader
install git (google git download)
git clone https://github.com/ril3y/ConsoleLoader
once its done..
cd ConsoleLoader
python Consoleloader.py
Then follow the instructions on screen.. NOTE YOU NEED PYSERIAL.
However its not fully tested. I have been without power from Irene for about 4 days now. I am planning on testing some tonight. I do know that Windows will not work right now with it. Some issue with the pySerial module.
This code will be changing frequently. Your best bet is to do a git pull each day until its in a stable state. Open issues on the github page if found.
Thanks,
ril3y
I've decided to go with ReplicatorG which is primarily made for 3D printing but I'll be adding a new driver for the Zen Toolworks 7x7 (serial passthrough with geometry to match cutting platform) and creating a Skeinforge profile (for cutting not extrusion) too.
I'm just reading docs etc at the moment and should have xml for both ready before the weekend.
Creating a simple object in Google Sketchup (exporting to stl) and opening in ReplicatorG is simple enough task. Only problem is that the toolpath visualisation has been disabled for R25.
Hopefully I won't need anything else besides Sketchup and ReplicatorG (skeinforge).
Hi @HadleyRille, I have a similar Mill, and am thinking of converting it too. I'm wondering how you solved the issue of backlash (compensation) ? Can you throw some light on that ?
Yah I have been meaning to ask if you upgraded your lead screws? Alden and I have X3 mills.. (his is a bit higher end than mine.. DRO and digital rpm stuff). We are in the market to convert our mills too. However so much to do so little time!
I didn't modify the mill's leadscrews. The X and Y each have about .5mm backlash. I measured it very precisely and compensate for it in software. Specifically, it's in my g-code generator script, but it could be added to Riley's g-code streamer.
What I do is keep track of what direction the last movement was per axis, and if the next movement command is a direction reverse, take up the backlash before continuing.
I've been looking into adding backlash compensation into TinyG at the firmware level. At first glance it seems straightforward, but as you read more about it getting backlash compensation at speed and under load requires some real tricks to control jerk (You might not know that TinyG implements the "real" 3rd order jerk equations of motion to control tangential and centripetal jerk to set maxima for each axis. And if I can get through a few things this weekend we'll get the first 24 production units in the store early next week. FInally! But I digress.) So I'd like to say I'll get backlash compensation into TinyG relatively soon, I want to be cautious about this statement.
Great idea putting it into the firmware! Seems to me that it would be pretty straightforward for standard linear moves (G0 and G1). Just look for a direction change between movement commands and insert a backlash takeup step there.
If you have an arc with a direction change in it, break it into two arcs with a backlash takeup move in the middle.
It seems straightforward but I gather that backlash compensation can do some nasty things to line planning - or to the jerk on the machine if you don't control it. Take the case of a 360 degree circle in XY. There are points at the 4 quadrants where the direction in X or Y reverses. Backlash compensation would cause the nice, smooth planned circle to jump 0.5mm to the left, right, up or down. This looks to the line planner as a 90 degree turn - followed immediately by another 90 degree turn (but the machine shouldn't be loaded - because it's traveling through the slop region). The planner would like to slow down to a velocity that it can make the corner, then speed up momentarily through the correction line, then slow down again for the end of the correcting line. If it does this it will cause the tool to go though a dip in velocity at the quadrants, and will affect the smoothness of the cut. The alternative - not slowing down - is worse, as the tool will try to move "instantaneously", and cause a stepper to drop steps, or jerk the table and rough-up the cut accordingly. I imagine the right answer is going to be somewhere in between those two extremes, and may require some special detection or handling aside from normal line planning. Anyway, I plan to have a go at it, but I do think it will be challenging.
Back to grblShield Support or the forum archive.