Thanks Larry, however stick with clearing your own workload for now. I’ve started another thread (Installing limit switches (not homing switches) ) which has already had a likely solution posted which I’ll explore a little more.
It appears this is something thats already supported through GRBL and there are individual pins on the controller already allocated as x, y & z limits.
If you have any thoughts on this (once you’ve got yourself some free time), I’d most certainly value your input, but as someone who is often drowning under work myself, please don’t spend time on this unless you’re intending to use the plans yourself…
Not sure if it’ll make things easier or harder for you, but I’ve found that using “Universal GCode Sender” (GitHub - winder/Universal-G-Code-Sender: A cross-platform G-Code sender for GRBL, Smoothieware, TinyG and G2core. ) has been more reliable (thus far anyway) and it allows a lot more control (macros, using the keypad for ‘jogging’ etc) than I found possible with Easel. Mind you, if you just want to cut a square, circle or triangle for setting up and tuning the machine, Easel is probably quickest.
The only issues I’ve had with UGS is:
- If I reboot the computer running UGS, I need to connect the Controller and then refresh the list of ports before it will recognise the Controller - simple but not intuitive.
- To reset tool zero is easy, theres a button for that. To reset machine zero, I need to close and the re-open the ports in UGS.
I’m using Carve (expensive but nice), MeshCam and Easel for generating GCode and an old Mac Mini to run UGS and send it to the Controller.
Happy to assist if any of this sounds useful to you.
David.