terjeio / iosender Goto Github PK

Tried Alpha 7. Still hangs on first run against newly rebooted teensy4. Tried all three possible toggle actions. Didn't see any different behavior with each.

Would be nice to be able to change port and toggle from the app. deleting app.config gets old fast.

Hello @terjeio
I‘d like to ask, If I/we can help you, translating the Program into other languages?
Maybe you can tell, where the files are located, so that I/we could help you translating it?

Maybe there could be a „Config“ File for the name templates in the future, that could be easily edited.
I‘m not a „pro“ in this, but maybe some of these things can help.
It‘s just a thought, because for some people english it not the best solution, because they don‘t understand it...
Greets
Chris

Downloaded and ran A17 for a while. Haven't pushed it very hard but here are my initial thoughts.

Overall, polish and features have clearly matured. Looks good! You still want to call it Alpha level quality? I think it's ready for broader use. But, of course, that's your call.

Some thoughts on A17:

• I like the Open/Reload/edit/close menu. Edit is a very helpful feature. Is the editor choice configurable? I have not played with these features enough to give in depth feedback. A minor nit on the word reload - you open a file but then reload it. Seems a little inconsistent - Open and Reopen or Load and Reload are more consistent in my mind. Regardless of the name, I like the feature as I often reload (lol) a file and that saves going through the file open process. Since edit triggers an external editor, perhaps load/reload is a better choice.
• Thank you for App max and min!
• I haven't tested the probing tab but have started looking into it. Will have more (mostly questions, I think) later. It looks pretty substantial.
• Camera Tab. How does move offset work? It doesn't seem to do anything that I could see.
• Camera Tab. (more of an unrelated question) How would I monitor my CNC remotely? Is there a way for TSender to act as a server? Or at least coordinating the connection? I suppose it's better to set up a separate system and not add that to TSender.
• Repeating myself here but it would be good to be able to change Com port and related settings via a menu item (and without app restart).
• I have not tested it against legacy grbl systems but the features you have added make it stand well above the other senders out there. It might be worth some effort - all us grbl panel refugees need something better than bCNC and UGS.
• Start, hold and stop buttons - this is a personal preference issue but I would like to see the standard start, pause and stop icons. Instantly recognizable for what they are. I'd use mouse hover-hint text to show the keyboard alternatives.

In the next week or so, I will be converting my router over to use grblHAL and TSender so will have more feedback.

And again, TSender is really nice. Well done!

wondering if you IRC or anything if I have real time questions?

here is a long winded video of me bumbling through some testing. I didn't test edge finding prior to today. Corner finding works well, as does center finding. I'm guessing you didn't put much time into edge finding and there are some easy fixes.

https://youtu.be/NthS9aIBZzg

It seems that for edge probing it uses some of the corner parameters in unclear ways, for instance the x/y offset seems to control the pull off distance. It is also unclear if the probing distance in the 2nd from the top box controls the probe distance or if the offset in the bottom box controls the distance for edge probing.

Here is an example where g92 was set somehow but not by the settings I had configure and I had a "crash"

Here g92 gets set again but not based on my input

Here I forgot to reset the diameter since the settings need a few click to persist and get lost when you switch tabs (or maybe I restarted?)

Here I am not sure what coordinates are being used and the dro values are not helping. Maybe a feature request: can you track the coordinate system and other things like absolute vs relative mode and have them display in all tabs? I would also like to see the DRO in the probing tab, if the DRO could display the current WCS that would be great!

Here is an example of the GUI crashing. It did this many times in a row while I was attempting to record this and the crashing is what motivated me to record it in the first place. Once I finally got the recording setup decent it stopped crashing. The audio is very bad because I had the wrong mic setup.

As interest in this program increases, a download link to the current executable version on the "front" page of this repository would make it easier to find. Perhaps the pre-built binary should be included in the project so that "clone or download" gets it as well. Anything to reduce confusion will increase the number of people using it.

