I have migrated to LinuxCNC (EMC2) and i’m very happy. super stable even when running G-Code that is really really long. pausing for days at a time, etc. its a process and involved. not for the faint of heart. but well worth the effort. drops mic
This a very old thread, hopefully it won’t get lost in the internet dross. I’ve read the interaction between John and Sung. Both know way may more than I do, too bad it got so ‘chippy’.
Of the points made there is only one I’m interested in, that’s motion planning, as it relates to 3D carving. (I am a little curious about ‘buffer wipe’, just because I don’t know what it is as it relates to me.)
For some background, I’m using grbl 9i / chillepeppr, and I do a lot of 3d carving. I’ve been happy with the results, but am always trying to improve. Typical carving time is 4 - 6 hours (I’ve had to get around the line count limit on chillepeppr, though that is not a real problem). If I could improve times by 10 - 15% I would count as a win.
So, for the question. Between grbl and tinyg, I figure if I’m doing straight lines that neither one will be faster than the other. But, when doing raster on X or Y with Z changing on rapid basis (3D carving) is either one appreciably faster because of the planning algorithm?
There is 1 other option you may want to look at and that is Estlcam. It’s a free down load full functionality to test. Cam and Arduino controller. There is a thread on this forum about it. I have not tested everything but am happy so far. I will not use any cloud based cam controller software. Estlcam takes a different approach. The G code parsing is done on the PC and stepping, timing low level instructions sent to the arduino at a high baud rate. 59$ US if you like it.
Ken, the acceleration on TinyG is really nice but it’s hard to say if you’d see a 10 - 15% improvement because it kind of depends on your Gcode. On small moves acceleration may not be noticeable. On long straight moves acceleration is highly visible. For short moves, it depends on how much angle between each move if acceleration will come into play–small angles you’ll see acceleration, large angles less so. Your settings, especially your jerk and junction deviation settings, will all matter for how much acceleration you get and what you are ok pushing your machine with.
Gary, on the cloud software stuff, I know sometimes folks think their Gcode is actually getting sent up to the cloud. I just want to make sure people know that isn’t how it works. Once ChiliPeppr is loaded in your browser window, it acts exactly like desktop software. When you drag your Gcode in, it only stores it locally and in RAM. When you send it to your CNC controller it only sends locally (not via the cloud).
The downside I’ve heard folks say about cloud software is that if their Internet is down they can’t load it. I get that argument, but I think as the months and years go by that will become less of a worry for people who are concerned about cloud software today.
I mentor a 8 -12 students in a FIRST robotics program. We meet in a warehouse space and wifi is not available. We can connect in the class rooms when they are available. However it is a real battle with school IT to open the school net to out side web sources. I mentioned ESTLCAM because last week I presented it to some of our cad team. We have been hitting these kids hard on Solid Works. Up to this point all of the other cam software I have shown them got the deer in the head lights response. I had them watch the videos and then had them import their dxf files. Next thing I know they are clicking away and generated correct tool paths. I only helped them on tool settings. This is why I am hot on ESTLCAM. Yes, there may be better programs but ESTLCAM seems to work for my students. I have had no problem with any of the cuts we have done.
John, I do appreciate the response. Can’t say I’m surprised that it is, “it depends”, which is what I was expecting.
I get that a lot at work and I understand why. Your explanation cleared up some things for me.
You did confirm a suspicion of mine about the amount of improvement to be expected, 10-15% was fairly unreasonable, ok no problem. fwiw, my next upgrade is a real spindle, I’ll worry about electronics later. (assuming I don’t get bored with this hobby)
That being said, is there a simple way to increase the gcode line capacity of Chillipeppr? It seems it is limited to 256K, which is not a real problem for me, but a little more would be nice. (If this documented somewhere else, I apologize for spending your time)
Gary, I have not looked into this thoroughly, but I was under the impression you could host Chillipeppr locally. It may be more effort than it’s worth, I don’t know.
The line limit you are talking about, I think, is Serial Port JSON Server’s 200k line limit. SPJS has to preallocate some amount of RAM so a high enough number was picked that you could buffer up a ton of lines but it wasn’t so high that it would just chew up RAM pointlessly. ChiliPeppr by default sends 50 lines at a time. So the notion that you would buffer up all 200k is super unlikely. Some people who do HSM will buffer up a ton to ensure there’s no slow down in lines getting to the CNC controller.
Why is getting past 200k lines important to you if ChiliPeppr just keeps slowly sending lines to keep the buffer full? Are you trying to then shutdown the browser and still let the job run?
Hi…i am a new user here and as per my knowledge it just means you have to program your Due via the command line using Bossac. Actually, the new version of ChiliPeppr is about to have it’s
own Arduino programmer built-in so it’ll be even easier. The comment on the IDE simply means you can actually open the source code and then compile/upload.
@JohnLauer I know this thread is almost a year old but it’s still relevant for me. I am looking for a controller for my Openbuilds OX setup (1000x1000mm). I have used the XPR V3 board but I’m considering moving to TinyG.
What I’m hoping you can shed some light on is the difference between V8 and V9 hardware. It appears from the table Nathan linked to earlier in this thread that we have TinyG V8, TinyG G2 but I don’t see mention of V9 in the form factor of the V8 hardware. Is there a planned update for V8 to V9 hardware or is V9 hardware only available in the TinyG G2 (arudino due + Gshield) configuration?
Thanks
Good evening all,
Quite everything has been said.
As I need to choose/select the board which will drive my GShield bought two years ago (in order to replace my LinuxCNC parallel port controller) and still unused now, I was very interested in the exchanges of this thread.
At this time I’m a little bit reluctant about Chillipeppr. Too many pieces to be integrated.
UGS seems to be enough to me. However, if I have a good understanding there is now a “forked version” specific for gCore.
Is it always the situation or have mods been incorporated in the std version?
Out of the academic pro’s and con’s of grbl and gCore, I would like to point out the basic fact of the memory limits of grbl on Arduino Uno. I just compile the last version and… 
Blockquote
Build options changed, rebuilding all
Sketch uses 30562 bytes (94%) of program storage space. Maximum is 32256 bytes.
Global variables use 1633 bytes (79%) of dynamic memory, leaving 415 bytes for local variables. Maximum is 2048 bytes.
Low memory available, stability problems may occur.
Blockquote
It seems that this board is about to be saturated. Any view on the future will be appreciated.
Thank you
Marc