Hi Steve,
meanwhile I've made this configurable as I laid out and it currently looks like
below. It currently doesnt support redefining existing codes, and aliasing them
to other codes to retain the original G/M-codes.
let me tack on some questions:
- does the set of potential parameter words [A-KMNP-Za-kmnp-z] make sense?
- is there a sensible use case for G-codes from other modal groups than group 1
(motion)?
- any idea how useful the 'redefining existing codes' as opposed to 'only allow
additional codes' feature would be?
Wrt the set of pre- and postconditions I dont really see yet how to do this.
What I currently do is: if I see a user-defined M/G-code I pretty much skip all
tests and rely on the argspec and the user knowing what she does. This is a
long rope to hang oneself, I guess.
I plan to enable Python subroutine bodies as well eventually and that may open
the path to better configurability - introspection in gcode subs is better that
it was but a long way from replacing the current C code.
-Michael
----
current .ini example
# define custom G and M codes
#
# syntax: GCODE=<number>,<modal group>,<argument spec>
#
# argument spec: 0-n characters of the class [A-KMNP-Za-kmnp-z]
# an uppercase letter for each required parameter 'word'
# a lowercase letter for each optional parameter 'word'
# superfluous words present in the current block which are neither required
nor optional cause an error message
#
# an 'S' requires speed > 0
# an 'F' requires feed > 0
[CUSTOM]
# currently supported modal group: 1
# G88.1 requires all of XYZ words, and feed > 0; optionally takes r
GCODE=88.1,1,XYZrF
# currently supported modal groups: 5,6,7,8,9,10
MCODE=75,5,PQ
MCODE=76,6,PQ
MCODE=77,7,PQ
MCODE=78,8,PQ
MCODE=79,9,PQ
MCODE=80,10,PQ
MCODE=250,10,xyzpq
Parameter passing is different from normal o-word sub calls as the positional
parameter scheme doesnt cope with optional parameters - all present parameters
words as per argspec are added as local variables during the call. The
procedure may test with EXISTS() for optional parameters like so:
o<m250> sub
(debug, in M250.ngc)
o<m250> if [EXISTS[#<x>]]
(debug, X param set: #<x>)
o<m250_havex> endif
o<m250_havey> if [EXISTS[#<y>]]
(debug, Y param set: #<y>)
o<m250_havey> endif
o<m250_havez> if [EXISTS[#<z>]]
(debug, Z param set: #<z>)
o<m250_havez> endif
o<m250_havep> if [EXISTS[#<p>]]
(debug, P param set: #<p>)
o<m250_havep> endif
o<m250_haveq> if [EXISTS[#<q>]]
(debug, Q param set: #<q>)
o<m250_haveq> endif
o<m250> endsub
m2
Am 25.04.2011 um 16:30 schrieb Stephen Wille Padnos:
> Michael Haberler wrote:
>> I'm now looking seriously into creating custom g/mcodes.
>>
> Excellent!
>> Your proposal on the wiki assumes every parameter word is made accessible to
>> the subroutine, and it's the sub's responsibility to figure what makes sense.
>>
>> My idea would rather be a check during conversion - before calling the sub -
>> driven by a parameter spec as follows:
>>
>> # define custom G and M codes
>> # syntax: GCODE=<number>,<argument spec>
>> # argument spec:
>> # an uppercase letter for each required parameter 'word'
>> # a lowercase letter for each optional parameter 'word'
>> #
>> [CUSTOM]
>> GCODE=88.1,XYZR # G88.1 requires all of X,Y,Z,R to be present
>> GCODE=88.2,XYpq # G88.2 requires X,Y and takes optional P and Q
>>
>> MCODE=290,PQ # M290 requires P and Q
>>
>> Any required parameters would be available as '#<X>' or some variant thereof.
>> Optional parameters could be tested for with the EXISTS(#<P>) function.
>>
> Something to consider: what about a routine that needs one or another
> word from a group, but not necessarily all of them? For example, G0 or
> G1 require at least one axis word to be present, but as long as there's
> at least one, there may be up to 9 (XYZABCUVW).
>
> The next complex case is one where you may need one or another set of
> words, as used in circles. You can specify R or IJK, but not both.
> This is even trickier because the active plane determines which of IJK
> are valid.
>
> It may be possible to specify all of these options with regex/glob-like
> syntax:
> [XYZABCUVW] means any or all axis words.
> {R,IJK} would be either R or I and J and K
> {R;[IJK]} would be R or at least one of IJK
>
> I'm not sure how to specify a dependence on the active plane, or a
> dependence on some other machine state I haven't thought of. I guess
> another comma-separated field (or set of fields) could work:
> GCODE=88.1,plane,[XYZ]{R;[IJK]}
>
> There is actually a full set of preconditions and postconditions for
> every G-code. To be able to fully re-define G-codes, it may be
> necessary to figure out how to specify these in the ini (or other
> config) file.
>
> - Steve
>
>
> ------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been
> demonstrated beyond question. Learn why your peers are replacing JEE
> containers with lightweight application servers - and what you can gain
> from the move. http://p.sf.net/sfu/vmware-sfemails
> _______________________________________________
> Emc-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
