Grbl Panel Control

I’m having the same problem.

 

I do not believe there is a way to separate commands. This seems to be a limitation of GRBL Panel.

 

I know that GRBL settings are stored on CNC XPro board. When I run GRBL Panel, I have to get GRBL settings from the board. Is it possible to export the GRBL settings to a file so that I can load it into another computer running another CNC router?

 

Hey guys!

I'm just getting started with talking to my xpro v4 board, and I had a couple initial issues that I didn't see discussed here. So I've solved those problems, and thought I would share so that others feeling my pain can get a short cut to the solution.

The first problem I had was the baud rate for the com port. I had to set it in two places on my Windows 10 machine. In the control panel find your "device manager" and in there go to the Ports (COM & LPT) and find your machine's entry. If you watch the screen when you plug and unplug, you will see the entry populate to confirm you have the right one. Double click on that entry, and if you are like me, the default was set to 9600 baud. That could easily be a "me only" thing because 9600 baud is a default rate I frequently use when configuring a Cisco over a serial cable,... In any event you will want to change that to 115200. Make a mental note of which com port this was, in case you have multiple com ports like I do. That way you connect to the correct port. In grbl panel, set the port and the rate and hit connect. This is simple stuff, but not everyone has experience with serial ports.

The second problem I had was the settings screen was only populated with one setting, $0. I was expecting to see the block of settings I see in all of the examples. I noticed the "Last Grbl Param" was $0. I wondered if I gave this $132 if it would show them all... And it worked, after setting it to a last param of $132, and pressing the Get Grbl Settings button, I saw the list populate with the full set of settings.

I was disappointed that I didn't find a post with a solution to these issues, but I only read about 75% so I could have missed something. I started on the last page and went backward until it started looking like much older versions of grbl panel were being discussed. I saw one post with one of my issues, but the user didn't say what he did to fix it. Thankfully it didn't take much time to overcome the problems. So if someone else has either of these issues, hopefully this post will help.

I'm here because I have designed a new 3D printer, and I need to mill some parts out of aluminum to make them solid enough to satisfy my requirements... Plus I've been wanting a c-beam and didn't have a good enough excuse to drop the cash on it until now.

George

 

Hey George

The reason why you probably couldn't find anything on these problems is that no one has seen them before. I know in building over 50 machines, I have never seen these issues.

It may have something to do with your G-Code Sender program. Don't know what you are using, but I use GRBL Panel, and it sets the baud rate with a button on the interface. This should set the baud rate in Windows, regardless of what the default rate on the port is set to. Strange that yours didn't. I use several devices that use USB to serial conversion, and setting the baud rate on the device screen always works. I've never had to change Windows settings. You actually might not want to change the default Baud rate on the port, because it may need it to do the initial handshake with a new device.

Mind you, I use Windows 7, can't stand Win10.

The second problem is also strange. GRBL Panel has a button that says "Get GRBL Settings", if you click it it populates everything. Having said that, I've never used the button that I can remember. As soon as you connect with the Arduino, it populates automatically. Again, may have something to do with your G-code sender program. May also have something to do with Problem 1. If it's not getting a serial connection, it can't read the GRBL settings from the micro. The "Last GRBL Parameter" setting should be automatically set, this is how the program updates the parameters when a new version is released that changes the number of parameters.

Also, a quick note, Windows doesn't always assign the same Com Port number to a USB device. It depends on what else was using USB when the driver was installed. It does usually stay put once you've installed a particular USB/serial driver, but it can change without warning.

Glad you found your issues. In future, if you cant find a solution to a problem, just ask.

MG

 

jeffmorris,

Even if Grbl panel can't do it, it should easily be possible. The standard "console" to arduino chips is a serial interface, and the config dump from the controller is probably a command you can run from a terminal program (such as putty). It is generally trivial to capture the text from a terminal program. Uploading to another arduino should be fairly straight forward once you know the format and commands required. I say that with no specific knowledge than having spent 40+ years working with serial ports and terminal programs as well as embedded systems. As far as I can tell, grbl is basically a text command line, and grbl control panels are generally specialized terminal programs designed to stream grbl files to a device, and to issue macros for functions like jogging.

