If you’ll overlook the length of this post, these might help you and perhaps some others, even if they are off the topic a little. Trying to figure out the workarea dimensions ties in with the remainder of these common starting troubles. I reported these to the 1Finity team, but through no fault of theirs, the way I worded these previously probably caused them to dismiss my bug report.
In certain scenarios, clicking the ProbeZ test may incorrectly trigger G-code soft-limit exceeded errors when trying to play code. If the z soft limit is exceeded during the internal pre-test, the error dialog can leave the webcode in a state at which it incorrectly reports the same error when ProbingZ again, even if the user has deleted all GCode afterward and loaded new GCode that does not exceed the soft limit in any way.
The internal ProbeZ pre-test currently incorrectly tests against the current z height of the router/spindle before the probe initiates movement, allowing the user to overcome seeing the soft limit error dialog in some cases by moving the z height slightly higher before clicking ProbeZ. Having the bit’s tip closer to the probing plate can push the pre-test into failure mode, which is not related to the probe/router/spindle height hardware limits in any way. [So for you, try starting with a higher z height for your router or spindle before pressing ProbeZ. You can only push it up a certain amount however, as the ProbeZ test will abort if it has to move too far downward to contact the metal plate.] The internal G-Code limit-exceeded pre-test code likely belongs at the beginning of the play button routine instead – something the developers would need to adjust.
ProbeZ can also fail to exit correctly where it displays the ‘don’t forget to put away the magnet’ code path in certain cases during these issues. This will lock the user from having access to moving the motors via the USB game controller. A workaround is to press the +z or -z buttons on the webpage. This will restore gamepad control. The code needs a little rework help there too.
In my early usage days, it wasn’t obvious to me whether I should press Stop, Ok, or Clear in the ‘soft limit exceeded’ dialog when those choices were presented. Sometimes I did not press the Stop button. I don’t know if that was the trigger, but once, I subsequently ended up with my system running a lengthy program of G code that could not be stopped via the standard stop button afterward. I hope the developers will add a fail-safe run=false boolean that is set by the stop button and check that each execution loop to help trap race conditions and other potential bugs.
I’ve also had a stepper motor quietly run continual miniscule steps where moving the USB gamepad controls made no difference.
If an error dialog occurs while a remote 1Finity webpage is open, the two instances – the remote webpage and the machine’s output – will be out of sync when one page’s Stop or Ok(/Clear) button is pressed.
A timeout resulting in Ah Snap can occur when the remote web-based page is open (and inactive) for lengthy period of time. The remote will not display the issue of the loss of connectivity. A reload of the 1Finity ‘base unit’ Ah Snap webpage will then lead to incorrect states. If the programs resynced all activity state, variable states, and any necessary (re)initialization scenarios after an ah-snap, that would help.
When Ah, Snap occurs due to a session timeout, pressing Reload may leave the user in jogging mode and may leave the UI without a delete button for existing GCode.
Running the G-Code and pressing stop midway can result in a condition where the home limit may shift considerably – possibly from a race condition where the user is moving the y-axis immediately via the gamepad after(?) or maybe during(?) the press of stop. More testing is required to identify the cause definitively – that just happened to be what I inadvertently did when I soft-stopped fast y-axis movement mid-travel. I was able to move the router/spindle base further away (from home) but moving it back toward home stopped at the exact same point, so a large shift in the home y-limit had occurred.
Since the Hardware Emergency Stop button will leave the user without Z control if a Makita router bit is deep inside a cut when the button is depressed, the user can get stuck in a potential fire situation. Since the hardware emergency stop button requires a reboot of the entire system to regain control, and the reboot time is significant during that critical time where the user may need to move the spindle or router vertically from a piece, it’s worth a share. Perhaps one quick press of the hardware emergency stop button should act as a software stop (after the bug that allows the standard stop button to be ignored is fixed), and two or more presses or a hold of the hardware emergency stop shuts down the system entirely? Maybe…maybe not, but letting everyone know that the software stop button should be the go-to button in most cases for router users is needed. Reaching in to turn off the Makita may pose the risk of serious injury if the workpiece split or became loose and unstable. Adding an easy-access, appropriate amp-rated switchable power extension for the Makita power cord next to the hardware stop button, or just knowing you should be ready to pull the plug manually in a crisis, and train your mind to do so, might save a limb or a life. Maybe a future design could offers a software-switched outlet on the controller so the hardware emergency stop stops everything?
The YouTube tutorial on ‘setting up the machine and first bootup’ omitted the mention of the twist and pull of the emergency stop button for those that follow those instructions.
I know normally one wouldn’t put all of this together in one post, but I feel it might help everyone to have it all consolidated.