PathPilot mods

[Fenichel]

This post is mainly directed at @sharmstr, because he seems to be the forum member who has most boldly made changes to PathPilot, but other forum members are of course invited to comment. I am interested in changes to PathPilot that would allow for greater situational awareness on the part of gCode programs. Also, I'm interested in finding ways of providing gCode programs with higher-bandwidth input than can be provided by the 4-bit USB I/O channel. All of my thinking is based on my experience with a 770 mill, but the ideas are generalizable to other machines. I don't know how hard these changes might be to make.

Situational awareness. What I mean by "situational awareness" is fairly simple. All modal data that are known to PathPilot should be available to gCode programs in system parameters.

For example, PathPilot gets told whether the spindle is in its high or low speed range, and it uses this datum to control the spindle motor in response to speed settings. I have a warmup program that I run when the spindle speed range is low; among its first few lines are

M1 (abort if not in LOW RPM range)
#<_MinRPM>   =  175
#<_MaxRPM>   = 3250

and I have a separate warmup program that I run when the spindle speed is high, identical except for these lines. I shouldn't have to have two programs. If PathPilot's idea of the current speed range were available in a read-only parameter, then the warmup program could include something like

    ;  Set speed range
    o 2000 if [#<_SpeedRange> EQ 0]   ; hypothetical read-only parameter
        M1 (abort if not in LOW RPM range)
        #<_MinRPM>   =  175
        #<_MaxRPM>   = 3250
    o 2000 else                     ; *high range
        M1 (abort if not in HIGH RPM range)
        #<_MinRPM>   =   525
        #<_MaxRPM>   = 10000
    o 2000 endif                    ; range selected

For that matter, my assignments to the #<_MinRPM> and #<_MaxRPM> parameters shouldn't be necessary; those data are already known to PathPilot too.

Some of PathPilot's gCode commands make modal settings that can be changed, but not interrogated. For example, the P and Q arguments of G64 make settings that cannot be interrogated. This becomes a problem when a subroutine has to set those values but then, as a good-citizen subroutine, wants to restore them before it returns. Some other data now gCode-inaccessible but known to PathPilot are

• whether in pathblending mode (G64) or not (G61)
• X and Y physical limits in current workspace

Higher-bandwidth input. I'd like to be able to be able to use the MaxVel Override slider for a different purpose. How hard would it be to have

• a read-only parameter (say, #<_BottomSlider>) whose value ranged from 0 to 100, capturing the position of the slider
• on the Settings tab, a new checkbox. The default condition of the checkbox would be checked. When this checkbox was checked, the MaxVel Override slider would control motion as it does now. When the checkbox was not checked, the only effect of the slider would be on the value of #<_BottomSlider>.
• nearby on the Settings tab, a new editbox, enabled when and only when the new checkbox was unchecked. When the edit box was enabled, its contents would appear as the caption of the MaxVel Override slider's reset-to-100 button.

[kstrauss]

As I'm sure that you know LinuxCNC makes Gcode access to over 5000 "internal" variables available using # variables. For example, #5400 is the current tool number and #5181-#5189 are the values for the G30 location. The obvious solution to your desire to access would be for Tormach to extend this perhaps using variable #8000 to #9999 or some such range. I have no idea how hard this would be implement but it is almost certainly beyond my abilities and would have to be redone for every PP release. Perhaps submit this as a feature request to Tormach?

Personally, I feel that modifying the UI layout and operation is a very bad idea. It might appeal to some users but would probably rapidly lead the proliferation of very poor screen designs as happened with Mach3. Consider that a significant plus of Tormach's PP is an attractive screen design. If you really want to do what you described you should look into using Glade. As with other changes, each new version of PP will require redoing your changes. Using HAL pins and a microprocessor based pendant might be a better approach.

It will be interesting to learn the views of knowledgeable users.

[Fenichel]

As I'm sure that you know LinuxCNC makes Gcode access to over 5000 "internal" variables available using # variables. For example, #5400 is the current tool number and #5181-#5189 are the values for the G30 location. The obvious solution to your desire to access would be for Tormach to extend this perhaps using variable #8000 to #9999 or some such range. I have no idea how hard this would be implement but it is almost certainly beyond my abilities and would have to be redone for every PP release. Perhaps submit this as a feature request to Tormach?

Most of what I called "situational awareness" is indeed just a matter of added read-only system variables. I don't know why anyone would want them to be numbered variables instead of named variables, but the semantics is, as always, more important than the syntax.

Personally, I feel that modifying the UI layout and operation is a very bad idea. It might appeal to some users but would probably rapidly lead the proliferation of very poor screen designs as happened with Mach3. Consider that a significant plus of Tormach's PP is an attractive screen design.

Having the lowest slider be optionally repurposed, with its default behavior unchanged, would scarcely change the UI very much. The only change would be Settings options that, like other Settings options, would be best ignored by most users. Such proliferation as would then be possible would be proliferation of different uses for the gCode-readable input. Trivially, it could be used to vary a programmed inspection delay. More interestingly, a sophisticated gCode program could use the input to change its depth of cut, much as running programs automatically change their behavior in response to the feed & speed sliders. Some uses of the new option would be ill-conceived. Well, yes. Many uses of tools are ill-conceived.

If you really want to do what you described you should look into using Glade. As with other changes, each new version of PP will require redoing your changes. Using HAL pins and a microprocessor based pendant might be a better approach.

I will look into HAL pins and Glade, but at first glance they seem to be overkill.

[kstrauss]

Most of what I called "situational awareness" is indeed just a matter of added read-only system variables. I don't know why anyone would want them to be numbered variables instead of named variables, but the semantics is, as always, more important than the syntax.

My reason for suggesting numbered rather than named variables is that that is the approach currently used for similar variables in standard LinuxCNC. No new syntax would have to be considered nor would there be any possible conflicts with existing Gcode programs. I suspect that exposing Tormach's internal variables would only require moving their storage to the same memory area as for current numbered variables and updating the documentation.

Agreed . Both many uses and many users of tools were ill-conceived!

[Fenichel]

Depends on you definition of BW. What frequency or time period are you interested in? Using the MESA IO card for digital input is about the fastest method to read some bits in. There are plenty of IO bits available to do this. However, this is still pretty slow depending on your frame of reference.
.

I misspoke by saying bandwidth; I should have said bitwidth. In other words, I want to get information in and out of a running gCode program a byte, or maybe 2 bytes, at a time. The bandwidth can be just a few Hz. As regards input, what I'm thinking about now is pretty much what each of the the PP UI sliders does now.

PP is basically a G-Code interpreter based on the RS-272 language. It does not define what you're looking for. .

Yes it does. A near-complete selection of the interpreter's modal variables is gCode-accessible in read-only parameters. A few modal variables, which must exist in order for PP to function, are not gCode accessible. I'd be surprised to learn that they could not be made gCode-accessible with trivial effort. Tormach should do this, but I thought that someone in the forum might know how to do it quickly for the ones I listed.

The optional repurposing of the MaxVel Override slider might be more involved, depending on how it is now handled in the current implementation

• if its changes are caught by an ISR or polled by a lightweight-thread loop, and in either case its value just left in a volatile variable (say, SliderValue), and if the feeding routines use this value when deciding how fast to move, then repurposing the slider would be easy

.initialize, or change of repurposing checkbox
    FeedFactor = SliderValue
on change of slider position
  SliderValue = (read slider)
  if not repurposed then
    FeedFactor = SliderValue
in feeding routines
  (replace SliderValue by FeedFactor)

• If the slider is actually read when and only when its value is needed by the feeding routines, repurposing would be harder.

However, there are some methods to accomplish what you want. The problem is Tormach does not publish information about PP internal workings. Many things are similar to LinuxCNC which PP is based on, but the variables you mention are not necessarily going match or exist in LinuxCNC.

Which variables might not exist?. To implement G61 and G64, PP must have a variable that tells it which is in effect. To decide which simulated LED in the UI to light, PP must have a variable that tells it which speed range is in use. And so on. The only new variables I discussed correspond to atomic elements of the PP environment whose existence is proven by PathPilot's easily-observed behavior.

Maybe there's more than one way to do this but the method I know is described here: Extending LinuxCNC. Basically you need to remap an existing or unused code to accomplish your goal. The TRICK HERE is that you can define a Python routine to do your bidding. While in Python you have access to all the variables you desire with the one caveat that you don't know what their names are. Maybe someone else knows what they are but I just nose around until I find what I'm looking for.

Anyway, once you understand this method the world is yours. You can call either a Python or o-word function. You can use the Python prolog & epilog functions to save/restore settings and/or set named parameters for use in an o-word call.

For example, in Python, if I want to know the GUI setting for the Spindle Type and provide a name parameter for it I would do this:

self.params["_spindle"] = int(self.redis.hget('machine_prefs', 'spindle_type'))

where

SPINDLE_TYPE_STANDARD = 0
SPINDLE_TYPE_SPEEDER = 1
SPINDLE_TYPE_HISPEED = 2

In your case you could write a routine as a complete new function to accomplish your goal, or have it stuff all the info you want into some parameter locations for use by your G-code.

I will look at that.

[kstrauss]

You may find the following useful. I have not tried any of the information. I would love learn of any success or failure! The original is at Remap Extending G code


The interpreter comes with a set of predefined named parameters for accessing internal state from the NGC language level. These parameters are read-only and global, and hence cannot be assigned to.

Additional parameters may be added by defining a function in the namedparams module. The name of the function defines the name of the new predefined named parameter, which now can be referenced in arbitrary expressions.

To add or redefine a named parameter:

add a namedparams module so it can be found by the interpreter

define new parameters by functions (see below). These functions receive self (the interpreter instance) as parameter and so can access aribtrary state. Arbitrary Python capabilities can be used to return a value.

import that module from the TOPLEVEL script

# namedparams.py
# trivial example
def _pi(self):
return 3.1415926535
#<circumference> = [2 * #<radius> * #<_pi>]
Functions in namedparams.py are expected to return a float or int value. If a string is returned, this sets the interpreter error message and aborts execution.

Ònly functions with a leading underscore are added as parameters, since this is the RS274NGC convention for globals.

It is possible to redefine an existing predefined parameter by adding a Python function of the same name to the namedparams module. In this case, a warning is generated during startup.

[Fenichel]

Thanks, Ken. I got your message while I was printing out the whole Extending LinuxCNC document, as cited by @rdsl, and now you've pointed me right into its pertinent section.