CamBam
News:
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
April 03, 2020, 23:47:26 pm


Login with username, password and session length


Pages: [1] 2
  Print  
Author Topic: A question to GRBL users  (Read 1982 times)
Dragonfly
CNC Jedi
*****
Offline Offline

Posts: 2268



View Profile
« on: August 24, 2019, 20:57:31 pm »

I started playing with a fork of GRBL 1.1 but on Arduino Mega (ATMega 2560) with a 4-th axis added. My intention is to introduce some changes to make a suitable controller for a specific machine - automatic plasma cutter for tubes (round, square, rectangular). A friend of mine has built the cutter and uses a Chinese (quite buggy) controller currently.

After compiling and uploading the firmware it works as expected, doing synchronous moves with 4 axes. The 4-th I've set as a rotational one (setting actual steps per degree).
This all was done manually from a serial terminal. But I need a sender, a good 4 axis sender. What I found is, well, disappointing. It seems that the developers pay more attention to incorporating CAM features into a sender rather than paying attention to actual machining. GRBL was initially developed for 3D printers and some of its built in functions are made with 3D printing in mind. So are the senders.

The only one sender which supports 4 axis I found is bCNC. Written in Python (but 2.7 which is almost obsolete). And while under Linux it behaves more or less as it should I had no success trying to run it under Windows (both XP (32 bit) and 7 (64 bit)). The GUI starts (after some fiddling) but there is a problem with communication.

So,
my question is what senders are you using to control a GRBL machine.
Logged
dh42
Administrator
CNC Jedi
*****
Online Online

Posts: 5848



View Profile WWW
« Reply #1 on: August 24, 2019, 21:09:22 pm »

Hello

Did you try the GRBL machin plugin ? ... I don't know if it is working with 4 axis ... (it is not working on linux)

http://www.atelier-des-fougeres.fr/Cambam/Aide/Plugins/GRBLmachine.html

++
David
Logged
onekk
CNC Jedi
*****
Offline Offline

Posts: 502


View Profile
« Reply #2 on: August 26, 2019, 01:59:34 am »

I use bCNC, but with Linux running on a Olimex Board (similar in concept to a Raspberry Pi).

Many people run it on a Raspberry Pi and there are also some board that mount on top of a Raspberry Pi making a sort of  all in One controller.

I've heard in my readings that development of Grbl are in progress also for some 32 bit controllers, similar to those used in 3d printing.

Regards

Carlo D.

Logged

Carlo D. (onekk)

eShapeoko #343 750x1000 mm + GRBL + bCNC + CamBam
EddyCurrent
CNC Jedi
*****
Offline Offline

Posts: 4228



View Profile
« Reply #3 on: August 26, 2019, 09:25:03 am »

David,

It looks to me like a dedicated GRBL section in the forum might be a good idea
Logged

Made in England
Dragonfly
CNC Jedi
*****
Offline Offline

Posts: 2268



View Profile
« Reply #4 on: August 26, 2019, 09:59:15 am »

I use bCNC, but with Linux running on a Olimex Board (similar in concept to a Raspberry Pi).
...........
Regards

Carlo D.
There is a boom in the availability of single chip computers with  32 bit ARM processors. And I've seen a few ports of GRBL to such platforms. There is one which is directly pin  and geometry compatible with "Nano". But with several times higher processing speed. Here is a link, but it is in Russian:
http://robomechs.com/grbl-1-1-smt32f103c8t6/

I am sticking for now with the "Mega 2560" because I have to dig into the source code and learn how it all works. Because GRBL was developed for 3D prining (and laser engraving too) some of it's functions are hard coded to the way a 3D printer or a laser engraver work. For example, homing does not actually need 3 separate inputs from end switches. A single input is enough if the homing is done sequentially one axis a time. Probing also needs more flexibility for CNC milling. Because it works by removing material instead of adding. Tool change and peck drilling also need to be supported.
What I see as a weak point IMHO with the senders I reviewed is that the developers throw a larger part of their effort to include hi-res tool path visualization, real time tool movement animation  and some CAM functionality directly into the sender program. I think this is an overkill. As long as they incorporate a G-code interpreter of their own for visualization it would be much better to use it for G-code conditioning and real time handling of canned cycles and tool changes. Like a post build processor. Again, in my personal opinion.
BTW, Olimex is a Bulgarian company Smiley

