Other than a genuine nano, i don't think i have ever seen a clone that wasn't a ch340.
Sent from my RS988 using Tapatalk
Thanks, I have a UNO but I like the size of the Nano.
Other than a genuine nano, i don't think i have ever seen a clone that wasn't a ch340.
Sent from my RS988 using Tapatalk
This one has the FTDI chip and it's about 3x the cost of other clones but still cheaper than genuine...https://smile.amazon.com/gp/product/B01983R7PK
If one is buying or about to buy new hardware to run GRBL it is worth knowing that there was effort afoot to get GRBL running on an ARM based board. Last i checked there was a discussion about which board to target. That is the official GRBL site. There is a related project call Machine Kit worth checking the status on.
I only mention ARM because long term, for GRBL to grow in capability, it needs a faster platform and more importantly more program space. While the GRBL developers have made progress on Arduino Mega in adding features it is pretty clear tge Arduino is maxed out. In any event a heads up for those that are looking to build a controller and that is it is worth checking the status of GRBL on ARM.
Grbl is running on ARM hardware now. Grbl-LPC
Have it controlling a co2 laser. Some of the I/O hasn’t been fully implemented yet, depends on which ARM board you have. You can configure and run 4 axis. I use the 4th with rotary. Step output rates about 200khz. Smoothieware on the same hardware is limited to about 90khz.
I find grbl-lpc as reliable as standard grbl and much better than smoothieware.
I think the cheapest ARM compatible board is the re-arm by panacutt for about $45. I use one and also a Cohesion3d mini. Unless you need higher step rates that standard grbl on atmega328 gives, no reason to use a ARM board. I’m pushing about 70khz step rates on the laser. The standard grbl/328 only does about 35khz.
I forgot standard grbl/328 only does 3 axis.
Last edited by jfong; 12-29-2017 at 02:40 PM.
That is very good news!
Thanks for mentioning the boards you use! With sonething under development it is always good to know what boards to look for.
High step rates can be useful for many designs. The real value i see in ARM is the potential for more features and better error handling.Unless you need higher step rates that standard grbl on atmega328 gives, no reason to use a ARM board. I’m pushing about 70khz step rates on the laser. The standard grbl/328 only does about 35khz.
I forgot standard grbl/328 only does 3 axis.
Wizard,109jb,gharley,
On the subject of GRBL, have you seen?
GrblGru: Free CAM and 3D-Simulation for mills and lathes
htttp://www.cnczone.com/forums/uncategorized-cam-discussion/311876-cnc-forum.html
It looked interesting to me! but have not seen mention of GrblGru in any of your posts.
comments appreciated!
W. (Ted) Smith
I'm not one of those guys, but I have seen and attempted to use the program. While it clearly is admirable that the developer just keeps pounding away at adding interesting features, I can not find joy in the GUI ergonomics (layout). The massive use of color gives me shivers and thoughts back to the fast paced insertion of buttons and bells as they were being added to Mach3 with all the look and feel of those thick Crayola crayons we let kindergärtner’s experience early life with. That alone makes me less interested in spending the time to bother to understand it, or seek to find whether there exists a flow of operations or not.
Dont allow me to sway someone from using it, because if everything claimed about it is true, it seems to have a lot of potential features.
Some of my opinion surrounds thoughts on what I need to get a job done verses having too much fluff. I believe most GRBL interfaces have attempted to keep the underlying world up front and center when frankly, users only care if they are required to troubleshoot.
Again, for my GRBL experiences, I have pretty much settled on the smooth, clear ergonomics of CANDLE (https://github.com/Denvi/Candle). For me, a control can be just the control and not be an illustration of the machine itself. I'm capable of visualizing a tool path by itself in a dialog box.
Sadly, it appears no longer worked on. Shame because it would not take much to really be a perfect interface because less is really more, and simple ergonomics will always win my vote.
But congrats to the GRBLGru developer because he is active in the forums and always adding new features and functions. I just don't have time to figure it out.
Chris L
Chris L,
Thanks for your Input, it was very informative!!
The only reason I did not include you was you had not posted on Page 4.
W (Ted) Smith
I tend to agree grblgru looks like it has potential but the UI is currently too noisy and hard to follow. One obvious change I'd like to see would be, instead of having several different sized drills and end-mills, just have one of each and let the size be specified in the properties. Another thought, since the app is free anyway why not make it open source so the community can work on it.
I am also using Candle, which I like a lot and CamBam (CamBam CNC Software) which is not free but the trial usage is very generous and one might decide it's worth $150 after using it awhile. True that Candle hasn't seen much love lately but it *is* open source so a motivate developer could pick up the ball.
I tend to like simple intuitive interfaces, so although I downloaded GrbGru, I pretty much didn't like it right away. I really find no use for the graphical representation of the machine itself and when trying to get a feel for it I couldn't figure out how to adjust things like jog speeds immediately. It probably works fine if you take the time to learn it, but I didn't. My background in CNC goes back to the 1980's when I was running VMC's about 50-60 hours per week. The machines back then had simple text based interfaces, and no graphics whatsoever. You had to do it that way back then because there were no other options. When I first started the machines still used reel to reel paper tape to load g-code programs. Since I was accustomed to that degree of antiquity, I don't really care about lots of bells and whistles. Just a basic interface works for me. I started the Grbl road using UGS and Candle, but since Grbl doesn't support canned cycles, I wound up writing my own interface to include canned cycles. Bottom line, GrblGru may be fine, but it wasn't my cup of tea, so I don't have any real experience with it to pass any kind of judgement.
I just heard about that one in this post so obviously cant comment. Also recently had a stolen laptop so that has be way behind.
In any event in my simple mind your CAM solution should not be your GCode sending solution.
However there is a fine line here, id love to see more conversational programming capabilities in a machine interface program. The ability to completely skip the CAD / CAM duo to solve common one off machining problems would be very nice if it avoids a bunch of hand written code. Solutions that allow you to center the spindke over a point and pocket a hole or surface an area quickly would be very usable.
>> In any event in my simple mind your CAM solution should not be your GCode sending solution.
I agree with this statement to a point, especially in that at least the main or home portion of the interface should be exactly the machine control. The place to initiate the machine, the place to home and set the machine DRO, the place to Jog and set program zero, and the place to load and cycle start or feed hold jobs.
The world of integrated tool path creation can easily rely on secondary tabs as well as other things we often need to change when it comes to the control settings for a particular machine set up.
>>However there is a fine line here, id love to see more conversational programming capabilities in a machine interface program.
I feel that most of the controls we talk about here already have addressed the conversational dialogs in their programs, but if anything, did not perhaps carry it far enough or continue with adding more fruits and veggies.
When you speak of a "Fine Line" though, I think Flashcut has figured out combining the control world with quick tool path creation in their newest Plasma versions especially that deal with pipe cutting and joints. I believe when it comes to melting the worlds of Cad and Cam into a Machine Control, no one seems to have done what they have done. If you have the time, seek out some of the HVAC / Tubing videos on youtube. I was really surprised at the capabilities and time savings for those in those markets.
It would appear that grblgru is headed in somewhat a similar direction, with the developer creating shortcuts for things he needs to accomplish. I've only noticed that those type of things might not be mainstream or traditional. The real stumbling block however was that a user can not immediately see the path to take without a lot of study. Really good interfaces tend to automatically drive the user in directions he needs to go without them even knowing.
Chris L
For Arduino grbl you can get fusion 360 for free and that is for cad and cam then use universal g code sender to send it to the machine. That method works great for me.
Sent from my iPhone using Tapatalk
How do you get Fusion 360 for free? Are you a student?
It's free for everybody, unless you are a business making more than $100,000/year.
After the trial period expires, you'll be given the option to sign up for a hobbyist license.
Gerry
UCCNC 2017 Screenset
[URL]http://www.thecncwoodworker.com/2017.html[/URL]
Mach3 2010 Screenset
[URL]http://www.thecncwoodworker.com/2010.html[/URL]
JointCAM - CNC Dovetails & Box Joints
[URL]http://www.g-forcecnc.com/jointcam.html[/URL]
(Note: The opinions expressed in this post are my own and are not necessarily those of CNCzone and its management)
i'm late in this, but i think GRBL is prevalent today and will be more so due to a couple of factors:
1) large availability of low cost micro-controllers (not just AVR)
e.g. stm32f103 'blue pill' board cost around $2 runs at 72 mhz usb built-in has an 'arduino compatible' core for it lots of on chip peripherals e.g. 2 x 1 msps ADC, 7 timers, 2xspi, i2c, uart etc all on board
https://www.ebay.com/sch/i.html?_fro...2f103&_sacat=0
https://www.st.com/content/st_com/en...m32f103cb.html
usb is a big win over parallel ports as pcs today don't even ship with parallel ports
and not only that there are various others that has ble or wifi built in (e.g. esp8266, esp32) effectively allowing wireless control
2) commodity 'toy' cnc
next apparently small desktop cnc are becoming somewhat a fad and mass produced on scale, many kits sells for < $200
https://www.ebay.com/sch/i.html?_fro...+3018&_sacat=0
that may be a main reason of the spread of GRBL based ones as apparently pretty much all the manufacturers of the 'toy' cnc ship with GRBL as the firmware
i'd think GRBL doesn't address the more varied real cnc scenarios. but i'd think micro controller based implementations would only become more pervasive due to the widespread commoditized use.
the micro controllers e.g. stm32f103 with usb built-in are replacing what is conventionally the serial port and parallel ports
and this change is across the board which means we are in the 'age' of customized usb peripherals in which you can re-define its role by simply uploading a different firmware