bCNC - help - support - FAQ

I have been using the bCNC for some time to run a self-made pyro-engraving machine with the tool for this that the program brings. The issue is that when generating the Gcode in the white parts in some lines does not set the maximum speed established by what makes me draw unnecessary lines in the final work. I think this is a bug of the program or that I may lack RAM when generating the Gcode but I have 8Gb and I do not know what I can do to solve this problem. I thought that maybe it could be some irregularity in the image but I tried with well treated images in Photoshop and it does not make sense that the program gave me that bug. I need to solve this problem because it is the only program I know that generates this type of work except for a Russian one for payment. If any of you could guide me, I would be very grateful.

I am new to grbl / bCNC but like what I’m seeing. I have built 5 CNC machines from scratch and have used a variety of controllers, steppers, motor controllers, etc. I just am finishing a 4’ x 5’ CNC router using an Arduino with grbl and a Raspberry Pi using bCNC.

I have learned a lot thus far and all seems to be in good shape. I found a lot of issues and I’ll no doubt document my experience and make that available to others. The EMI issues in particular have been interesting to diagnose and fix. But at this stage it appears as though there are a few things that bCNC lacks or things that could be improved upon. I am a software engineer so I by myself could most likely tackle these but I am not versed well in Python and it would take me some effort there. I would therefore like to ask if there is anyone who would like to collaborate on this so we can move bCNC forward as a more robust product?

I have used Mach3, UCCNC, LinuxCNC and a few others. Here are the major things I see the bCNC needs. Feel free to correct me if it’s there and I just don’t see it:

  1. Easier Jogging
    It is time consuming to jog with single mouse presses and constantly adjust the distance to move down to get exactly where you need to be. There are easier ways to do this with less interaction.

  2. View running G-Code
    You can see the running G-Code in the Editor but the “Ok” responses being returned from grbl make it tough to really follow. A simple toggle off feature would be nice to eliminate those lines so you can easily see just the G-code running through without interruption.

  3. Restart Capabilities
    Although not required every day, a restart option is most helpful. Mach3 does it but it takes a little effort. UCCNC does it really well. A feature to either walk the file from the beginning to the restart point virtually to get the X, Y and Z position at the point of restart, or, the ability to create a restart file during running where it would store the X, Y and Z position after each G-Code statement. Then if you restart it could go to the line in the restart file to get the X, Y and Z position and then start the G-code from that point forward.

Hopefully this makes sense. As I use these tools I may find a better way or see other things but for now those are the big ones. I absolutely love the auto leveling, camera setup, homing and other features that seem to be way ahead of other software. I believe this will continue to evolve and could outpace all the others. Thank you all so much for your efforts. Let me know if your interested and we can see if a plan can be coordinated.

Some quick comments on your points…

Re 1, I’ve been using a game controller for the past two years for jogging, probing, homing, run, feedhold, G28, G30. If, except for the XYZ +/- motions, you also assign keys for x10 and /10 jogging steps , it’s super fast and convenient and you can keep your eyes at the workpiece and the bit. I also use bCNC on a RPi and did the mapping with jkeys.

Here’s an old clip testing @10mm, 1mm, 0.1mm, 0.01mm steps.

Re 2-3, it’s a bit complicated, you need to take into account several cases and subcases. Was there a power outage? A controller reset? Was the WCS origin persistent (G10) or not (G92) ? All X,Y,Z or some? Z is very important in such a case. Whenever I had an incident that required restarting the job midway, I’d look for the last lines executed in bCNC, then edit a copy of the file removing all the way down to the last executed code (repeating some of the last lines to be safe). Then starting from a safe Z I’d add code to slowly plunge to the working Z in a spot that would not crash and continue from there.

@EliasPolitis would you mind sharing how you’re able to utilize the game controller with bCNC?

I believe this is how a game controller was implemented.

It’s a 3 step process:

(1) identify the buttons
(2) map buttons to keystrokes
(3) map keystrokes to actions

This is a common approach for adding a physical input as means of controlling software. I recently did something similar for developing RAW photos in Capture One with a 16 knob + 16 button MIDI controller.

