Grbl 1.1
Victorio Galindo
The first thing to do is to read through the material at the following link. You are going to need to understand that material in order to set up your version of grbl to run on your machine with Easel.
Hi I am completely new to all of this. I have been gifted (or cursed) a 3018pro cnc which has grbl 1.1 controller?. I have played around with easel but i need to configure it to connect to the machine. I obviously need plenty of help but in small steps. long strings of techno jargon for someone in their
70s would be intimidating at present .I just need the simplest of instruction till i get started. look on this as your quest to get me carving regards Colin the codger
I just upgraded grbl to 1.1f from 1.1e on my Eleksmaker A3. It was working ok on earlier grbl but now the Y axis is reversed. I chose lower left when I selected the machine but in the move window if I press right arrow it goes right as it should but pressing the up arrow makes it come towards me. If I do $$ in console this is what I get.
Hi. I have tried everything to get grbl to load into the zip file on IDE even tried a new master zip of grbl but it just goes to examples when i click on grbl then onto grbl upload. But then says no files.
There is an M9 command later in the code stream which would turn off M7, but if M9 is issued without a prior M7 that is not a problem.
It could be that your controller has M8 use enabled (normally flood control output when milling). If so, in the future, if you need such a digital output control for THC Z Anti-Dive enabling or arming, then you could change M7 to M8.
I just uploaded a new version of the .scpost -plasma-w-thc-torch-touchoff-and-rotary/7342/1
I forgot to add S1000 to the M3 torch trigger/fire command to cover the case of using grbl on Arduino Uno.
blouchip has been an excellent resource for me and has gone above and beyond to help me out. His knowledge is far beyond mine and will steer you in the right direction. His most recent post processor worked out for me. Thanks again Lou!
Currently I am setup for Z IHS and about to start building THC voltage divider and use some existing software. Probably used relays to flip back and forth from FluidCNC Z control to Arduino THC depending on ARC start.
I'm trying to switch to using either Universal Gcode Sender or PicSender to my Grbl based X-Carve CNC. I have previously been using the Easel customized Post Processor and Easel as my Gcode sender, but I'd like to move on to something more advanced.
I downloaded the generic Grbl Post Processor from the AutoDesk HSM Post Processor library and the gcode is generates is clearly incorrect. For starters the % line at the beginning and end of the file is not supported by Grbl, nor is the M06 command, and the M30 at the end of the file should really be a M05. It appears that UGS filters out some of this, but PicSender takes a more pure approach and does not.
So I'm wondering why the HSM supplied Post Processor for Grbl can be in a current state of "couldn't possibly work" and since I know that there are lots of people who are using Fusion 360 with Grbl and either UGS or PicSender, where are they getting a Post Processor that does work?
But after doing some more research it seems that for example the M06 command has never been correct for any version of Grbl, it's just that for older version of Grbl (0.8) it was ignored and no error thrown, but still wrong. Newer versions of Grbl now send an error for an unsupported command, but some Gcode senders (like UGS apparently) have been modified to ignore invalid Gcode errors, but that's just a hack.
So I'm back to why after all this time the Grbl post processor hasn't been corrected to not generated invalid Grbl codes ('%', 'M06', 'M30') in the first place and not depend on the Gcode sender to ignore the error? It doesn't seem very difficult to change, I'm just trying to figure out how I could possibly be the first person requesting it.
There are no versions of the Grbl firmware (excluding possibly some derived forks) that actually support Tool Change and therefore the M06 code, yet the Grbl post processor generates them - this is incorrect and should be removed. The only reason this has ever worked for anyone is that some of the popular Gcode senders have been modified to ignore the error the bad code causes.
These incorrect codes have been causing problems for lots of users with various combinations of Grbl and Gcode senders and should be a pretty brainless fix, but it would be best if the corrected code came from the Autodesk library so ongoing updates won't need to be patched manually by end users. I don't see any downside to these invalid codes being removed.
@sprior913 can you give examples of other people who are asking for these same things to be fixed? The Post Team certainly is NOT opposed to making improvements so the general population has a solid working post.
The "%" character and the "M6" command are both considered illegal commands by GRBL, not PicSender. PicSender is only reporting the errors that GRBL sends to it when illegal characters/commands are encountered in a gcode file.
An "M30" signals the end of file sending; it does not turn off the spindle. An "M5" command turns off the spindle. It is (should be) a function of the gcode generating program (post processor) to add an "M5" at the end of the file to turn off the spindle/laser.
To test the on/off functions of grbl in the PicSender demo to verify you have the relay wiring correct, you can use the "M03" button to toggle a spindle relay on and off. When off the button reads "M03" and when on the button reads "M05".
I should also mention that all the versions of Universal Gcode Sender I've seen have a built in filter to remove M30 codes (Grbl only recently started supporting that at all), but does not have a M6 filter in place.
I've also seen forum posts where end users have expressed frustration that they never got Fusion 360 working with PicSender (PicSender does not attempt to correct the Gcode or ignore Grbl warnings - they're purists).
What would the desired behavior be when it reaches a tool change? Thus far, I was under the impression that people were posting out single tools, as there was no mechanism for changing tools and starting again.
I am aware that some gcode senders handle this themselves - Carbide Create apparently intercepts the tool change and prompts the user to change the tool then Z probes it and resumes the carve, but the actual tool change gcode never makes it to Grbl where it would throw an error.
But Carbide Create has its own post processor anyway so I would argue that the "pure" Grbl/Grbl post processor should not generate the tool change codes since Grbl doesn't support them, then a derived post processor specific to an environment like Carbide Create would be free to add support for it since it's going to be there Gcode sender which actually handles it anyway.
If you want to take a slightly safer approach I'd say you can leave the option for the Grbl processor to generate the tool change codes, but by default have it disabled. The only reason I suggest this is that it provides the code as an example for downstream providers (like Carbide Create) to enable it by default since it's supported in their environments.
Here is the explanation in the bCNC wiki which covers how they attempt to translate the tool change in the Gcode sender (and also note that the option to forward it to Grbl will always result in an error).
I just tested the generated gcode from the corrected grbl.cps that I attached here. It now works out of the box for both Universal Gcode Sender and PicSender - something the shipping version does not do.
Thanks for the poke on this. The people I've needed to involve in these changes have been on vacations, so things are starting to settle down. I'll send the info you have provided into them and see what they think. Thanks for bringing all these to our attention!
I look forward to it. In the meantime I noticed that the fork of the grbl post processor that Inventables uses added a nice feature to put the stock block dimensions in a comment. That's actually a really nice feature to have. They still do have the issues I opened this issue for, so I created a version of the code which fixes the bad codes and adds the new comment. I've attached it for consideration.
As of last night I too was having the same issues. By accident I deleted lines 12 and up and ran the program through my universal g code sender with GRBL and it worked. I used to have no problems with the post process, but that was last year. Now with the new version the post process does not work with my UGS. Something changed. Here are some screen shots.
I'm still using the version of the post processor I modified and attached above. The new version of the post processor released by Autodesk has an option to disable the tool change code, but it defaults to including it.
I have started in safe mode.
One clue is that in the video instructions in the grbl settings was to remove "$$" under "Hello Command" - but... when I make it blank like the video and save, it resorts to the factory setting of "$$" - Could this be the issue?
From the little info you included, it looks like the serial device returns info, but obviously not what octoprint expects to get back, so definitely a question that needs answers from the sand table forum, this is not something anyone here will be familiar with.
I am finally asking for help as I have almost no hair left. On my Ramps 3d printer running marlin and on my xvico 3d printer with its own custom firmware before it starts a print it will search for all the endstops then begin the print. On my 3018 cnc running grbl i am trying to replicate this.
G28 will just home to your 0 xyz or it s last known 0 xyz. So after a power cycle where ever you machine is, is where it thinks 0 is. Is there a G-code command for seek endstop? and behave like hG28 with a debounce on finding the endstop?
When you start your machine does it remember its xyz. When i use Laser GRBL and open it my coordinates will always be 0 for xyz. So if I use $23=0 or any combination the machine does not move. If I jog it forward 10 steps then use $23=0 it returns to what it thinks is home. What I am after is there a grbl or g code that will make the machine travel in a direction until it hits and endstop and then set that direction coordinate to 0. If that is what $23=0 is meant to do then my GRBL is buggered.
687b7eae2f