Parameters: now also alpha-numeric

[Henner Zeller]

Hi,
I didn't have much time tonight, but added a way to also have
alphanumeric parameter names. This is certainly outside the NIST
standard, but results in more readable code in particular if more
variables are involved.
src/testdata/polygon-24-vs-arc.gcode

Cheers,
H.

[Hartley Sweeten]

Henner,

Sounds like a great add. I still need to pull the latest HEAD to take a look.

I need to talk to our CNC operators to see if the Fadal or HASS support
named parameters and if so how they are handled.

The only thing I found on the web about them is at:
http://linuxcnc.org/docs/html/gcode/overview.html#_named_parameters

That page says that named parameters must be enclosed with < > marks.

#<named_parameter> is a local named parameter which only has scope where
it is defined.

#<_global_named_parameter> is a global named parameter. They have scope
within the entire program, same as regular numeric parameters. These would
probably not be discarded, not sure.

Both types are not persistent.

This is also mentioned on the page:

"Named parameters spring into existence when they are assigned a value for the
first time. Local named parameters vanish when their scope is left: when a subroutine
returns, all its local parameters are deleted and cannot be referred to anymore.
...
Global parameters, as well as local parameters assigned to at the global level, retain
their value once assigned even when the program ends, and have these values when
the program is run again."

The EXISTS function tests whether a given named parameter exists.

We don't currently support subroutine calls so I think named parameters should be
discarded:
1) when the file is complete
2) when a "program end " is parsed
3) when a port connection is closed

LinuxCNC also has "predefined named parameters". We could support something
like this in the paramsfile, a separate "named" paramsfile.

The site above lists the built-in global named system parameters in LinuxCNC.
It appears most of them are used to query the current mode as set by various
G/M codes.

Regards,
Hartley

[Henner Zeller]

On 15 September 2016 at 09:40, Hartley Sweeten

<Hart...@visionengravers.com> wrote:
> On Thursday, September 15, 2016 12:17 AM, Henner Zeller wrote:
>> Hi,
>> I didn't have much time tonight, but added a way to also have
>> alphanumeric parameter names. This is certainly outside the NIST
>> standard, but results in more readable code in particular if more
>> variables are involved.
>> src/testdata/polygon-24-vs-arc.gcode
>
> Henner,
>
> Sounds like a great add. I still need to pull the latest HEAD to take a look.
>
> I need to talk to our CNC operators to see if the Fadal or HASS support
> named parameters and if so how they are handled.
>
> The only thing I found on the web about them is at:
> http://linuxcnc.org/docs/html/gcode/overview.html#_named_parameters
>
> That page says that named parameters must be enclosed with < > marks.

Uh, ok, I didn't do that, mine are just plain, such as #foo. Only
requirement is, there needs to be a space behind in case of ambiguous
interpretation. Possibly they do this because these parameters can
have spaces in them ?
Possibly easy to add, but BeagleG should also do the right thing in
supporting that without the ugly <> brackets around.

(I get the impression, that people involved in GCode standards make an
active attempt to always come up with the _most_ ugly solution...)

>
> #<named_parameter> is a local named parameter which only has scope where
> it is defined.

We don't really have a concept of local scope yet (no functions), but
if we do, then we could distinguish if the parameter has a leading
underscore (and then write it into the global map), vs. none (write it
to the local map).
Of course, since local scopes are ephemeral, they will not be written to files.

>
> #<_global_named_parameter> is a global named parameter. They have scope
> within the entire program, same as regular numeric parameters. These would
> probably not be discarded, not sure.
>
> Both types are not persistent.

BeagleG persists all of these currently. Well, the global scope anyway
(which is currently everything, because we don't have global scopes).

>
> This is also mentioned on the page:
>
> "Named parameters spring into existence when they are assigned a value for the
> first time. Local named parameters vanish when their scope is left: when a subroutine
> returns, all its local parameters are deleted and cannot be referred to anymore.

Yep, once we have subroutines, we'd just store a map on the stack.

> ...
> Global parameters, as well as local parameters assigned to at the global level, retain
> their value once assigned even when the program ends, and have these values when
> the program is run again."
>
> The EXISTS function tests whether a given named parameter exists.
>
> We don't currently support subroutine calls so I think named parameters should be
> discarded:
> 1) when the file is complete

I think we shouldn't distinguish that from other numeric parameters:
if they are used as global variables, we should store them.
So the ones with underscore. Because above it says
"Global parameters .. retain .. and have these values when the program
is run again."

