Default Core Options #145
Replies: 4 comments 5 replies
-
I have already moved most legacy build options to $-settings. The few that remains is not so easy to handle as settings?
I do not want to sanction the use of NO switches by changing the current default, what I can add is a setting for enabling them with all switches disabled as default. This will also solve the safety door issue.
True, and I did not want to add that as a default option as I have not tested it myself. It also adds new settings that can cause sender issues? If tested and found ok by others I can enable this as default but then perhaps dependent on compatibility level? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I expected you to say that about NO switches... Not that I disagree with the sentiment, at least when it comes to limit switches. How would the setting for enabling work? Unfortunately, for people to bring up a grblHAL system outside of a CNC machine without hooking up switches, they wind up having to invert EStop, Door, Hold and Start. It is the number 1 support issue by a wide margin because people want to verify their controller before putting into the machine where it is harder to deal with. I have dreams about $14=78 (though 70 would do it given that Door is not in the default set). |
Beta Was this translation helpful? Give feedback.
-
|
There is nothing to stop you from changing the default for prebuilt binaries if it is users of those that results in support requests.
A new $-command? $enableswitches? A warning at startup if not enabled? I do not know if this is a good idea... |
Beta Was this translation helpful? Give feedback.
-
|
Providing a test build could be another option? |
Beta Was this translation helpful? Give feedback.
-
|
Sure, I can do anything I want but I'm trying to stay as close to the default distribution as possible. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so the only option is to default to NO for control signals? |
Beta Was this translation helpful? Give feedback.
-
|
Or, I just make sure the customers understand the issue. Like I said, I agree with being aggressive about NC inputs - it reduces EMI related problems which are harder to diagnose and resolve. |
Beta Was this translation helpful? Give feedback.
-
|
Add a notice in your packages then? And also one on the grblHAL main page? Add a FAQ to the Wiki as well? |
Beta Was this translation helpful? Give feedback.
-
|
Yeah. I will put together a wiki entry - First Run Settings (or some such
title).
…On Fri, Dec 18, 2020 at 1:55 PM Terje Io ***@***.***> wrote:
Add a notice in your packages then? And also one on the grblHAL main page?
Add a FAQ to the Wiki as well?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#145 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD6NUTX3545UT5CNFNAUJY3SVPFVXANCNFSM4VBK27YQ>
.
|
Beta Was this translation helpful? Give feedback.
-
Having multiple build options is confusing for the average user and for non-programmers is a bit daunting to have to go and build a version with the options they want. Ideally, we would have an automated build system like Marlin. But in the short(er) term, it makes sense to me to avoid having build options where possible - eg turn them on by default. Most grblHAL target processors have a lot of Flash and RAM memory. I am thinking about those that don't require driver code and do not change basic operations. Backlash Compensation and Safety Door are two examples. There may be others.
I believe Safety Door was turned off because it was causing confusion but it is a simple thing to deal with and EStop not set up presents the same symptoms. Maybe the default should have the pin inverted so it starts out as an NO input to minimize initial confusion. (Perhaps EStop should too?)
Best I can tell, Backlash Compensation is off by default because it was never in the gnea core. It looks to be innocuous when set to zero for each axis (technically <= 0.0001f), mostly just adding an extra test for it being on in the stepper driver ISR. Perhaps it needs more testing? I have several customers that are running with it enabled and I have it turned on for my standard builds. Since most users will probably never set BL Comp ($160-$165) to anything other than 0.0, it seems an easy decision.
Beta Was this translation helpful? Give feedback.
All reactions