Also, I think a download link to the latest version on the grblHAL repository "front page" would also be very helpful. Alpha 19 is very stable and high quality. It is far better than any other G Code Sender out there and will make it easier to use grblHAL.

Minor issue. Upon startup, jog step indicator in low right corner is 0.05. Actual step in the Jog Panel is 0.1 mm. When you change distance in the jog panel, the lower left "Jog Step" value correctly tracks.

On a separate point, should it say Jog Step or Jog Distance? Shouldn't the two be consistent?

I have VS Code installed but I am beyond newb with VS in general. How do you run this, shouldn't there be a launch.json file? Happy to help documenting in the wiki if I can build/run this. I'm also looking to test out your esp32 HAL version with a focus on your enhanced jogging if I can get the sender running.

Does this code tested on Linux host?

Running a long test job (concentric_circles as arcs fr5000.cnc, posted on theGRBL/HAL issues list) with Aggressive Buffering and GCode Viewer on had a hang fairly early in the run. Also, running same test job with GCode Viewer on by Aggressive Buffering off also hung. A run with both off ran nearly to completion (7:05, 65K lines of 67.5K) but I tried to hold it and was unable restart.

The rapids on the center finding are a bit scary, maybe better to tone them down a bit with the defaults. My first test I had something that could move but I could have easily crashed it. It isn't clear that it rapids to the "safe distance". I like that it is quick but it may be unexpected for some.

Does the grblHAL in the microcontroller define the number of axes to the Sender?

I have a situation where a 5 axis build causes the G-Code Sender to only see 3 Axes on one PC but all 5 on another. Here's a screen shot of a $i showing 5 axes but the sender only sees 3.

I can power cycle it and restart the sender - sometimes it will show 5 axes, sometimes only 3.

I have an ammeter on my USB feed and it will show lower power consumption, commensurate with 3 axes, when only 3 are seen. When it show 5 axes, it shows the higher power 5 axes will draw.

This only happens on one PC. My main dev machine always show 5 axes.

not urgent but for reference.

you have to restart if you startup and have not yet plugged in your grbl. Refresh button would be nice.

I'd like to document a few things, how do you want to do that. Should I do it via a pull request?

Feature or bug? I don't know.

The test case concentric circles as arcs fr500.cnc loads in a few seconds (and looks correct). Took about 10 minutes in prior releases.

I'm getting a NaN in place of the Z postion below when z probing.

G53G0Z-163.048
ok
PM:ok
<Run|MPos:-84.446,-62.372,-164.066|Bf:14,512|FS:108,0|Pn:P>
<Run|MPos:-84.446,-62.372,-164.020|Bf:14,512|FS:180,0>
<Run|MPos:-84.446,-62.372,-163.322|Bf:14,512|FS:160,0>
<Run|MPos:-84.446,-62.372,-163.195|Bf:14,512|FS:88,0>
<Idle|MPos:-84.446,-62.372,-163.048|Bf:15,512|FS:0,0>
G10L2P1ZNaN

I use a four-axis machine.
If I activate "allow manual" in Alpha18 ($22=55) jogging is possible normally. But if I set the A axis back to zero with $HA (manual homing) and then jogging, no matter if X, Y or Z axis is running, the A axis will also run simultaneously. Whether keyboard jogging or using the tap.
If "Allow manual" is disabled ( $22=23) the jogging works perfectly.

This may be related to my previous report.

In the main TSender screen with no program running, highlight the number (0) in the Feed rate box and type any number. The display will not change. Then, load and run a GCode file. Note that the Feed rate in the display box stays at 0. Note that typing anything other than numeric digits will not cause this problem. A restart is required to get the Feed rate to display correctly.

Alpha 11.

Set $30, max spindle speed to 1000, save.
ensure off in spindle group is set.
enter 1000 in the RPM field.
click on CW or CCW. note that RPM has changed to 99.
click Off, note that RPM is still 99.
Clock on CW or CCW, note that RPM has changed to 9

Installed and played with it last night. Seems pretty solid though still has some rough behavior around Hold and (re)Start that I think you are aware of. I believe the same problem exists with using the feed/hold signal.

