Problem with probing about iosender HOT 19 OPEN

New edge versions with M66 bugfix uploaded - 2.0.45p5.

Another problem when probing with "Set Z = 0 at X0Y0:" option and negative X Y in "Area to probe". Z is not become 0 at X0Y0 in .map file.

Which version are you running?

It's also would be nice to add possibility to edit and save G-Code file after applying height map.

Save then edit works.

My custom code visible but doesn't work after applying height map either. M101L1Q60 should send command via UART but it doesn't.

I'll have to look into how to better handle arbitrary M-commands when transforming the gcode, e.g. the L word is removed in the above example.

from iosender.

Thank you, Terjeio!
But I still have problems with the height map.
In my project, the tool should move above the surface at a distance of 0.2-0.3mm (needle with paint).
After creating and applying a height map in ioSender and setting Z0 to X0Y0, the needle touches and scratches the surface in many places.
I tried to do the same in Candle, and there were no problems, the needle always moved at a distance of about 0.2 -0.3 mm above the surface and not touching it, as I needed.

I made a test circle with a diameter of 300 mm and here are the extreme points after applying the height map in ioSender and Candle (before applying height map Z is 0.2mm):

ioSender
X-150 Y0 Z0.183
X0 Y-150 Z-0.096
X150 Y0 Z-0.057
X0 Y150 Z-0.185

Candle
X-150 Y0 Z0.307
X0 Y-150 Z0.175
X150 Y0 Z0.280
X0 Y150 Z0.004

ioSender .map file:

MinX="-150" MinY="-150" MaxX="150" MaxY="150" SizeX="7" SizeY="7" ZOffset="0.385"
X="0" Y="0" 0
X="0" Y="1" -0.028
X="0" Y="2" -0.014
X="0" Y="3" -0.017
X="0" Y="4" -0.061
X="0" Y="5" -0.106
X="0" Y="6" -0.116
X="1" Y="0" -0.143
X="1" Y="1" -0.144
X="1" Y="2" -0.125
X="1" Y="3" -0.12
X="1" Y="4" -0.152
X="1" Y="5" -0.191
X="1" Y="6" -0.228
X="2" Y="0" -0.205
X="2" Y="1" -0.218
X="2" Y="2" -0.201
X="2" Y="3" -0.203
X="2" Y="4" -0.242
X="2" Y="5" -0.295
X="2" Y="6" -0.344
X="3" Y="0" -0.296
X="3" Y="1" -0.296
X="3" Y="2" -0.274
X="3" Y="3" -0.268
X="3" Y="4" -0.29
X="3" Y="5" -0.338
X="3" Y="6" -0.385
X="4" Y="0" -0.301
X="4" Y="1" -0.296
X="4" Y="2" -0.296
X="4" Y="3" -0.306
X="4" Y="4" -0.338
X="4" Y="5" -0.391
X="4" Y="6" -0.448
X="5" Y="0" -0.305
X="5" Y="1" -0.3
X="5" Y="2" -0.282
X="5" Y="3" -0.288
X="5" Y="4" -0.312
X="5" Y="5" -0.354
X="5" Y="6" -0.4
X="6" Y="0" -0.234
X="6" Y="1" -0.25
X="6" Y="2" -0.239
X="6" Y="3" -0.257
X="6" Y="4" -0.288
X="6" Y="5" -0.337
X="6" Y="6" -0.387

Candle .map file:

-150.00;-150.00;300.00;300.00
7;7;-0.60;0.60
0;60;60
0.13700000000000001;0.055000000000000049;0.0010000000000001119;-0.024999999999999911;0;0.050000000000000044;0.099999999999999978
0.099999999999999978;0.028000000000000025;-0.022999999999999909;-0.050000000000000044;-0.044999999999999929;0.0080000000000000071;0.086000000000000076
0.124;0.050000000000000044;-0.0040000000000000036;-0.036000000000000032;-0.03499999999999992;0.02100000000000013;0.09000000000000008
0.10699999999999998;0.035000000000000031;-0.016999999999999904;-0.038999999999999924;-0.042000000000000037;0.0070000000000001172;0.080000000000000071
0.066000000000000059;-0.0069999999999998952;-0.058000000000000052;-0.084999999999999964;-0.086999999999999966;-0.032000000000000028;0.031000000000000028
0.009000000000000119;-0.062000000000000055;-0.11499999999999999;-0.13900000000000001;-0.13900000000000001;-0.084999999999999964;-0.012999999999999901
0.0040000000000000036;-0.10499999999999998;-0.16500000000000004;-0.19599999999999995;-0.19900000000000007;-0.1419999999999999;-0.078000000000000069

ioSender Edge XL 2.0.45p5
Board MKS Tinybee (ESP32)
grblHAL Build 20240228

from iosender.

the needle touches and scratches the surface in many places.

What kind of motion? Rapids (G0) or regular (G1, G2 or G3)?

Are the map files above generated from scanning the same surface? And by following the same pattern?

from iosender.

Motion is G1, normal.
Patterns are exactly same. 300x300mm, X-150 to 150, Y -150 to 150, grid size 50mm. Surface is same, measured one by one.
Only difference measuring direction. ioSender starts from X-150 Y-150 and than moves by Y axis (Y-100, Y-50, Y 0, etc.) and Candle starts also from X-150 Y-150 but than moves by X axis (X-100, X-50, X 0, etc.)
I've tried several times and result is always about the same.

