GrblGru: Free CAM program with 3D simulation for mills and lathes

I have just uploaded a new alpha version v19. This should improve the “Allign circle” measurement.
The ‘30 seconds problem’ I look at again after my vacation.
Thanks again for your help to improve the program. :slight_smile:

Hey @GrblGru - v19 seems to have a severe bug. “Align circle” touches the first point correctly, then the machine does not return to the starting point but moves rapidly in XY, causing the probe to crash into the working piece.

Back from vacation. I cannot reproduce the behavior you describe.
On my website is a video “Align circle” that I created with version alpha 19. It works without errors.
https://www.grblgru.com/VideoGallery
Does the error always occur or only occasionally ?
Please take a screenshot of the two controller windows when the error occurs.

I just found out its occasionally. I managed to reproduce it once today but found another strange behaviour:
All 3 points are touched and recognized correctly but then the machine moves in Y- direction.
Left controller window says:
—> 120
0 G91 G38.2 Y50.000 F100
1 G90 G1 X0.000 Y125.075 F300
2 G91 G38.2 X50.000 Y-50.000 F100
3 G90 G1 X0.000 Y125.075 F300
4 G91 G38.2 X-50.000 Y-50.000 F100
—> 120
0 G1 G90 F100 X1.555 Y-8.255
—> 120

Right controller window:WCO:0.000,-125.075,0.000,0.000>
ok
<Run|WPos:-16.656,107.281,0.000,0.000|FS:100,0|Pn:A|Ov:100,100,100>
<Run|WPos:-16.538,106.513,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-16.425,105.800,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-16.313,105.091,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-16.200,104.375,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-16.088,103.663,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-15.975,102.953,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-15.863,102.238,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-15.750,101.519,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-15.638,100.803,0.000,0.000|FS:100,0|Pn:A|WCO:0.000,-125.075,0.000,0.000>
<Run|WPos:-15.522,100.081,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-15.409,99.359,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-15.297,98.653,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-15.184,97.928,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-15.069,97.209,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-14.956,96.488,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:-14.844,95.775,0.000,0.000|FS:100,0|Pn:A>
Hold:0|WPos:-14.772,95.319,0.000,0.000|FS:0,0|Pn:A

oops, my fault again. :frowning:
It looks like I forgot your A-axis again. Please check the new version alpha 20.

Looks good now. There is though still a long pause before the machine finally moves from the last point back to the center (position status messages come ticking in in the right controller window during that time btw.). Another thing is that the final command to move to the center is done with the slow feed rate (used for probing), not with the retract rate.
Thanks for the fix and have a great day!

Hey @GrblGru - I see the Alpha download page has vanished from your homepage. Is the 4 axis probing feature now included in beta or is this still scheduled for release of v6.0?

Alpha development is now complete. The beta version now contains the current state. I also hope to publish a new release version soon. Until then, please download the beta version.

1 Like

Hey @GrblGru
Issues with version 5.1.13:

  1. 3D probing, align circle: Still experiencing that the machine does not center to the circle after probing all 3 points, but runs somewhere else. This is not really reproducable. Homing cures the issue but its not predictable when this occurs.
  2. When choosing Tool Type = Laser, the command for the intensity is “M4 S=1000”, returns a fault. Correct syntax should be “M4 S1000” (The “=” sign should probably be dropped)

As always, thanks for your work :slight_smile:

Roman, thank you very much for your feedback. :slight_smile:

The “=” sign is of course a big bug of mine. I will fix this in the next version.

Do you still have a tip for me, how I can reconstruct the error when measuring ? How often does the error occur ? Do you also have problems with the other measuring functions or only with ‘Allign circle’ ?
I just tried it again. It always seems to work for me.

I only observe this with the “align circle” routine.
It is actually reproducable. The routine will always work as intended:

  1. after homing the machine
  2. after resetting the controller

Here is an OK align circle routine:

Here is one I took right after the first one above, this one failed:

And here is a third one which I made after resetting the controller. This one was again OK:

When it fails, the machine is running towards +X and -Y. Correct direction would be +X and +Y

You are right. I was able to understand the error from your records.
It is a problem of the conversion of the coordinate systems MPOS / WPOS.
The measured values are sent in MPOS and must be converted into WPOS. This did not work in the one case.

However, the error does not occur on my test setup nor on my machine.
So I could only do some precautionary checks in the new version V5.1.14 and output some debug displays. This includes a display of the G54 value, which contains the conversion MPOS / WPOS.