Tabbed interface looks ok. I assume you will remove the the top 3D View tab.

In the signal section, the indicator boxes (not sure the right word for them) are clickable and change to light grey when clicked. What does that mean/do?

I have been assuming that in the Signals section, a red box means the signal is active (as in button pushed or end stop hit). This presumes that inputs are pulled high, I believe. Thus, if inverted in Settings: Grbl, a red box means a high level signal is present. i.e. the normally low input signal is now high. Is this correct?

Ran a long job overnight and when I looked this morning, it was gone. Not sure what happened. Running same job again. Is there some sort of logging I could turn on?

BTW: do you own some probes/plates? I have none so I am thinking about using a piezoelectric element for probing.

Probing is a big yack shaving diversion so I though I'd break this out into another thread.

My "pcb mill" I use a HDPE plate for my PCBs so I just need to have the spindle grounded and connect probe positive the PCB surface. I made a puck with a spring in it which I just set onto the PCB. This seems to work well and I don't think I want to complicate that setup any more.

My lathe and "micro mill" both have ground continuity throughout so the above method doesn't work. My simple solution is to use some acetal to isolate a ground pin. These are machined to a press fit. The connection wire is soldered to a spring and then fit the spring over the pin. You could also thread/tap something into the pin.

I've thought quite a lot about non contact type solutions.

I did a prototype using velostat. It works but the signal wanders and tapers in a big curve as the material decompresses. I don't think this is a big deal if you are not doing lots of quick probe cycles. Using a microcontroller to manage what is a contact signal is easy enough and I think the approach has some merit but I have not poked at it for a while. This is perhaps the easiest to construct and very cheap. The complexity is in the signal processing.

Using a similar principal strain gauges can be used. This requires a high resolution ADC for each strain gauge Wheatstone bridge. I bought some BF350 and HX711 ADCs but I have not yet tested them. another project for my long backlog.

There is also the Kinematic coupling approach. you can use ground pins and ball bearings. I attempted to use a PCB to make one but it didn't work out great. For a non-PCB type the hard part is soldering to the ball bearings. On my todo list is trying plumbing flux to do the soldering. Silver solder is likely ideal but I don't have any. I also have a tig welder now so there may be a way I can use that. The other components are fairly easy to machine and there is a multitude of designs for these style probes. The complexity here I believe is setting it to be concentric which typically uses a system like a 4 jaw independent chuck. you can position the probe offset but then you have to figure out how to make it perpendicular to your work surface.

My pie in the sky project would be to make a 3d taster. The principal they work on is pretty simple but it requires machining a very accurate "cup" for the X and Y travel. It is essentially a regular dial indicator with a matched cup so that movement in the X/Y pushes the cup up. There is only one sensor/gear for the dial.

For plates I like this design: https://entirelycrimson.com/products/cnc-edge-finder-for-diy-router-machines. the hard part is holding the plate in registration but that design can do inside/outside corners and is easy to machine. The other downside is that if you forget to connect something you are going to crash.

The spring type "button" is nice for z height or tool offsets because you can set your probe limit distance to match your spring travel. The tool can still crash but it will only push the spring down. I have snapped a number of small end mills due to coatings on the PCB or bad contact with the PCB.

You could also make a HDPE or acetal sandwich by epoxying a plate of conductive material and then re-milling both sides to ensure parallel. This would let you attach use the fact that the spindle is grounded and you could probe the actual tool you would be using. Copper tape may be a quick and dirty way to do this but wouldn't last long.

While there are many fun diversions the simple continuity type probes are so easy and effective it is hard to justify the time to make another type. My lathe has enough backlash issues that I don't bother probing or setting my tool offsets. I have a ballscrew conversion planned but it works now and it is hard to mess with something that is working.

stop doesn't seem to be immediate, hold is though. If you are in a hold state and you stop it get stuck in a hold state and you have to reset.