You should be able to dissect the command line behind the "get grbl settings" button, and use that command from a term program to capture the config. Reversing that process to write the config shouldn't be too difficult.

I know I'm being vague here, in that I don't have the specific answer, I am only describing this in general terms...

 

Of course I'm here because I'm using Grbl Panel as my grbl sender. And I posted the problem/solution because other Grbl Panel users come here for support. So I may be new to Grbl Panel, but I'm on topic in the right place for support.

The field "Last Grbl Param" seems to hold the value of the last config parameter to dump. I can't tell you why mine was set to $0, but at least one other user here saw this problem, but the solution he found was not posted... He asked the question, then said it cleared up a short while later. Clearly it is not a common problem, it may be caused by me launching the program out of the zipped folder, a particular version I downloaded from git hub, or some other variable like having the serial driver default to 9600 on win10 while grbl panel was at 115200 the first time through. The variable might be that I frequently use serial consoles so some settings might have been at non-default presets. But my post was not a complaint, rather a helping hand for the next guy with the same issue.

And as for the driver behavior with serial ports, I know the com port number tends to drift every time the driver is loaded under conditions difficult to predict (more so on win7 than win10, but win10 has different drivers). That would be why I offered a suggesting regarding how to find your serial port. I can't tell you how many times people at work come tell me they need help with this "proprietary rs232 thing"... I tell them rs232 was a standard before they were ever born... And finding the serial port number is easy, but few support documents spell it out for people. It is a skill the kids are not learning in college.

My day job is managing a lab for embedded system programmers, so serial communication and serial consoles is something I deal with constantly, and have since the 1970's. The old guys get it, the kids think it is something new and are easily confused.

If I had seen these issues reported with solutions before in the forum thread, you might have never heard from me, as my purpose was to post the answer more than the question. The questions I still have aren't likely to get answers here... Fortunately my brother in law is a retired machinist, so I have someone to help with the hard stuff...

 

So I noticed that the "C-Beam Machine GRBL Settings" listed on the c-beam page are slightly different than those in the controller firmware as is shipping today. My firmware is missing $14, and has additional parameters $30, $31 and $32. I chalk this up to drift between the shipping version and the version that was shipping when the web page was created. Based on other things on the page, the page seems to be around 4 years old, so small changes are to be expected. I did not search the topic for those, I only mention it here in case it indicates I have an issue people want to warn me about (such as wrong firmware version). The parameter missing from my firmware is $14 Autostart, and my "extras" are $30 rpm max, $31 rpm min, and $32 Laser mode.

I think this is better fielded by the Spark Concepts team, except that they direct me to the 4 year old Openbuilds documentation page for information beyond their quickstart guide (a photo of the board with a wiring diagram). Precious thin documentation. But as thin and out of date as the documentation is, it is far better than the documentation of some of the open source code I work with in my day job, so I'm not complaining. That is part of the fun, groping around in the dark for answers, right? I mean, if this stuff was easy, we would all have to do something else to challenge ourselves.

 

Hey George.

GRBL has several release versions, all the way back to 0.7 and probably older. A lot of companies are still shipping preloaded Arduinos with version 0.9. Versions up to 0.9 did not have the "Laser Mode", which is associated with $30, $31, and $32. I have actually never seen a version with $14, don't know what it's for. Wiki says it is in version 0.8. Surprised anyone is still shipping with this version. The newer versions, 1.0, 1.1e-f have Laser Mode and the extra configuration values. It is always good practice to use the latest version as it has bug fixes and enhancements.

See: grbl/grbl

this is the older versions up to 0.9, newer 1.0-1.1 versions are documented through a link at the top of the page. You can download the latest version and install it, I like to use a program called Xloader, it's way simpler than using the Arduino IDE.