I still have two questions for you:

  1. can you please tell me what GRBL settings you are using. Command = “$$” (pic1)
  2. can you please check if G54 is your Select Coordinate System ? Command = “$G” (pic2)

Thanks again for your great help :slight_smile:

Always happy to help!
$G
<Idle|WPos:0.000,0.000,0.000,0.000|FS:0,0|Pn:A|WCO:0.000,0.000,0.000,0.000>
[GC:G0 G54 G17 G21 G90 G94 M5 M M9 T0 F0 S0]

$$
$0=10
$1=255
$2=0
$3=6
$4=0
$5=1
$6=1
$10=200
$11=0.010
$12=0.002
$13=0
$20=0
$21=0
$22=1
$23=1
$24=50.000
$25=500.000
$26=250
$27=1.000
$30=1000
$31=0
$32=1
$38=10
$39=0
$100=320.000
$101=320.000
$102=320.000
$103=2.222
$110=1800.000
$111=1800.000
$112=1000.000
$113=1000.000
$120=100.000
$121=100.000
$122=100.000
$123=100.000
$130=300.000
$131=400.000
$132=120.000
$133=720.000

By the way - I tested the 5.1.14 yesterday and it gives me a warning “G54 could not be read”.
I have a hunch this could again be a problem with 3/4 axes coordinates. My machine has 4 axes and the G54 offset comes most likely also with 4 values, while the program expects only 3.

Yes, that’s it !!! :slight_smile:

The error message I had installed to see if the G54 value was read. And you have of course combined correctly. By the 4th axis, the format of the read is different than with 3 axes, and so the G54 offset value was always 0. But this is only true after homing or after resetting the controller.

I will make this week a new version, in which the bug is then hopefully finally fixed.

Thanks for your great help. Please let me know if you have a special program wish.
I would be happy to return the favor.

I just want to briefly draw your attention to the new Notepad++ plugin.

It offers great possibilities to debug GCode. This now includes graphical output in addition to the well-known syntax highlighting. What makes me especially happy is that for manipulating the graphic the same mouse actions are used as in my program :slight_smile:

If you specify the path to the Notepad++ exe in the settings of GrblGru under ‘Editor’, the calculated GCode is displayed in the toolbar at the push of a button.

But of course Notepad++ can also be used to display Easel or X-Carve generated GCode. :slight_smile:

Here a pic from the German version

2 Likes

Hey @GrblGru, I am reporting an issue I have seen some time ago but did not really have the time to wrap my head around it… Something seems off with the reference point for the rotational axis. This is how my STL model looks like in FreeCAD:


This is how it looks in GRBLGru:

It seems the chuck rotates around the correct axis position, but its position is not concentric as it should be according to the STL files. I had it working in an older version once. where I found out I had to position the chuck to the machines zero position. Other XYZ+A axis machines seem to have the same issue (checked in v5.2.2)

@Roman, thank you for your feedback. I have been working a lot on the 4th axis and 5th axis recently. Perhaps I have inadvertently built in a bug. Can you please send me the STL files from your machine to GrblGruNoReply@yahoo.com.

Then I can take a closer look at why the error is occurring.
If you agree, I would also be happy to include your model in the program.

1 Like

Today, after a long time, I would like to introduce you to a new function in my program.

In the past, it was already possible to machine round components, but the machining options were limited. Now, however, it is possible to machine rotationally symmetrical components in a similar way to components machined on normal 3-axis machines. Machining methods such as CUT, POCKET, CHAMFER and even V_CARVE can now also be used on the rotary axis.

The video only provides a general overview of a possible process. Basic knowledge of how to use GrblGru is assumed. More detailed descriptions would have driven the length of the video to infinity.

Unfortunately, I do not yet have a suitable machine for such processing. The image sections shown in the video were kindly provided by a friend.

All the processes shown in the video can be reproduced in the simulation mode of GrblGru. I am happy to answer any questions you may have.

Have fun trying it out. :slight_smile:

3 Likes

Thank you for creating and sharing these programs.

One question on the lathe app (v1.0.0). It is very possible that this is user error, but I cannot understand why this happens. I import one of the sample dxf files, touch off the material, and then set the zero point in grblgru.

The resulting gcode seems to jog in the wrong X direction initially, and then run a few passes only cutting air before finally contacting the material. I would not think that the green simulation lines on the screenshot should go below the tip of the tool (for the roughing passes that is).

I have tried changing the diameter, jogging and re-setting the zero point/origin, and I looked through all of the parameters in the “2d” tab, but did not find any that seemed to fix this. Am I doing something wrong or is this a bug?