So we can be selective in what parameters are written.

> 2) when a "program end " is parsed
> 3) when a port connection is closed

That is a good point. Part of the 'program end' and 'port closed'
routine should be to Save all the parameters that should be saved, our
map cleaned, and then re-read from the file to have a fresh set of
defaults.

>
> LinuxCNC also has "predefined named parameters". We could support something
> like this in the paramsfile, a separate "named" paramsfile.

yes, also a concept of a 'const' parameter. So a parameter that we
might set in the configuration file, but that shall not be modified by
the program. The entry in the file can look like

const:answer_to_life_universe_and_everything 42

>
> The site above lists the built-in global named system parameters in LinuxCNC.
> It appears most of them are used to query the current mode as set by various
> G/M codes.

Sounds good.

-h

>
> Regards,
> Hartley
>
> --
> You received this message because you are subscribed to the Google Groups "beagleg-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev...@googlegroups.com.
> To post to this group, send email to beagl...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/SN1PR0101MB156584C53A10A05D335FE368D0F00%40SN1PR0101MB1565.prod.exchangelabs.com.
> For more options, visit https://groups.google.com/d/optout.

[Hartley Sweeten]

On Thursday, September 15, 2016 10:26 AM, Henner Zeller wrote:

> On 15 September 2016 at 09:40, Hartley Sweeten wrote:
>> The only thing I found on the web about them is at:
>> http://linuxcnc.org/docs/html/gcode/overview.html#_named_parameters
>>
>> That page says that named parameters must be enclosed with < > marks.
>
> Uh, ok, I didn't do that, mine are just plain, such as #foo. Only
> requirement is, there needs to be a space behind in case of ambiguous
> interpretation. Possibly they do this because these parameters can
> have spaces in them ?

Who knows... That is just how LinuxCNC appears to handle the named
parameters.

> Possibly easy to add, but BeagleG should also do the right thing in
> supporting that without the ugly <> brackets around.

I agree. Using '#param_name' seems more logical than '#<param_name>'.

We should probably allow the '< >' but simply ignore them.

> (I get the impression, that people involved in GCode standards make an
> active attempt to always come up with the _most_ ugly solution...)

Didn't you say you found a GCode book? Does it say anything about the
parameters?

The "NIST RS274NGC Interpreter - Version 3" spec is dated August 17, 2000.
I don't think it has any newer updates so as long as we support what it says
is the "standard" I think any "enhancements" are free game. That appears
to be what all the big CNC manufacture do (Fadal, Fagor, HAAS, etc.).

I believe LinuxCNC used the NIST Interpreter as the starting point for how
it supports GCode. They then enhanced it as users requested features.
The src/emc/rs274ngc/* code has a lot of similarity to the rs274ngc code.
I think Machinekit is fork of LinuxCNC and has the same similarity.

Regards,
Hartley

[Henner Zeller]

On 15 September 2016 at 12:02, Hartley Sweeten

<Hart...@visionengravers.com> wrote:
> On Thursday, September 15, 2016 10:26 AM, Henner Zeller wrote:
>> On 15 September 2016 at 09:40, Hartley Sweeten wrote:
>>> The only thing I found on the web about them is at:
>>> http://linuxcnc.org/docs/html/gcode/overview.html#_named_parameters
>>>
>>> That page says that named parameters must be enclosed with < > marks.
>>
>> Uh, ok, I didn't do that, mine are just plain, such as #foo. Only
>> requirement is, there needs to be a space behind in case of ambiguous
>> interpretation. Possibly they do this because these parameters can
>> have spaces in them ?
>
> Who knows... That is just how LinuxCNC appears to handle the named
> parameters.
>
>> Possibly easy to add, but BeagleG should also do the right thing in
>> supporting that without the ugly <> brackets around.
>
> I agree. Using '#param_name' seems more logical than '#<param_name>'.
>
> We should probably allow the '< >' but simply ignore them.

Yep added now. Within <> brackets it is allowed to have spaces (which are then
ignored), essentially how the LinuxCNC doc says.

>
>> (I get the impression, that people involved in GCode standards make an
>> active attempt to always come up with the _most_ ugly solution...)
>
> Didn't you say you found a GCode book? Does it say anything about the
> parameters?

Good point, I'll consult that to see if they say anything about that.

Sounds like we're way out into 'vendor specific extension land' here.