David,

It looks to me like a dedicated GRBL section in the forum might be a good idea
Sounds tempting but I think a separate section will be too much. It's a CamBam forum first of all.
« Last Edit: August 26, 2019, 10:02:32 am by Dragonfly » Logged
Dragonfly
CNC Jedi
*****
Offline Offline

Posts: 2268



View Profile
« Reply #5 on: August 26, 2019, 10:17:12 am »

On the topic of single board computers.
It appears that this unique 5 axis portable mill developed by crowdfunding is using a Beagle Bone Black board. And is controlled as far as I understand by a port of Linux CNC
https://beagleboard.org/blog/2014-08-06-project-spotlight-pocket-nc

And a video of the machine itself.
I think stevehuckss396 will be delighted to watch Smiley
https://youtu.be/UQutUdOg3gI
Logged
alex_holden
CNC Ewok
*
Offline Offline

Posts: 29


View Profile
« Reply #6 on: August 26, 2019, 12:13:29 pm »

I wrote my own sender for some of the reasons you state; my main aims were that it be stable and very fast/responsive even on low end hardware (I currently run it on a Raspberry Pi 3 but it also works on Mac - no plans to port it to Windows). It also handles peck drilling codes, though I haven't yet got around to adding tool change offset support. It doesn't do visualisation or CAM, or more than three axes. I had originally intended to make it open source but I'm so busy in my day job that I haven't had the time to clean it up or write documentation suitable for public release.

I'm not sure it's true that grbl was developed for 3D printers; I thought it initially targeted low end CNC routers, and people later forked it so they could add extra features necessary for controlling 3D printers while the mainline grbl stuck to routers/mills/lasers/plasmas etc.
Logged
Dragonfly
CNC Jedi
*****
Offline Offline

Posts: 2268



View Profile
« Reply #7 on: August 26, 2019, 15:27:49 pm »

Quote
It also handles peck drilling codes, though I haven't yet got around to adding tool change offset support.
Tool length offset is useful only with automatic toolchangers where every tool in the magazine has a predefined length. With manual tool changing it's enough to:
- lift to clearance plane
- stop the spindle
- remember current position
and let the user :
- replace the tool
- jog to a spot where he wants to touch a setting plate or block, or an electronic touch sensor
- enter the new tool tip height
- signal back he is ready.
Control software then:
- lifts to clearance
- moves to the position where it had stopped
- starts the spindle and waits it reaches the set rpm
- continues with the next portion of G-code.
On some machines a tool setting block or sensor may be mounted at a spot with fixed coordinates. In this case movement should be done in real machine coordinate space with G53. Provided the machine is properly homed and travel lengths set correct.
I don't have one. In the real world with Mach3, after replacing the tool, I jog to a suitable spot, lower the tool manually to few millimeters above stock (or bottom of stock), place a touching conductive plate with known thickness under the tool and connect the other wire to the spindle shaft by means of a large crocodile clip. Then do the tool touching and setting a new work zero for the tool.
Ability to interpret canned cycles (peck drilling in particular) is very useful when making MOPs with CamBam.
----------
As a side note, even if Mach3 provides a way for manual tool changing I try to avoid it when possible by grouping MOPs with one and the same tool. And often do separate parts for each tool change. At the end - "MOPs (and parts) are free" is the non-official motto of CamBam users Smiley
« Last Edit: August 26, 2019, 15:34:28 pm by Dragonfly » Logged
alex_holden
CNC Ewok
*
Offline Offline

Posts: 29


View Profile
« Reply #8 on: August 26, 2019, 16:36:23 pm »

My current workflow is similar to that, except I use a piece of cigarette paper and jog down until it is pinched between the tool and the part. My mill has a manual quickchange tool holder system so a saved tool offset table would save a bit of time per tool change and reduce the chance of error. I haven't yet figured out a good system for measuring the tool length offsets.
Logged
Garyhlucas
CNC Jedi
*****
Offline Offline

Posts: 1344


View Profile
« Reply #9 on: August 26, 2019, 18:02:30 pm »

