Named variables are documented as having the form #, but in some contexts, the leading < is not actually checked. Specifically, the following is accepted but probably shouldn't be:
~~~~
$ ./bin/rs274 -g
executing
1 N..... USELENGTHUNITS(CANONUNITSMM)
2 N..... SETG5XOFFSET(1, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000)
3 N..... SETG92OFFSET(0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000)
4 N..... SETXYROTATION(0.0000)
5 N..... SETFEEDREFERENCE(CANON_XYZ)
READ => #abc>=7
READ =>
~~~~
@cradek stated on IRC:
~~~~
14:36:23
14:36:57
14:37:16
~~~~
It does not seem possible to REFER to such a variable (Z#abc>, Z[#abc>], Z# and other possibilities that might refer to the created variable don't work.) This means the impact of fixing it is low: it would only affect the assignment of a variable that could never be referred to. It also brings the implementation in line with the documentation.
评论 (4)
#2 - SebKuzminsky 于 2018-03-20
Good find!
The docs say:
~~~~~
Named parameters must be enclosed with < > marks.
~~~~~
So I agree that this is a bug in the interpreter. I think we should fix it in 2.7 even though it might break existing g-code programs, because any such g-code programs are wrong (ie are in violation of the syntax of our g-code language).
#3 - jepler 于 2018-03-20
Fixed by #425.
#4 - SebKuzminsky 于 2018-07-29
This was fixed in March.
#1 - cradek 于 2018-03-20
Then a little later I figured out more:
`` the character after # can be any isalpha and it still works as if that character is <
14:39 #Qabc>=1 #=1 these are equivalent so #O=3 defined the named param "`
14:39
14:39
14:39
14:40
So it is possible to refer to the variable in your example as #
and maybe other ways too. I agree it's unlikely fixing this will break any programs. I also suspect that<` shouldn't be allowed as part of a variable's name.