In the other senders I believe stop will be immediate canceling the job and halting. I ran an adaptive clearing job which had a long 180 mm cut and a short 20mm return. I issued stop at the beginning of the 180mm move but it did not stop until after the 20mm return move. Not what I was expecting.

other than that it worked great

I don't know if this is a grblHAL issue or TSender. I've been trying to get an easily reproducible case of this but having some trouble. Several times now with long running jobs, TSender will exit and when I restart I get this message.

Closing the message box does nothing - I have to power cycle the Teensy to get it to run. The attached zip contains a long file (concentric circles as segments fr5000.cnc) that seems to reproduce the problem fairly often.
concentric circles as segments fr5000.zip

I have been running with aggressive buffering turned on and turned up feed rate override to 200%.

Some times TSender doesn't exit but just stops. Run time stops advancing and the start/stop/hold buttons do nothing. File Open doesn't do anything. Restarting TSender gets the MPG Mode message.

Note, I have not updated grblHAL to the latest changes.

I see how you can specify an IP address for grblHAL to the sender. There does not appear to be a mechanism to find the IP address. In grblHAL there are extensions to set all the network parameters but I don't see them in TSender. Do they become available under some circumstance? How does one make the initial connection when grblHAL is configured to use an Ethernet protocol. I am thinking that maybe an initial connection could be made via USB to configure? Is it possible to connect via USB and then switch to an Ethernet protocol?

I've looked at other motion controllers and they seem user unfriendly. Lots of comments on Ethernet config problems on CNCZone. Some involve directly connecting the PC to the controller via an Ethernet cable. Then changing the IP address of the PC to match the default IP address on the controller to connect and change the controller to a local router IP address. A number of them suggest a second Ethernet NIC and to stay directly connect to the controller. Given that most machinists are pretty far from network gurus, I think that is a poor approach. Having USB can make it pretty simple to set up.

Anyway, I think making this super easy for a user would be a huge win for grblHAL.

Perhaps the current set up is just a place-holder but they seem out of place with the rest of the UI. They are graphic in nature (as opposed to text everywhere else). Also, the vertical dots seem to imply movability - when you mouse over it the cursor changes to a 4 arrow move cursor though you can't really move it. Also, there is an expand down control/button in the lower right corner of that bar but it doesn't do anything.

Well, I installed VS and my computer has been BSOD'ing for a week. I think it has finally stabalized with some ram settings.

I tried to build the project and my newbness with both VS and c# are glaring. I will try to read some tutorials on c#. Any tips you might the build would be helpful.

here are the errors:

I finally got around to testing some probing. I setup for center finding but it kept saying "select type of probe" and it took me a while to figure out what it wanted. Maybe it should say "click probe type image to select probe movement" or something more descriptive.

This is potentially a very exciting feature. How does (will?) it work? Does TSender modify Z values as they are sent to conform with the height map? Does this require grblHAL support? i.e. could it work with legacy grbl systems? I think engravers would love this feature. PCB milling, too.

Are only linear height maps supported? I can see it useful for carving on curved surfaces.

Problem: clicking on probe tab causes sender to exit
To reproduce: Start G Code Sender. Verify it is working. Click on Probe tab.

https://github.com/vlachoudis/bCNC/blob/c144f28960aa03bad59132ae06ea9fe3f518dd4d/bCNC/CNC.py#L394

It looks like "compile" checks for the autolevel config and "splitLines" does the autoleveling. it requires you run setZero first in a bit of a wonky procedure.

https://github.com/vlachoudis/bCNC/blob/c144f28960aa03bad59132ae06ea9fe3f518dd4d/bCNC/CNC.py#L4550

Orient (next function after splitLines) is also interesting, you can pick a set of points with the camera and it will compensate position, for a double sided pcb you select drill holes and it does the x,y and skew correction for you.

A quick look at klipper reveals it actually has some tests!!!

guessing most goodies are here: It looks like the transforms, lookups, probe routines, config processing are here

https://github.com/KevinOConnor/klipper/blob/master/klippy/extras/bed_mesh.py#L59