For Raspbian and bCNC I did (1) with jstest, (2) with jkeys. If you use standard shortcuts you don’t need to do anything for (3), it’s already there. If you wish to use custom shortcuts (e.g. for macros) you need to define them in bCNC.

Have a look here for some more details:

EDIT: you can get jkeys here.

Any advice would be greatly appreciated.
I am trying to do a tool change it goes through the first phase fine does the first cut then goes to a hold when it should be moving to the tool change position for another tool change? I am obliviously missing something.

I am at a loss and still pretty new to this… video and file

code.txt (303 Bytes)

@SamVean What machine and controller? What CAM software? What post processor? I see a G43 in there. Grbl does not support that, though I’m not sure how bcnc treats it.

Open builds lead cnc with bcnc and grbl

How are you generating the gcode? I think that’s where your problem is.

VcarvePro gcode ATC file

You’ll want to use a grbl post processor (or X-Carve or Shapeoko etc).
I can send you a modified one for tool changes later.

That would be awesome i did not know you could add post processors, if you had one for grbl that did tool changes and would be willing to share it i would greatly appreciate it.
I see the default x-carve or shapeoko ,grbl do not support tool change in the default processors.

Not much to modify the posts. Here’s one that adds toolchange (M6) and dwell (G4) commads.

Grbl_mm_TC.pp (4.9 KB)

Technically, GRBL does not support tool changes. Some senders like bCNC and my favorite, CNCjs, intercept the M6 command and run a macro to act as a tool change.

You have been such a great help and the tool change works and all but runs into an alarm after first tool change just when it has goes to go back to work position due to a machine limitation? i can only assume its trying to move +up 5mm before it goes back to the job but i set the tool change position 5mm below the home switch on the Z. also tried setting it another 5mm down but same issue. code for the cut file below aswell
Code (2).txt (304 Bytes)

Any chance you can capture or copy/paste the log, so I can see the string of commands sent before the error?

So i got this video from play to the issue. https://youtu.be/Rx8Lnsq5iYc

I’m sorry. I can’t read that in the video. I tried.
Can you just copy paste?

ok
G10L20P1X0Y0Z0
[GC:G0 G54 G17 G21 G91 G94 M5 M9 T0 F60 S0]
ok
$G
[G54:-605.003,-727.002,-5.003]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,-38.197]
[TLO:0.000]
[PRB:-605.003,-727.002,-23.159:1]
ok
$#
ok
G90
ok
T1
ok
G17
ok
G21
ok
G90
ok
G0Z20
ok
G0X0Y0S12000
ok
M3
ok
G0X28.026Y37.288Z5
ok
G1Z-3F200
ok
G1Y147.288F400
ok
G1X184.026
ok
G1Y37.288
ok
G1X28.026
ok
G0Z5
[GC:G0 G54 G17 G21 G90 G94 M3 M9 T0 F400 S12000]
ok
$g
ok
m5
ok
g53g0z-10.005
ok
g53g0x-575.003y-697.002
ok
m0
ok
g53g0x-575.003y-697.002
ok
g53g0z-10.005
[PRB:-575.003,-697.002,-23.194:1]
ok
g91G38.2f60z-30.0
[PRB:-575.003,-697.002,-23.174:1]
ok
G38.4f60z13.24
[PRB:-575.003,-697.002,-23.194:1]
ok
g91G38.2f40.0z-16.876
ok
g10l20p1z-21.089
ok
g53g0z-10.005
ok
g53g0x-575.003y-697.002
ok
m0
ok
g90
ok
g0x28.027y37.288
ALARM:2
[MSG:Reset to continue]

END

This code below is what was ready to go just before i hit resume after the tool change.
g53g0x-575.003y-697.002
m0
g90
g0x28.027y37.288
g0z5.002

code (1.1 KB)

From pic 1, it looks like
WCS Z-3 = MCS Z-5

By commanding WCS Z5 you want to move 8mm higher from current position which would be MCS Z3.

MCS Z can only be <=0 . In your case, according to your $132, your working Z range is from Z0 to Z-70 (MCS) and your code wants to go to Z5. This is out of range and triggers the out of range alarm (alarm 2).

(all numbers rounded for simplicity)

1 Like