FEATURES variable in INI file RS274NGC section
Firstly, mad props to all the devs for making LinuxCNC such a piece of wizardry! I've been refitting my Chinese CNC router due to problems with the RichAuto hand-held controller, and have just recently got the machine to a useful working state.
While working on a Z-probe routine based around G38, I recognised that I should use custom variables in the machine INI file for things like the probe plate thickness and probing feedrate. It seems that in order to refer to INI file variables (and HAL values) from within G-code, you have to add FEATURES=12 to the INI file, in the RS274NGC section, a la:
[RS274NGC] ... FEATURES=12
I found this nugget in a forum/list discussion. I was thinking it would be helpful if this requirement was mentioned in the documentation on custom sections and variables:
FEATURES itself should probably also be described in the section on the RS274NGC INI file section:
(I'm using LinuxCNC 2.6 at present but the 2.7 and development docs are the same in this regard.)
Indeed, is there any reason not to enable FEATURES=12 by default? I was curious about this variable and wondered what possible values there are.
However, INI file data is static and these concerns are not (usually) an issue. So I think that setting the feature mask to 4 might be a good idea, but setting it to 12 ought to be something that is done deliberately and while understanding the consequences.
I can imagine that reading HAL signals from G-code would be tricky! I did find some more information here, which clarifies that accessing INI-file vars as named parameters is still experimental:
This will be a very useful feature once stabilised/merged.
Ha - and had I scrolled up just a little from the location from my last message, I would have found exactly what I was looking for:
So, as you say, FEATURES=4 would make sense in my case of just wanting to access INI file vars from G-code.
Still, is there a case for documenting this in the INI Configuration section? Even just an extra sentence or two and/or a link to the Remap docs would help. I'm happy to do some editing, if that's permissible.
screwtop wrote: Still, is there a case for documenting this in the INI Configuration section?
I think so.
You could edit the files on Github and submit a pull request, if you like.
Asciidoc syntax is descibed here:
Perhaps you could also confirm that I'm using the right markup for chapter and section references (the HTML docs I've built don't seem to come out with the correct inter-page links):
For another chapter:
<<cha:remap,Remap Extending G-Code>>
For a section in another chapter/page:
<<cha:remap#remap:ini-features,Optional Interpreter Features>>
or perhaps just
<<remap:ini-features,Optional Interpreter Features>>
screwtop wrote: Grand, thank you. I've cloned, branched, and made some changes - do I need privs to push the branch before I can issue a pull request? Computer says no, at the moment.
I don't actually know, I have never committed via Github, I have push privileges to the main repository.
I am pretty sure that anyone at all can send a pull-request, and one of the developers gets to accept or reject it.