Using grblHAL on a system that does not have limit switches

[dcoones]

I have successfully compiled grblHAL to run on an Arduino Due, which is pretty good going for me.

However, my machine does not have (has never had) limit switches installed. I have actually been using the machine for several years using Tinyg on the Due and communicating via Chillipeppr. All has worked well, but I decided to 'upgrade' because I want to use the laser features in grbl.

Can anyone explain how to set up grbl so that, when compiled, it ignores the limit switch inputs? I have not been able to find this in any other threads, and I don't want to bork anything.

[terjeio]

Leave settings $21 (hard limits enable) and $22 (homing enable) at 0 (the default value) and limit inputs will be ignored.

[dcoones]

Thanks for such a fast response! But it's odd, because I have not changed any of the defaults. The only thing I did was set the following in my_machine.h.

#define BOARD_TINYG2_DUE
and
#define Y_GANGED 1

I have changed nothing else, it is all default. And I am confident it is using the Due pinout.

It does not ignore the limit switches, although I can see both $21 & $22 in config.h as

($21)
#if !defined DEFAULT_HARD_LIMIT_ENABLE || defined DOXYGEN
#define DEFAULT_HARD_LIMIT_ENABLE Off
#endif
#if !defined DEFAULT_CHECK_LIMITS_AT_INIT || defined DOXYGEN
#define DEFAULT_CHECK_LIMITS_AT_INIT Off
#endif

and ($22)
#if !defined DEFAULT_HOMING_ENABLE || defined DOXYGEN
#define DEFAULT_HOMING_ENABLE Off // Default disabled. Set to \ref On or 1 to enable.
#endif

Could DEFAULT_HARD_LIMIT_ENABLE, DEFAULT_CHECK_LIMITS_AT_INIT, and/or DEFAULT_HOMING_ENABLE get defined/set somewhere else? I've not been able to find it. But I am not the best at looking through code.

Also, could the sender software be setting these without asking first? It starts up in the alarm state with all limits triggered in two different sender programs I've used.

By the way, it snot a hardware problem. Connecting the relevant inputs to ground, simulating an NC switch, does solve the problem, but its a bodge and I'd rather configure the software for how I'm using it rather than tricking it.

[terjeio]

The sender may not ignore them even if the controller does. Either connect inputs to ground or invert them.
The current value of a setting will be output if you send $<setting> where <setting> is the setting number.
Note the default values for settings in config.h is typically only set when flashing for the first time, if changing any and recompile/reflash require a settings reset.

[dcoones]

Ok, thanks for that. I put some dummies in and all is well.

Your assistance is greatly appreciated.