I believe you can scan before each print or just use the stored mesh (what I do with my printer). It does scan the whole bed as defined in the config with configurable probe offsets.

the two modes are 'lagrange', and 'bicubic' documented here:

https://github.com/KevinOConnor/klipper/blob/46d0c6bdfc346ee6d3e6db704578679cb9fe55c5/docs/Bed_Mesh.md

I had a probe routine crash the GUI. After a reset I was stuck with this state. I was trying to send

g91 y-1

It would be handy to have a logging function so you can see what is sent, and what msgs grbl is sending.

up/down arrow to navigate command history in MDI window would be very nice. Return does not send so you have to click the button. return should send the current command.

It would be nice to have total GCode file line count shown in the UI. Perhaps next to run time. Grbl Panel does this and it is nice to get a sense of how big the program is. I use this to get a crude estimate of how long the program will take to complete.

Clearly an accurate completion prediction is desirable though I believe it is a very hard problem to solve.

This appears to be a bug in the keyboard manipulation of 4 digit numbers in text boxes. My example is for Id 25 (Homing search seek rate) but it appears to apply to all numeric text boxes..

• Open the Settings: Grbl tab.
• Select id 25 by clicking on the row in the table on the left (Homing search seek rate). Enter 5000 in the text box. Press save (or enter).
• note that the entry in the Value column changes to 5000
• press reload. Note the Value column entry has added .000 to the value

(the above is just to set the situation up to demonstrate the bug)

• select Id 25 as above
• place the cursor after the 50 in the 5000.000 shown in the text box on the right.
• delete a 0 so that the box shows 500.000 and press enter.
• note that the Id 25 Value column entry changes to 5000 (not .000 following).
• press save and then reload. the Value column entry has changed to 5000.000 and exit box on the right still shows 500.000
• expect results are 500.000 in the Value column entry for Id 25

This appears to be the case for all values edited, not just Id 25. Note that if you change the leading digit or completely rewrite the value, it works correctly.

Hello terjeio,
today i did some short probing tests and would like to tell you the results.
First of all I would like to suggest that you can jogging in the probing tab, would be very helpful in my opinion.
Now to my first probing tests: ;)
For all attempts no milling program was loaded and the basic settings were unchanged except the cutter diameter was 6mm.

Corner probing without z works without errors.

Z probing, the process is okay so far, milling cutter moves to the set height (5mm) is unfortunately not displayed in the dro.
Corner probing with z is the same, wrong dro display.
Think there is a mistake in z probing somewhere.
Entry in mdi is only possible once, e.g. G0 X2 Y2, the second entry, e.g. G0 X0 Y0 is no longer accepted.
Think the probing Tab is a very nice helper. +1:
Will continue the tests and report.

Cheers Stefan

The MDI box isn't keeping focus and I keep accidentaly jogging with the arrow keys vs using the command history. I almost think entering focus on the MDI box should be fully modal so you can't do anything else by accident. I don't think this was a problem in my initial fix. Happy to take a look myself if you've done something unintentionally here.

Hello @terjeio

I would like to ask you for the handling with M6 Commands in the G-Code.
I didn‘t test it in your Software, but I know the Workflow in the old Software that I was using.
In the Software I had to define a Position for the Tool length Sensor (TLS), where the length will be measured.

So the workflow was:

• Measure the length of the tool at the fixed Position
• Measure the height of the Workpiece (with the TLS)
• Start Milling will the first Tool

when the M6 Command appears, then the following happens:

• Spindle was Stopped and was driven to the specified Postion of the Sensor
• A Pop-Up says, which tool should be installed next
• After changing, the pop-up will be closed
• Tool length will be measured on fixed Position
• Machine goes to last Position of the Program, start the Spindle and begin to mill with the second tool

Can you please give me some advise, how to use your Software for Tool-Changing??

Not critical but wanted to report this.

My machine has the Y axis homing inverted and I run in $10=3 so I can use bCNC

When I enable soft limits I cannot jog, it throws error:15. I can move around in g53 and g54 with g90 g91 without having any errors thrown.