You can see your installed GRBL version and compile options on the Settings tab in the upper right corner, if you are using the latest version of GRBL Panel. It's kind of a shame that Garret has retired from supporting GRBL Panel, I hope someone takes up the support function.

One of my pet peeves is that nobody supplies proper documentation with their boards.

MG

 

Yeah, $14 is documented on the C-beam documentation page, and is missing from my unit. I only noticed when I was getting ready for the final stage of the build. I bought mine from Openbuilds, think it was the last one in stock as they are out of them now. The Openbuilds page is just getting old, even the build video was out of date, but they inserted some text frames to bring it up to date where it was badly outdated. It's not a big deal really, if we can't build past poor or out of date documentation, then we have no hope for making our machines work as there is so much more to know about milling aluminum than can be easily covered.

The example plate cut video was pretty scary, in that it really made it look like this machine really can't do a good job (if you assume this is the best the machine can do). But I saw another demo from someone with a really cheap chinese machine with a much weaker spindle plowing through a 1" thick block of aluminum leaving a mirror finish that convinced me that the problem with the c-beam was the video was simply showing someone making a cut without the right feed and speed rates, and probably the wrong set-up.

I do sense some deflection in the y direction from the top of the z axis that could be an issue, so one of my first projects after the build will be to take an indicator to the various segments of the frame supporting the Z, identify the part(s) that are providing deflection and shore those up if my first milling tests show the problem is real. It doesn't look like it is in the gantry wheels, but those would be my first suspect. But my eye tends to implicate the x axis structure. It is all tight, but there is no box to the structure so there is an accumulation of frame flex. I think I can correct for that with some forward facing braces. The x rail is on an "L" structure, and closing the open side of the "L" to turn that into a triangle should cancel most of the deflection I sense on the x, leaving just the x gantry wheels as the remaining weak link. I see some people box in the back side of the wheels by adding a second gantry plate on the back side, that might be the solution there. One person talked about replacing the wheels with metal wheels, but I'm not sure that will really help if the flex is in the wheel structure.

I saw one you-tuber proclaim the c-beam can't cut aluminum very well due to the flex in the Z, but in his example I think he just did a poor job on his build, had his feeds and speeds wrong, and probably used a cheap end mill. But he also seems to have chosen to shoot video of his first cut and give up...

The point being that you can document so much more, but at some point the machinist using the tool needs to own the responsibility to learn the art of running a mill. Most mill suppliers do not document much past the assembly instructions, they leave the art of using the mill to the machinists. I think the documentation is on the weak side for sure, and the example videos are poor, but the hobbyist's own learning curve is where the bulk of the issues will tend to be. Of course here I am asking stupid questions... but at least I know they are probably stupid. I need to go read some of the c-beam topics beyond the grbl panel discussion next, as I suspect there are a lot of people that have already solved some of the things I am expecting to deal with.

 

I would wholeheartedly recommend upgrading your GRBL 0.8 to GRBL 1.1F. 0.8 is old and decrepit.

I assume you are talking about the standard C-Beam Machine and not the C-Beam XL. I think it is a bit of a stretch to call this a "Plate Maker". It was the first machine I ever built, and it has a lot of shortcomings.

The play you are seeing when you grab the Z axis and yard on it is not from the wheels, or gantry plates. It is the C-beam flexing torsionally. It's pretty strong when the force is applied on top or the front, but torsionally its not as good, so the whole Z/X axis will twist if you apply force forward or back on the Z axis.

See the OB builds page for some upgrades I did with mine. The first rebuild was the CBM Too machine:

C-Beam Machine Too

Then, I did another major revamp and called it the CBM3:

Improved CBM

If you apply a little of both, you could come up with a great little machine. Machining aluminum is not easy, and you really need a mist lubrication system which precludes the MDF bed. MDF flexes too much anyway.

But, good luck, and experiment. That's how we get better and learn.

MG

