As the title says, since this is now considered PRO how about adding TinyG support.
whats the advantages on TinyG over GRBL?
That depends on your point of view. There is a great article that explains the differences in detail (see link). I am mostly drawn to tinyG because it has smoother acceleration and deceleration than GRBL controllers.
Link to article: https://github.com/synthetos/TinyG/wiki/What-is-TinyG
[Third Order Constant Jerk Profiles]
TinyG runs 3rd order, constant jerk acceleration profiles, grbl runs 2nd order constant acceleration profiles. What does this mean? In grbl the velocity profile during acceleration and deceleration looks like a pure trapezoid in time. For example the move starts at zero velocity, then velocity ramps in a straight line to the target velocity, then decelerates in a straight line back to zero. In TinyG the velocity profile is an S curve that ramps to the target velocity during acceleration and in reverse during the deceleration phase. The means that you can run to motors harder in transition and hence operate at faster accelerations and decelerations. It also means there are fewer machine resonances excited (that cause chatter and other problems) as the jerk term is controlled. Jerk is a measure of the impact a machine is hit with during a velocity change. See: TinyG driving an Ultimaker and driving a Shapeoko. The machines are not fastened to the table and don’t jump around because of the jerk control.
@RobertMitchell What are the differences in gCode that would prevent one with a TinyG controller from generating gCode with Easel? Obviously, if you add a rotational axis you’d have problems with GRBL, but Easel’s not going there anyway.
I have used both the TinyG and GRBL controller boards.
The G Code is the same for both as TinyG is based on GRBL. So generating the G Code is the same. (I was using the same post processer for both)
The main difference is in the format the sending software uses to talk to the controller to send that GCode.
I was aware of that. My point to @RobertMitchell is why would Easel Pro need to support sending the gCode to a TinyG controller to make it worth it? I can generate gCode with a lot of very expensive software, but there is almost always a different piece of software to send that gCode. If the CAD and CAM features of Easel Pro are worth it, you can always use the sender UI of your choice.
@NeilFerreri1 You are correct. I can create and export Gcode from EASEL to another sender connected to tinyG. This is essentially how I do it today with Chilipeppr. I do this out of necessity and would rather have an integrated workflow and not worry about the extra steps involved if I could avoid it. My opening statement was more of a value proposition statement. The extra costs of upgrading to PRO is not worth it as it is. Until more features become available I am not likely to be a PRO user. The one capability which could save me time is integrating tinyG support in EASEL due to extra effort involved in setup and troubleshooting (when needed) as I workflow through the various other tools.
I am a novice at all this bur for me I had to switch from GRBL to TinyG to solve a power issue after upgrading my stock Shapeoko 2 from 500mm to 1000mm and adding in NEMA 23 motors for the x and dual y gantrys. I think that due to my sharing the stepper driver with y the issue was overheating the GRBL board constantly. I added heat sinks, cooling fan, you name it but the board would simply overheat and shut down. I already had a Tinyg that I had from way back but didn’t get into using Chillipeppr so just had it shelved. But changing to it solved my GRBL overheating issue as each axis has its own stepper now and things move more smoothly. Plus I like the idea of putting homing and limit switches back on if I choose to (but haven’t seen the need for now).
I do have the proper power supplies on the board and spindle (24 volt and 48 volt respectively). I just feel like TinyG support would give users better options for choices when upgrading, and/or maintaining their machines. I know that the Shapeoko 1 and 2 have become all but obsolete (you can only obtain partial build items should you want to totally build or create a replacement) so all the focus is on the new machines. But I do this as a hobbyist not a commercial user, so I can’t just throw down on a new machine when I want to go to try something new. That isn’t a complaint. I am still really enjoying the SO2 and plan to for the foreseeable future. But I hope that the hobbyist is not forgotten in all the focus on commercial gain.
So here we are in 2018, and this post was back in the fall of 2017, and not a word about a way to keep that “inventable” / “tinker” spirit alive with some options for expanding the use of the machine beyond its basic inception, and even if one went with the more commercially focused Easel PRO, that doesn’t get you much. So in may case, I couldn’t use PRO anyway, because my SO2 can’t use GRBL without overheating, so buying the PRO isn’t a good option. If I moved to a VCarve that might solve my problem, but I’d feel better understanding why my GRBL overheats, or what the best GRBL alternative that would be compatible would be that would give me independent stepper drivers to maintain optimal board and stepper control. Anyway, that’s my take on it from my perspective.
More of an operational standpoint than one of TinyG over GRBL because the gcode works the same with both in most instance, but what a long way around to the end result if one just wanted to do as Robert Mitchell points out and have a smoother workflow when using Easel. I use Fusion 360 for some work, but for simple stuff, Easel is just faster and fun.
There are lot’s of people running Arduino/gShield grbl setups with NEMA 23s and no overheating problems. Are you using the gShield, or some other driver?
I am using gshield.
If you are running gShield with the NEMA 23 motors from Inventables and getting over heating of the driver chips then you have the current limits set too high, or you have a faulty board.