Hey tKC,
I quoted what was already said in a previous thread, so it doesn’t apply to a machine mounted on the rolling or the folding stand. It’s clear you don’t build an anti-torsion box made of 12 mm birch plywood on top of these (usually) 
Homing is done only once after machine startup. It is not needed after that, and as explained below, should be avoided.
Homing does not need to be over the usable workarea. Its purpose is to let the machine now where its X, Y and Z carriages are, since they could have been moved while the machine was off. See also ➪ Homing vs. Zeroing.
In the ‘tool-change’ routine, that is run every time a tool-change event (M6 command) is encountered in the g-code toolpath, it returns to this “home” position too, since the leftmost, frontmost and topmost position is the most comfortable position to manually change the bit. However in ➪ my ‘tool change’ routine, it does not perform the ➪ stall homing (=bumping against the travel end) (➪ see also here), again every time, but is just moving there, without stall homing, because stall homing is not accurate and will never home at the same position, so you would loose position accuracy after each tool change. Therefore, my ‘tool-change’ routine goes to this home position not with the homing command, but by (G53 – Moving in machine coordinates) with the commands:
G53 G0 Z0
G53 G0 X0 Y0
Generally, for position repeatability even over power shutdowns, it would be necessary to ➪ retrofit limit sensors to have accurate, repeatable homing, instead of using the generally not accurate stall homing. The buildbotics-derived Onefinity and the Buildbotics controllers support the connection of limit sensors.