BTW, here is a sneak preview of a new machine I am working on, which gets rid of the wheels and uses MGN series linear guideways. It's the same size as the CBM, but uses double C-beams for the X axis, and ball screws. I'll be publishing this build soon:



MG

 

I've got a question regarding Manual Jogging Movements. In Grbl panel, you set the incremental distance you want to move and the speed at which to move, then for each button press of X/Y/Z it moves that specified distance.
Is there a way, Or through other software to get it to move at a specified speed as long as an arrow button is pressed? Then once you let up on the arrow button it stops? This way I can position it much faster than having to keep pressing the buttons over and over.

Thanks!

 

You can just hold down the mouse button, it will keep moving as long as you do.

You can also set the speeds used in the main page radio buttons by going to the Setup tab and editing the values for Feed Increments and Feed Rates. Just make your own list of comma separated values, and click Refresh. There are separate settings for Imperial and Metric.

Also, if you get a jerky movement on an axis, you can change the Button Repeat Rate higher to make it smoother. Be careful with this as you can save up quite a few button presses in the buffer, and the machine will continue to move and crash into the end stops even after you let go of the button.

You can also check the Enable Keyboard Arrows box and it will let you use left, right, up, and down arrows, and Pg Up and Pg Dn for Z. Again, be very careful with this as holding these down for even a couple of seconds will store a huge number of key presses in the buffer and cause the machine to crash into the endstops. You may be able to change the Keyboard Repeat Rate in Windows to mitigate this. They were supposed to fix this so the machine stops as soon as you let go of the button, but it never got fixed and Garrett has now stopped maintenance on GRBL Panel, so WYSIWYG unless someone else steps up and continues support.

I find it useful to set the $10 (Status Report Mask) on the GRBL Settings window to 3 instead of 1, Then the Q and RX progress bars work on the Status window. You can see the Q (key or mouse button queue) getting filled up and let go of the button.

MG

 

Thanks but the button repeat problem is what I’m trying to avoid...

 

How can I get a copy of the source code for the Control - Machine Driver Software? I want to modify the GUI a little for our application. Thanks.

 

If I turn off my computer and CNC router at the end of the day and turn them on in the morning, GRBL Panel Control doesn't remember the settings. I have to home the machine, zero all axises, and auto-zero Z Axis before each job. If I hit E-Stop, I have to repeat those steps before the next job. How can I fix the problem? Is GRBL Panel Control no longer supported? I'm not sure about OpenBuilds Control Software.

 

You're kidding, right? What program do you have that will start right up where it left off after you shut down your computer?

Generally, no computer or software will remember it's state when powered off. Not much you can do about that. Doesn't matter which software you use, it's not going to be able to do what you want if you power it down. You have to do all that stuff every time you start a new job anyway, it only takes a couple of minutes. Not like it's a great hardship or anything.

Perhaps just put your computer to sleep rather than shutting it down, this should keep the USB port powered and the Arduino will remain in the same state. You can tell, if the red power LED on the Arduino remains on when the computer is put to sleep, that means it is still powered up. Keep in mind that if the machine is manually moved when powered down, the position info is lost as well. It's likely that GRBL panel will give you a "USB not connected" error or something similar through a sleep cycle, but you should be able to just ignore it.

Hitting the E-stop is a hard reset for the arduino, a hard reset clears all position information. If you do a soft reset, using the Reset button on GRBL Panel under the position display, it does not lose the position info. BTW, you can simply set all axes to zero when starting a job by using the E-stop.

GRBL Panel is currently not supported, the author has retired. We are hoping someone will take up the maintenance on the program, but so far no takers.

MG

 

Some computers keep the power on the USB port even when they are off, just so USB keyboards and mice are able to wake up the computer, especially in sleep mode. If yours does, the power to the Arduino is not interrupted even though you powered off the computer. Easy to check, if you power down but the power LED on the Arduino stays on, it is still active and maintaining it's memory. If you power it off, it does a hard reset which clears the position registers. GRBL may store the work offsets in EEPROM, along with the G28 and G30 positions, but I'm not sure. Anyway, if your main position info is lost, it doesn't matter if you still have the work offset saved, because there is nothing to reference to.