from iosender.

from iosender.

from iosender.

Here is the hegthmap from Candle, offset to 0 for the origin.

0;-0,082;-0,136;-0,162;-0,137;-0,087;-0,037
-0,037;-0,109;-0,16;-0,187;-0,182;-0,129;-0,051
-0,013;-0,087;-0,141;-0,173;-0,172;-0,116;-0,047
-0,03;-0,102;-0,154;-0,176;-0,179;-0,13;-0,057
-0,071;-0,144;-0,195;-0,222;-0,224;-0,169;-0,106
-0,128;-0,199;-0,252;-0,276;-0,276;-0,222;-0,15
-0,133;-0,242;-0,302;-0,333;-0,336;-0,279;-0,215

As you can se there is quite a bit of difference between them suggesting to me that the probed surface might be bending when probed. This might be due the probing speed beeing different. Or a bug somehwere causing the heighmaps to differ - it looks like ioSender is not probing the full width of the surface.
The differences are largest on the right hand side, is this where the scraping occurs?

from iosender.

Yes, left and right side are different height after applying a height map. I've changed a probe and made more tests. Circle 300mm. On the photo you can see difference.

from iosender.

Another strange behavior. I put probe to Z 1mm and start probing. And after probing is done probe returns to approx the same position but ioSender shows Z -4.xxx mm which is wrong. Not big problem because anyway I have to set new zero for Z axis with tool. But I think it should not be like this.

from iosender.

Is Candle probing each point twice with different feed rates like ioSender does?
Any backlash in the Z-axis?

from iosender.

No, Candle probing only once, but speed I use is same - 10 mm/min. And Candle shows immediately result of each point and visualization during probing ))
I think there is very slight backslash on Z axis. But it's not so big and result I still get acceptable for my need.

from iosender.

I would also like to thank you for this amazing project. Helped me a lot...

from iosender.

BTW. Now I'm using ESP32 TinyBee board with grblHAL and would like to ask you does any ESP32 board support I2C keypad? I've tried but no luck. I2C EEPROM is working but keypad is not. Now using keypad with UART. Not sure is it right place to ask...

from iosender.

ioSender shows Z -4.xxx mm which is wrong.

Do you have Set Z = 0 at X0Y0 checked when probing?

No, Candle probing only once

Ok, then you may set the ioSender Latch distance to 0 to skip the slow step. If you do so are the maps more equal?

does any ESP32 board support I2C keypad?

This board has the pin definition for the keypad strobe.

from iosender.

Ok, then you may set the ioSender Latch distance to 0 to skip the slow step. If you do so are the maps more equal?

Yes. Now much better!!! Thank you!!! I also hope one day ioSender will stop braking my custom G-Code )))

[This board] has the pin definition for the keypad strobe.

Ok. I will try. Is there definition example to use UART 3 in ESP32 boards? If I want to use MPG on UART 2 and UART keypad (input) and Debug (output) on UART 3. Is it possible? Couldn't get it to work.

from iosender.

Do you have Set Z = 0 at X0Y0 checked when probing?

All settings you can see on screenshots. Before probing and after probing. Real position of probe before and after is about 1mm.

from iosender.

I also hope one day ioSender will stop braking my custom G-Code )))

This is a bit complicated since a block (line) may contain several gcodes and some parameter words are single meaning. If the gcode is unknown (which parameter letters are asscociated with it) it becomes impossible to parse unambiguously.
I could assume that an unknown gcode "owns" all the parameter letters and just keep them (and the values) in a string and pass them unchanged through the transform routines and I may do this later.

Is there definition example to use UART 3 in ESP32 boards?

Not yet? You have to use instance number 2 to claim it - but it cannot be claimend by two "clients" unless you modify the code by commenting out or removing this line.

from iosender.

I could assume that an unknown gcode ...

Is it necessary to apply height map to M-Codes? Why not parse only G-code and leave M-codes as they are?

Not yet? You have to use instance number 2 ...

Thank you so much!!! With your help everything works now. I2C, Serial2, Serial3...
In the file "uart_serial.h" line 132 there is missing "," after "}" but error come out only if "SERIAL3_ENABLE" is defined.
I guess no one else accept me needed Serial3 )))

Keypad plugin also contain display plugin but there is no description. Is there any info or examples? Will it work with ESP32 boards?
I tried to compile with this plugin enabled but got errors:
"msg_type_t too large for I2C display interface"
"machine_state_t too large for I2C display interface"
"coord_system_id_t too large for I2C display interface"

from iosender.

Why not parse only G-code and leave M-codes as they are?

I'll have to leave unknown M- and G-codes alone, and that can be tricky as explained above.
BTW gcode transforms other than the heightmap transform also uses the parsed/tokenized gcode, and I am not going to write a separate parser just for the heightmap. So give me some time.

In the file "uart_serial.h" line 132 there is missing ","

I'll fix this in the next commit.

Keypad plugin also contain display plugin but there is no description. Is there any info or examples?

It is for the Jog2K Jog Controller. Or for MPGs or displays that uses the grblHAL message parser.

Will it work with ESP32 boards?

No - at least not yet. The ESP compiler do not understand the assert statements and currrently the I2C driver code does not support the required API functions. So a bit more code, and testing, is required to make it work.

from iosender.