I’m feeling very very close to having my homing issues resolved. This is what I’m using now for my start code:
; Custom Homing
; Fake line
$HY
G92 X0 Y0
G0 Y-5
G92 X0 Y0
$HX
G92 X0 Y0
G0 X-15
G92 X0 Y0
G1 X0 Y0 F1200
The two comments are to get around sandify combining the first two lines. It’s just too easy for me to forget to modify something manually after 
Making sure that $HY and G92 are on separate lines resolved most of the Y crashes. But there was still a small Y crash so I backed my offset off from -6 to -5 and now I’m not getting any more Y crashes.
But - running the steps manually I figured out what was wrong with the X. I needed another G92 after $HX before the G0. I forget exactly what I saw that made me think that was necessary - but I remember that in some situations there were cases were one of the coordinates was off at that point unless I did another G92. I think the work X was off even though the machine X was getting zeroed out from the $HX. But…adding that resolved the X crashes I was having.
And changing the initial move to a G1 to 0,0 solved the issue of the first move being hyper fast.
There’s just one remaining issue. If I’m in those first 15mm between workspace 0 and machine 0 where I’m in machine negative when I start a homing - then it still crashes.
As long as my X is above machine 0 everything works great. But a lot of my patterns end at X0 so starting another pattern immediately after results in a crash when homing.
Reading about fluidnc parameters and expressions just before I went to sleep it sure sounds like I could add something to detect that situation…it also sounds like the expressions would make it possible to do what I was musing about earlier and making it return to 0,0 by perimeter as part of and end code.
The one catch is it wouldn’t work when the machine is unhomed…but there’s a parameter to tell if G92 is applied or not so maybe a check for that…so maybe something like
o102 if [#5210]
; G92 is applied so we should be homed
o103 if [#5420 LT 0]
G0 X5
o103 endif
o102 endif
There’s probably a better way to check if the machine is homed…I’ll have to read the docs a bit closer tonight. But if I’m understaning it correctly that should basically say if G92 is applied and X is less than 0 then move to X5.
Some similar logic at the end could be used to check if xmax or xmin is closer to the current position and move towards the closest…and same for ymax / ymin to get to the border. Then just move to max/min positions along the border.
I’ll have to play with this tonight…the parameters and expressions seem really powerful even if they’re kind of basic. Heck - this could be used to do some basic looping like logo/turtle as well it seems.
I’m pretty sure there is…but it’s definitely a rabbit hole I’m not in a hurry to jump down or encourage anyone else to I do something similar in gulp on some legacy sites we maintain to copy packages managed by npm out of node_modules and into a deployable form when the site is built in a way that we can’t use something like webpack to package things cleanly. It’s a pretty ugly hack…and I’m sure there’s a better way but it solved the need at the time.
I definitely want to take a closer look at sandify’s code soon. I don’t do a lot with React though we did do a mobile app in react native last year so at least the basics are still fairly close to the front of my mind.
What I’m not sure about is how even if sandify was packaged so it could run as part of the fluidnc GUI how it could send completed gcode - I just haven’t looked at the fluidnc GUI to see what kind of hooks may be available for file transfer.
But…
You make a great point - I’m a big fan of the unix approach with small tools that do one thing and do it well - but can be easily piped/chained together to complete bigger tasks. Though that almost seems backards to me - like sandify would be more the “creative” side for generating paths while the part that would break off would be the “utlity” side for limiting and exporting gcode. But it’s your project and that’s just my impression of which part I associate with the name “sandify” 
I had never seen a more “visual” turtle graphics like the one you linked. Looks like it might be leveraging blockly? Side note - if anyone who is enjoying this kind of talk is looking for a nice rabbit hole of diversion the guy who created blockly has a really interesting “blog” with a buch of neat nerdy/geeky projects he’s done over the years: Neil Fraser: News
I was also never completely clear on the line between Logo and Turtle Graphics…even back in the 80’s when I was first introduced to them. I know Turtle graphics have been implemented in other languages as well - but given how I was introduced I always associate them as an offshoot of logo. In fact while logo was the second programming language I was exposed to I’m not sure I ever did anything other that turtle graphics with it. Though I do have some vague memories of creating interactive scripts that would prompt the user for inputs that it would use to modify the pattern instead of just hard coding the designs. But I did a lot more with basic than I ever did with logo…then I was introduced to Pascal and shortly after I got my hands on and early 0.98 SLS linux distro and C came into the picture followed closely by bash and zsh and Perl…
Woah…ok…back on track.
Thinking about turtle graphics more and refreshing my memory on it and looking at the parameters / functions that fluidnc supports and I’m wondering if I’d be better off just digging deeper into gcode directly. At least for my own personal itch.
Though it does seem like a simple utility with a easy to learn language would be a nice tool for beginners. Though I also feel like it’s getting close to reinventing the wheel. I suspect an hour or two with google and I’d find someone already created something that does some type of turtle graphics type of approach to creating SVG’s which is 90% of what I’m envisioning…
And the generated SVGs use polylines which 
