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.
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�);
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.
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?
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.
@CrookedWoodTex I donât have mine set to auto connect so my mileage may vary. However, gSender never times out on my two setups after it opens. No version ever has, including 1.2.2. FWIW.
Thanks Grant. Yesterday I disabled the setting for auto connect, settings were saved and I exited gSender. I reloaded it, waited for at least an hour and connected just fine. No death spiral loop.
So, I re-enabled the auto connect setting as I was shutting down last evening and this morning loaded gSender as usual. I let it sit for an hour. When I got back, it had auto connected, was waiting for the homing cycle and all started up OK.
I suppose there is something there about auto connect that didnât get right during the change to 1.2.2. Just toggling the setting and restarting got it corrected? Iâll keep checking it, though.
)
gSender automatically connects ⊠if youâre there to click the Homing button thereâs no problem.