grblHAL / core

grblHAL core code and master Wiki
Other
305 stars 74 forks source link

When the maximum stroke of the axis is greater than 88000, there will be no action in homing. #380

Closed hanke-cnc closed 8 months ago

hanke-cnc commented 8 months ago

Although my default setting of the maximum axis travel of 99999 is unreasonable, this bug caused me trouble for a long time.

terjeio commented 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.

hanke-cnc commented 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.

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

terjeio commented 8 months ago

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.

hanke-cnc commented 8 months ago

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

terjeio commented 8 months ago

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.