Hello,
i am missing the possibility to run self made gcode before and after a M6 tool change command as it was able in 1.1.7.
Because gSender is not processing the âPRB:â message from a probing command i have to use the special probing command only included in FluidNC with the P-parameter (Probe | Wiki.js) to get the exact trigger position of the tool sensor / sensor plate. Because of that i run my self made tool change code.
So it would be very helpfull if you could add additional the originally functionality of running your own code before and after a M6 command.
Thanks for your help, I appreciate it. Iâm in the process of swapping my router for a spindle and Iâm trying to get all the bugs worked out of gsender first.
Still a bit buggy! Wouldnât do a Z probe after a tool change. In the console there was a Gcode error from its own probing code. I ran a probe command G38.2 in the console successfully, then it was willing to do its own Z probe successfully. It also messed up on G4P2 command in one of my scripts, pausing and sometimes stopping altogether in the wrong places
You should be able to do this using Pause strategy + a custom macro. PRB values are available as macro variables thanks to a pull request by @NeilFerreri
G38.2 Z50 F60
%PROBE_Z=params.PRB.z
([PROBE_Z])
([JSON.stringify(params.PRB)])
Ultimately it should be a bit more flexible compared to preset code blocks.
GRBL does not support parameters for M0 commands. This is a firmware issue, not a sender issue.
Line comments should already be appearing in the pause dialog.
The availability of the PRB values are a really nice feature!!
Yes you are right, with the pause functionality you are more flexible but i see two drawbacks of this functionality.
- If you accidentally press the wrong macro you mess up your job
- Because i use the printing of the M6-command comment on the screen for telling me which tool i have to change i have to run a code before the tool change, to move to the tool change position and i need a code after the M6-command to perform the tool probing onto the tool sensor.
So if you do not want to support the pre defined code blocks anymore, would it be possible at least to define two fixed macros, which are run before and after the tool change command instead?
@KGN Will Edge 1.3.0 (HAL+) receive these fixes in 1.2.2 in the near future? I want to jump in to testing the new PRB: functionality but really need the HAL version as my base.
Next release will be current with 1.2.2 and include the PRB changes and a few other things. Timeline TBD (not this week) but sooner rather than later.
I adapted my probing macros to use the PRB: data using EDGE 1.3.0 on my GrblHAL/Teensy 4.1, with @NeilFerreri %PROBE_Z etc variables. The macros run OK syntactically, but when I set Zero using the PROBE_Z there is a NaN error which suggests that the PRB: report is not being parsed into the PROBE_Z etc variables correctly (or perhaps that part is not written/finished).
I stripped the Z macro back to the barest minimum, to avoid the NaN error coming from a calculation error on my part, but I still get the same NaN. If it helps, the below documents the essence of the macro and some contextual data.
An excerpt ************************;
; Set user-defined variables
%PROBE_TIP_DIA = 2.0 ; Diameter in mm
%PROBE_INERTIA_Z = 0.00 ; Machine overshoot Z due to inertia
%PROBE_INERTIA_XY = 0.00 ; Machine overshoot XY due to inertia
%PROBE_BLOCK_X = 0 ; Probe/puck thickness, X
%PROBE_BLOCK_Y = 0 ; Probe/puck thickness, Y
%PROBE_BLOCK_Z = 0 ; Probe/puck thickness, Z
%PROBE_PROBE_RANGE = 15.0 ; Range that G38.x will use
%PROBE_CLOSE_RANGE = 1.0 ; Distance to retreat before slow probe
%PROBE_PROBE_SLOW = 50.0 ; Slow probe rate for G38.x
%PROBE_PROBE_FAST = 150.0 ; Fast probe rate for G38.x
%PROBE_DROP_BY = 7.0 ; Distance Z drops before probing (typ double WITHDRAW)
%PROBE_WITHDRAW = 3.0 ; Distance axes pull back after probing
; Wait until the planner queue is empty
%wait
; *** FRONT LEFT âTO and AWAYâ PROBE XYZ ***
G21 ; Make sure weâre in mm
M5 ; Just to be sure, ensure spindle is stopped
G91 ; Incremental mode
; *** Z Probe *** Downwards is -ve
G38.2 Z[-PROBE_PROBE_RANGE] F[PROBE_PROBE_FAST] ; First probe quickly to find Z
G0 Z[PROBE_CLOSE_RANGE] ; Withdraw now Z crudely located, raise Z a little
%wait
G38.2 Z[-PROBE_PROBE_RANGE] F[PROBE_PROBE_SLOW] ; Now probe TO slowly to reduce inertia
$# ; Ask for PRB report
%wait ; Let Reports catch up
%PROBE_Z=params.PRB.z ; Retrieve Z from PRB
G10 L20 P1 Z[PROBE_Z +PROBE_BLOCK_Z -PROBE_INERTIA_Z] ; Set Z0 with PRB compensations
G0 Z[PROBE_WITHDRAW] ; Pull up Z to clear puck/workpiece
; end of macro excerpt *********************
It is the G10 line that throws the NaN
If I look at the G38.2 Z command, I can see in the console the PRB: report as follows (I have a permanent rotary axis, so PRB is reporting X,Y,Z and A = 4 elements in the PRB, which could be a causal link to the NaN error�);
feeder G38.2 Z-15 F50
[PRB:-344.975,-37.117,-39.169,-3.000:1]
Running $# manually, I see PRB: similarly, as follows;
client $#
[G54:-344.975,-25.643,-34.769,0.000]
[G55:0.000,0.000,0.000,0.000]
[G56:0.000,0.000,0.000,0.000]
[G57:0.000,0.000,0.000,0.000]
[G58:0.000,0.000,0.000,0.000]
[G59:0.000,0.000,0.000,0.000]
[G59.1:0.000,0.000,0.000,0.000]
[G59.2:0.000,0.000,0.000,0.000]
[G59.3:0.000,0.000,0.000,0.000]
[G28:0.000,0.000,0.000,0.000]
[G30:0.000,0.000,0.000,0.000]
[G92:0.000,0.000,0.000,0.000]
[HOME:-3.000,-3.000,-3.000,-3.000:15]
[TLO:0.000,0.000,0.000,0.000]
[PRB:-344.975,-13.891,-39.169,-3.000:1]
ok
Just following up on this - code blocks will be reappearing in the next Edge release as an option for tool changing with them coming to Main again in the near future alongside the rest of the rotary work.
While the general feedback originally was that they didnât work well for most tool changing workflows, them disappearing received a bit more of a backlash than expected. While we still think itâs possible to do the same thing with macros, we generally donât see a reason to remove the option for those who donât want to change their approach for whatever reason.
Weâll also be adding a pass-through option to not comment out M6 if people are using firmwares that are GRBL-adjacent and do support actual tool changes.
Now, I learned two things while writing this. The âexport macroâ button works, but you can only export all the macros, as gsender saves them in one .json file. However, the âimport macroâ button does not work. I will write a comment in the 6.6 thread on that right now. Edit: FWIW, Frank, Iâve added a comment on this in the 6.6 feedback thread.
And in 1.2.2 the import macro function still doesnât work; even on a json file. The json file was saved from the program notepad++ by selecting the json extension.
And in 1.2.2 the âcopy the last 50 linesâ in the console doesnât work for me. Thereâs no indication that anything gets copied when that console button gets pushed.
I tried highlighting the text and not. I tried ctrl-c on highlighted text, also.
I tried pasting into Notepad, but it only pasted a previous item that I had copied with ctrl-c.
Windows 10 on a laptop.
Weâll take a look at both of these, thanks.
Kevin
I updated my production PC to GSender 1.2.2 and GSender 1.3.2 and realized the function menus were no longer there. I also confirm on DEV PC (Running WIN10, but at different resolution), same thing.
See compared Screen Grabs: (Yes, my machine was disconnected )
Should i see the function menus with newer versions?
Function menus generally only appear in Edge builds, not production.
While rebuilding some basic macros I found several items that make it difficult to produce macros in gSender (1.2.2)
This line gave me fits trying to isolate what it was doing. The error messages donât really help when thereâs this kind of problem.
%LWC=modal.wcs ( save the current workspace )
The variable and source are available in the macro editing window in gSender. Its supposed to save âG54â or âG55â or etc. when Iâm saving the Workspace location. It was returning null into the variable LWC.
I had to dig up some old computer programming troubleshooting skills when I was trying to pin down why I was getting an error message and not my intended result.
I suspect its true for any line that is setting a variable value.
The import and export functions in the macro editing function either donât work or are difficult to figure out. I tried importing both a TXT file and a JSON file without success. The exporting function just dumps all macros out in JSON file which is obviously not convenient. Sorry for duplicating this request.
I got no movement, or at least extremely slow on the Z when probing for Z zero. I put the router in position, lowered it a little, did the probe test, and finally clicked probe. Below is what I copied from the console. Windows 11 64 gSender 1.2.2
feeder G91 G20
error:3 (Invalid statement)
feeder G38.2 Z-1.5 F5.9
client \x18
ALARM:3 (Abort during cycle)
ok
Grbl 1.1h [â$â for help] LongMill build Feb 25, 2020
[MSG:â$Hâ|â$Xâ to unlock]
Just documenting another irritant for 1.2.2 in hopes it wonât go into newer versions.
Since Iâm stuck with very long load/startup time for gSender, I try to get ahead of it by loading it while Iâm doing other things. Later, Iâll remember what I did and go back to click the homing button etc.
Only thing is, when the damn thing quits waiting for you to click the button, it just goes into an infinite loop that canât be exited without shutting down and waiting through the same delay again. What the hell?
I donât know if the Windows port, the Shapeoko or the software times out, because gSender is in the disconnected mode by then.
Does it happen before you connect to the COM port, or after?
I donât know, because Iâm not there. gSender automatically connects ⊠if youâre there to click the Homing button thereâs no problem.