I can run bCNC and jog around. I can see that it is issuing $J=G91

with grbl-gcode-sender I can't see the command that is issued but here is the console output when trying to jog

jog error:

<Idle|MPos:-5.000,-130.000,-5.000|Bf:15,512|FS:0,0> error:15 <Idle|MPos:-5.000,-130.000,-5.000|Bf:15,512|FS:0,0> <Idle|MPos:-5.000,-130.000,-5.000|Bf:15,512|FS:0,0> <Idle|MPos:-5.000,-130.000,-5.000|Bf:15,512|FS:0,0> <Idle|MPos:-5.000,-130.000,-5.000|Bf:15,512|FS:0,0|WCO:-95.180,-58.882,-158.402>

if I issue $J=G91 y1 F200 it works

<Idle|MPos:-5.000,-129.000,-5.000|Bf:15,512|FS:0,0> ok <Jog|MPos:-5.000,-128.817,-5.000|Bf:14,512|FS:200,0> <Jog|MPos:-5.000,-128.151,-5.000|Bf:14,512|FS:110,0> <Idle|MPos:-5.000,-128.000,-5.000|Bf:15,512|FS:0,0>

Overall it looks good! I ran it with an esp32 running bart's port but not connected to anything else.

I see a tool selection, how do tool offsets work?

I also see "program limits", seems to be the boundaries of the current g-code file loaded.

wondering if you support extended firmware settings e.g bart's stuff. those don't seem to be editable assuming that is something on the backlog.

window resizing doesn't seem to work, assuming this is due to alpha stage. nothing moves on maximize so nothing is "broken" it just stays the fixed sizing.

any plans for a "terminal view". It is sometimes handy to see the responses in list out. Also it is nice to see the pin states when troubleshooting. If your stated update quickly it may not be an issue. UGS in particular seems to have a lot of lag updating the states. I really like having terminal view i most modes so it would be great to have a sizable full width row at the bottom you could use to toggle on/off in each tab. At a bear minimum it would be nice to see the MDI input on both the grbl and offset tabs.

regarding MDI, it would be great to be able to add "macros" and or console type wizards. For instance i'd like to make some canned routines for facing, probing etc. I was looking at mecode which seems like an interesting attempt to make gcode a bit higher level.

I don't see where the gcode viewer is supposed to render.

The camera needs to be plugged in before you start the app, restart with camera plugged in and it worked good with my C270. My pcb mill has a endoscope camera and bCNC has a camera offset function. It took a bit but I just noticed the camera offset setting boxes. I see a move offset button but it isnt' clear what it does. Camera zoom seems to be a good feature also when trying to center on .9mm holes. Docking the camera window would be a big win. I'm not a big fan of multiple windows. Centroid's software does this and it is one of the biggest bothers.

plans for jog buttons in the UI?

i ran some gcode that creates a error 33 and the sender seemed to ignore it. not sure if this is intended. bCNC halted with the same gcode.

you seem to need to hit stop to load a new gcode file.

i ran other gcode file that had a M8 command. It halted at that line. UGS's behavior is that it goes into "HOLD" and if you resume it will skip the offending line. This is great for things like M8 that you may forget to comment out if you forget to disable cooling in fusion. I also noticed the flood and mist toggles and wondered why grbl doesnt' support m8...

wondering how newbie friendly you want to be. I doubt most newbs can get work positions set without an MPG/pendant or buttons in the UI, they likely don't know the gcode move commands to put in the MDI.

Also assuming many folks will want to use standard keyboard keymapping to jog,

Hello terjeio,

testing your GCode-Sender and GRBLHAL, i am enthusiastic, works very well despite alpha status. I come from GRBLPanel and i am looking for a station that can also display my a-axis.
Unfortunately i have a little problem with G93 and G94 commands.
When i start GCode-Sender with GRBLHAL, G94 is activ. If i now enter G93 everything is fine and the g-code is running. Comes now a single G94 cammand error22 is coming, G94 a200 f1500 as a line works.
The other way around a single G93 command to G94 works fine.
Cheers,
Stefan

