Servus, I am runing a x-carve with a grbl-shield and since yesterday I have

Servus,

I am runing a x-carve with a grbl-shield and since yesterday I have a strange problem with chilipeppr.

I use the touch-plate function to zero out the z-axis. This seems to work fine.

But at the moment, when I start the toolpath, chilipeppr is adding an offset to to the z-axis values. so the bit is flying through the air instead of cutting into my plastic-sheet.

If I use the same G-code file with UGS, everything works fine. But UGS does not have an auto-level- nor the touchplate-feature.

Two days ago, I used the aoutlevel-function to mill a pcb and the touch-plate feature and everything works just fine.

Does anybody has any idea, why chilipeppr is adding this z-axis-offset (about 20 mm) and how to avoid this?

Have a nice day

Wolfgang

ChiliPeppr doesn’t add offsets, so my guess is that Grbl is adding an offset which really means your own Gcode is adding an offset. It sounds like ChiliPeppr is working perfectly fine but then your own Gcode adds the offset at the start. So, are there are G92 or G54, G55, G56, etc commands in your file?

Seems like I have seen this once, but I wasn’t able to reproduce it to take a video. Are you able to consistently reproduce it? If so, take a video with some shots of the screen and behavior.

@jlauer : I am rather sure, that it has nothing to do (directly) with the g-code-file. The reasons: why I think so:

It tried it with three different g-code-files, the behaviour was the same. There is only one
G54 (select coordinate system 1)
statement at the beginning of each of the files.
A $# shows all axis set to zero for G54

If I run exact the same files with UGS, there is no offset.

If I do not use the touch-plate feature, but zero out the x-axis manually, there is no offset in chilipeppr, with exact the same files.

So it seem to be obvious, that anything in conjunction with the touch-plate feature, leads to the z-axis-offset.

@Frank_Graffagnino : I just have started a 3-hour-job, so I cannot check it out now, but I will try it again tomorrow (in Europe its evening now).
Here is a description of the behaviour, that I could reproduce today at least 10 times:

Zero the z-axis with the touch-plate-feature, using a 10mm block. After successfully probing, the z-axis goes to 11.9 mm and shows that value in the axes-section.

Then I zero out the x-axis and y-axis manually and click to “go to zero”. The bit goes exactly to (0, 0, 0). In the axes-sections all axes are displayed with (rather) 0.

After that, I start running the g-code-file (that I have droped in before the “work-homing”)
At the moment, when I start the g-cod-file, the z-axis-value changes to -19.956 (as far as I remember) and the bit raises on the z-axis to about 20mm more than it should, whereas it now displays the values, that are within the g-code-file, like 0 or 25 or 20, but the bit is about 20mm higher, than its displayed.

May be, that the G54-statement is causing this, but where does this 19.956 come from and why does this not happen, when I do not use the touch-plate-feature?

Any ideas?

What commands are sent during the touch plate? @Jarret_Luft did a modified touch plate for Grbl so i’m not sure his approach. In the TinyG workspace I made the touch plate reset machine coordinates G53. Just watch the serial port console while you run to see what it does.

@Frank_Graffagnino here is the video with the axes-display: https://www.youtube.com/watch?v=YRRxlo9R7lo

… and this is, what the x-carve does: https://www.youtube.com/watch?v=XE9OlCj5Too

Very weird. What versions of grbl and spjs? Also, can you share the GCODE that is doing this in the video?

I am using grbl. 0.9
spjs is currently running, so I cannot have a look for the version
this are the first lines of the gcode:

;PYCAM-META-DATA: Filename: /home/framlin/tinker/holzlampe/panel-test.stl
;PYCAM-META-DATA: Timestamp: 2015-12-07 17:49:56.693387
;PYCAM-META-DATA: Version: 0.5.1
;Estimated machine time: 115 minutes
G40 (disable tool radius compensation)
G49 (disable tool length compensation)
G80 (cancel modal motion)
G54 (select coordinate system 1)
G90 (disable incremental moves)
G21 (metric)
G61 (exact path mode)
F800.00000
S1000.00000
;PYCAM_TOOLPATH_SETTINGS: START
;[Bounds]
;maxz = 0.0
;maxx = 174.93
;maxy = 94.93
;minx = 1.57
;miny = 1.57
;minz = -22.0
;
;[Tool]
;torus_radius = 0.125
;speed = 1000.0
;shape = CylindricalCutter
;tool_radius = 1.57
;feedrate = 800.0
;
;[SupportGrid]
;height = 1.0
;distance_x = 23.0
;distance_y = 23.0
;adjustments_x = 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
;adjustments_y = 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
;thickness = 2.0
;offset_x = 0.0
;offset_y = 0.0
;type = grid
;
;[Process]
;engrave_offset = 0.0
;step_down = 3.0
;generator = PushCutter
;postprocessor = SimpleCutter
;overlap_percent = 0
;milling_style = ignore
;material_allowance = 0.5
;pocketing_type = none
;path_direction = x
;
;PYCAM_TOOLPATH_SETTINGS: END
T4 M6
G0 Z25.0000
X1.5700 Y1.5700
G1 Z0.0000
X174.9300
Y4.6820
X173.5454
G0 Z25.0000
X2.9546
G1 Z0.0000
X1.5700
Y7.7940
X2.9300
G0 Z25.0000
X7.1200
G1 Z0.0000
X169.3800
G0 Z25.0000
X173.5700
G1 Z0.0000
X174.9300
Y10.9060
X173.5700
G0 Z25.0000
X169.3800
G1 Z0.0000
X7.1200
G0 Z25.0000
X2.9300
G1 Z0.0000
X1.5700
Y14.0180
X2.9300

Serial Port JSON Server v1.86

Here is one way, how I can use the touch-plate-feature:
manual zero out X
manual zero-out Y
touch-plate-Z
goto zero
click ctrl+x
enter $X within the serial-console-input
click zero-out within the axes-display
run g-code-file

==> works fine, no offset

So the soft reset between touch-plate-usage and runng the g-code does the trick, I think.

Any ideas, what I should configure, to avoid this step?

so, i wonder if commenting out the G54 will fix things… i’m guessing CP is using G92 to zero out Z from the touch plate widget. If you do that… I’m wondering… does G54 then lose that G92 temporary assignment? I’m thinking you would need to do the WCS selection first then do the G92.

To test the theory I suppose you could manually send in a G54 before you do the touch plate zero and see if it makes a difference.

sorry, I didn’t understand this. What should I do in wich order?

well, i’m just suggesting trying it without the G54 in the GCODE to see if it makes a difference.

What’s interesting is the TinyG workspace Touch Plate sets machine coordinates because I figured that was a path to having less confusion out there. The Grbl workspace uses the G92 temporary offsets which then become overridden if your CAM software tries to set a work coordinate system. It might be better to default to the way TinyG workspace does it but perhaps let folks override from a radio/checkbox button.

Did something just change with this that would affect the grbl workspace? Tried this a few times today and it wasn’t working. Doesn’t look like it was using G92.

Nope. Nothing changed.

@Frank_Graffagnino I have removed the G54 statement, but that doesn’t help …

Is something else removing your g92?

No, I do not think so. At least nothing within the g-code file:
G40 (disable tool radius compensation)
G49 (disable tool length compensation)
G80 (cancel modal motion)
(G54 select coordinate system 1)
G90 (disable incremental moves)
G21 (metric)
G61 (exact path mode)
F1000.00000
S1000.00000
T4 M6
G0 Z25.0000
M3 (start spindle)
G04 P3 (wait for 3 seconds)
X160.1307 Y83.3482
G1 Z0.0000