Closed hanke-cnc closed 8 months ago
This is likely a feature not a bug. Legacy Grbl and grblHAL uses single precision math and storage for float values and (IIRC) somwhere it is specified in the legacy Grbl documentation that the max reachable area is around 10m. I have longer term plans to make a core version that will use double precision math, limited to the MCUs that has a double precision FPU - currently iMXRT1062 and STM32H7xx drivers. That will solve this and other related issues that single precision floats presents. Until then keep values within a reasonable range or switch to controller firmware that is able to handle such large sizes.
This is likely a feature not a bug. Legacy Grbl and grblHAL uses single precision math and storage for float values and (IIRC) somwhere it is specified in the legacy Grbl documentation that the max reachable area is around 10m. I have longer term plans to make a core version that will use double precision math, limited to the MCUs that has a double precision FPU - currently iMXRT1062 and STM32H7xx drivers. That will solve this and other related issues that single precision floats presents. Until then keep values within a reasonable range or switch to controller firmware that is able to handle such large sizes.
I don't think this is a bug either, but at least the setting of the maximum value should be limited, otherwise an error is returned, this problem made me waste some time to find out the problem
I don't think this is a bug either, but at least the setting of the maximum value should be limited, otherwise an error is returned, this problem made me waste some time to find out the problem
A potetial issue with limiting the setting is that other settings may affect what the limit actually is. If someone could explore this and come up with reasonable value I am all ears. There are tons of stuff that should be done to make grblHAL better but I do not have the capacity to do everything myself, I spend far too much (unpaid) time on this project already...
I am sorry for having wasted some of your precious time.
I don't think this is a bug either, but at least the setting of the maximum value should be limited, otherwise an error is returned, this problem made me waste some time to find out the problem
A potetial issue with limiting the setting is that other settings may affect what the limit actually is. If someone could explore this and come up with reasonable value I am all ears. There are tons of stuff that should be done to make grblHAL better but I do not have the capacity to do everything myself, I spend far too much (unpaid) time on this project already...
I am sorry for having wasted some of your precious time.
Well, this question is actually not very important. I think the way to make grblHAL better is to move towards paid closed source? The free version can get some basic functions, which is enough to satisfy most ordinary users. Advanced commercial functions can be paid for. Customized? Or make your own CNC system for sale, okay, here are some random ideas of mine
I think the way to make grblHAL better is to move towards paid closed source?
Firstly making it closed source will be against the license of the original Grbl code. Secondly it will require funding - hiring staff to help with coding, documentation, marketing and what not... So it will not happen.
Selling related stuff such as controller boards etc. may generate an income stream but likely not enough to hire somebody to do it - doing it myself will only lead to me having even less time for coding.
Although my default setting of the maximum axis travel of 99999 is unreasonable, this bug caused me trouble for a long time.