I don’t use anything thin, too easy to break a tool or damage a part by jogging too big a step or wrong direction. I use my 3/8” edge finder and roll it under the tool while jogging, and I have the Z offset set to 3/8 in Mach 3.

When using my mill spindle that goes down to 500 rpm I pick up X & Y using an edge finder. On the router at 8000 rpm minimum it would probably fly apart.

So I do it by laying the edge finder shaft between the tool and the part and jog away until it drops. You have to rotate the tool so you actually get the flute edge.  The spindle is then tool Radius plus 3/8” from edge.
Logged

Gary H. Lucas

Have you read my blog?
 http://a-little-business.blogspot.com/
Dragonfly
CNC Jedi
*****
Offline Offline

Posts: 2268



View Profile
« Reply #10 on: August 26, 2019, 19:15:51 pm »

My current workflow is similar to that, except I use a piece of cigarette paper and jog down until it is pinched between the tool and the part. My mill has a manual quickchange tool holder system so a saved tool offset table would save a bit of time per tool change and reduce the chance of error. I haven't yet figured out a good system for measuring the tool length offsets.
A quick change system, even if manual, if based on cone tail tool holders makes a tool offset once measured and set a constant value. Something which is not achievable by manual untightening the chuck, inserting the tool into the collet and tighten again. Even if the tool has a stop ring. The collet action always drives it a bit into the chuck cone. I don't have any experience with automatic tool changing, nor with quick change systems. But sometimes I use a steel block on an insulating pad fixed to the table and one wire of the probe input connected to it. Before the first operation I zero the tool to stock surface. Then move it over the block and do a touch probe cycle without  zeroing the Z work height. I write down the difference with its sign. On next tool change I touch the block with the new tool and enter the written down value. And I get the new tool zeroed  no matter its current length out of the chuck.

I don’t use anything thin ....
Garry,
I have learnt a lot of tricks from you and use them when direct probe cannot be done Smiley  Letting the piece fall down the edge is a new one. Thanks!
Logged
Dragonfly
CNC Jedi
*****
Offline Offline

Posts: 2268



View Profile
« Reply #11 on: August 29, 2019, 13:36:57 pm »

I wrote my own sender for some of the reasons you state;  ...
What language and what development environment it is based on?
Logged
Garyhlucas
CNC Jedi
*****
Offline Offline

Posts: 1344


View Profile
« Reply #12 on: August 29, 2019, 13:54:57 pm »

Fly,
I am building a CNC router for the high school FIRST robotics and likely will need to use a touch pad probing for part pickup and tool length because the machine will be fully enclosed and shuts off if the door opens. So I am going to need other techniques to avoid changing out the tool for a probe.

This just gave me an idea. Maybe insulate the Bed of the router from the frame so a clamped part can complete a circuit through the tool to ground!
Logged

Gary H. Lucas

Have you read my blog?
 http://a-little-business.blogspot.com/
Dragonfly
CNC Jedi
*****
Offline Offline

Posts: 2268



View Profile
« Reply #13 on: August 29, 2019, 15:48:36 pm »

Or the spindle. On the previous iteration of my router the spindle motor was held in place on two aluminum brackets with slotted ring shape and tightening screws. And I used POM bushes between them and the motor. So I had this kind of isolation but nevertheless had to use a large crocodile clip clamped on the motor shaft to do the tool touching.

Better IMHO is to use an electronic touch pad mounted at fixed coordinates in the travel area. After initial zeroing of one tool all tool length differences can be calculated in the software after touching.
Something like this
Logged
alex_holden
CNC Ewok
*
Offline Offline

Posts: 29


View Profile
« Reply #14 on: August 29, 2019, 17:40:16 pm »

I wrote my own sender for some of the reasons you state;  ...
What language and what development environment it is based on?

Multithreaded C, with the GUI part using the Gtk+2 widget set. It also incorporates a Javascript interpreter running a script that does a bit of processing on the G-code as it passes through the program - that's where the canned cycle magic happens. It's also possible to write macro functions in Javascript and call them from a button press or the MDI terminal.
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 5.102 seconds with 18 queries.

Copyright © 2018 HexRay Ltd. | Sitemap