it would be nice to have a simple z probe which allows for probing Z and setting it in G54.

saw this was disabled, wondering about the thinking behind it?

This is a nice looking app and I'm thinking about using it for a project that I'm working on, but you currently don't have a LICENSE file describing your chosen license. Would you be able to specify which license you have selected for your code?

Thanks!

Used by F-Engrave and several other tools from Scorch Works.

After using GGS for a few days, I am quite impressed with the quality of it. Very well done. Program limits are a useful feature. I could have used this a couple of times in the past. Even with the arc issue, it's a great feature.

I usually use GRBLPanel but given that the owner has stopped supporting it, I've been looking for a replacement for GRBLPanel. I think this is it.

Some thoughts and questions:

• Com port, baud rate should be settable from the Settings: App panel. Would rather not have to restart with a command line option. Especially when using multiple boards.
• Visualization doesn't seem to work at all for me. Am I missing something?
• It would be nice to have jog and macro panels that don't obscure the main panel (i.e. allow them to be made permanent)
• Macro definition is not intuitive. You have to create the macro name and then edit it again to add the actual gcode. It would be more clear if there were separate new and edit buttons. New would essentially be the edit screen with the ability to fill in a name. As it stands, it seems like you are changing an existing macro when you create a new one. Also, there doesn't seem to be a way to delete a macro.
• How would it support an ethernet interface?
• On the grbl settings panel, I think there should be 2 modes - basic and advanced. Basic would show only the standard GRBL functions. Advanced, shows all. If basic was the default, grbl tutorials would be consistent with the initial view.
• It would be great if the MDI input and status showed up in the list of commands accepted by the grbl board.
• It needs a snazzier name than grbl-gcode-sender. It is an outstanding program and should have a outstanding name.

OK, one that is a huge ask and probably not happening anytime soon but I would love to see realtime GCode execution feedback. So 2 statuses: ok (received) and completed. I know it's a complex area and needs GRBL changes so it's hard(er).

Anyway, hope that's not too many things at once. GGS is already a fantastic program so please excuse my enthusiasm for making it even better.

Is it possible to adjust the 3d visualization to taste, as it appears in the title?
I upload two examples of cutting with trochoidal strategy.
Maybe improve performance using G5.
In the second (smaller, adaptive corner milling ) it seems that he is so close as to say "Houston, we are in trouble, I think we are going to collide, do not wait for us for dinner"
Hexagon Trochoid example_1.txt
Hexagon Trochoid example_0.txt
Congratulations and thank you!

I really struggled with the height map probing. My part is setup to flip on the X axis and X is setup on the centerline. The load from file boundaries does not seem to work correctly in this case.

The "top right" and "lower left" are also very confusing. I think it would be clearer to label them so it is clear which coordinates are X +/- and Y +/-.

It is also unclear what height and width are so clarifying with which is X and which is Y would be helpful.

I'm not sure how much work it is but it would be nice to see the heightmap over the gcode viewer display. I'm guessing you have planned to do this.

The tool offset setting does not seem to update. I was not able to get the Z height accurate and had to reset it after the probing routine. The height map did seem accurate though.

Finally, when doing PCB's it would be nice if the height map would stay in memory and if you load another file it would ask you if you wanted to apply the heightmap to the new gcode. For a double sided PCB milling where I'm doing 2 parts I would first load the drill file and do the height map probing. Then I'd load the traces cutout and apply the heightmap. Next I'd flip the part and re-run the traces cutout with the heightmap applied a 3rd time. Finally I'd run the board cutouts with the heightmap applied a 4th time. Since the spoil board degrades over time I'd not want to save it or have the potential of getting confused with an old one.

I'm guessing there are use cases where you want to keep it and have it auto-load but I don't see myself needing that. BCNC's dialogs allow for this but are very murkey and unclear in any use case.

I'm planning on giving it another go tomorrow but I had a few to many crashes and almost crashes for one day!