MG

 

Where can I get more info on G54-G59 work coordinate offsets and G28/30 positions? The gnea/grbl page doesn't have info on those commands.

 

Use Google.

MG

 

Cnc cookbook has a thorough account.
Alex.

 

Hello i have a problem with skipped lines of code in z axis , and was wondering if anyone experienced similar problems?
I am using a xproV3 board and Universal Gcode Sender and have succesfully ran the cbeam xl hundreds of hours.
First i thought that the newest vcarve update messed up the post prosessor or something so i made a really easy two hole drilling op and tried with the same result , and after inspecting the code i can rule that out.
everything is fine but after pecking to final depth in the first hole it skipps the Z retract line of code and just starts to move to next position wich results in a broken bit.
I reinstalled the UGS several times and it does the same thing everytime i import a program , in the preveiw you can see that it skipps all or some of the code but just for z axis.

 

T1
G17
G21
G90
G0Z1.000
G0X0.000Y0.000
S16000M3
G0X10.000Y99.970Z1.000
G1Z0.000F2000.0
G1Z-4.750
G2X9.970Y100.000I0.000J0.030
G2X10.000Y100.030I0.030J0.000
G2X10.030Y100.000I0.000J-0.030
G2X10.000Y99.970I-0.030J0.000
G1Z-9.500
G2X9.970Y100.000I0.000J0.030
G2X10.000Y100.030I0.030J0.000
G2X10.030Y100.000I0.000J-0.030
G2X10.000Y99.970I-0.030J0.000
G1Z-14.250
G2X9.970Y100.000I0.000J0.030
G2X10.000Y100.030I0.030J0.000
G2X10.030Y100.000I0.000J-0.030
G2X10.000Y99.970I-0.030J0.000
G1Z-19.000
G2X9.970Y100.000I0.000J0.030
G2X10.000Y100.030I0.030J0.000
G2X10.030Y100.000I0.000J-0.030
G2X10.000Y99.970I-0.030J0.000
G0Z1.000
G0X409.970Y100.000
G1Z0.000F2000.0
G1Z-4.750
G2X410.000Y100.030I0.030J0.000
G2X410.030Y100.000I0.000J-0.030
G2X410.000Y99.970I-0.030J0.000
G2X409.970Y100.000I0.000J0.030
G1Z-9.500
G2X410.000Y100.030I0.030J0.000
G2X410.030Y100.000I0.000J-0.030
G2X410.000Y99.970I-0.030J0.000
G2X409.970Y100.000I0.000J0.030
G1Z-14.250
G2X410.000Y100.030I0.030J0.000
G2X410.030Y100.000I0.000J-0.030
G2X410.000Y99.970I-0.030J0.000
G2X409.970Y100.000I0.000J0.030
G1Z-19.000
G2X410.000Y100.030I0.030J0.000
G2X410.030Y100.000I0.000J-0.030
G2X410.000Y99.970I-0.030J0.000
G2X409.970Y100.000I0.000J0.030
G0Z1.000
M5
G0Z1.000
G0X0.000Y0.000
M2

 

And Im not using grbl Panel but Universal Gcode sender so im posting in the wrong thread , ill leave it here anyways cause i found the solution in another thread.

( Copied )
Just to conclude this one I did find the solution. As David suggested the “Regular expressions remover” was filtering out certain lines of code. I eventually realised i only had myself to blame (as usual) - when UGS was throwing up errors I was randomly clicking Yes, No, or the X to close the error box that pops up. I must have occasionally been hitting OK which then adds that line to the filter and is ignored in the future.

I presume the code is only run through the filter once connected to the CNC machine. Hence, the visualiser looked fine before connecting, but was missing certain cuts when visualised after connecting.

Thanks David