Refactored Post Processors Custom PP's

Here's the place for discussion related to CAM/CNC and the development of the Path module.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Post Reply
bmsaus4ax
Posts: 255
Joined: Sat Nov 14, 2020 9:16 pm
Location: Bargara, Queensland, Australia UTC+10

Refactored Post Processors Custom PP's

Post by bmsaus4ax »

I have a g-code interpreter / motion controller which uses "I" instead of "Q" in drilling cycles.
I have a custom post processor which can do the substitution , and have modified it to do so for the refactored Path code also, but have have not been able to do a "refactored" version.

Is there a way to trigger the substitution from the post processor via the values[ ] mechanism ?

I see this in Utils.py, which I read as a substitution routine

Code: Select all

def stringsplit(commandline):
    returndict = {
        "command": None,
        "X": None,
        "Y": None,
        "Z": None,
        "A": None,
        "B": None,
        "F": None,
        "T": None,
        "S": None,
        "I": None,
        "J": None,
        "K": None,
        "txt": None,
    }
    wordlist = [a.strip() for a in commandline.split(" ")]
    if wordlist[0][0] == "(":
        returndict["command"] = "message"
        returndict["txt"] = wordlist[0]
    else:
        returndict["command"] = wordlist[0]
    for word in wordlist[1:]:
        returndict[word[0]] = word[1:]

    return returndict
but can a new dictionary be passed? via something like values[ ]? I have tried a few things without success.

Pre refactor I could do this from the post processor

Code: Select all

                    elif param == 'Q':    # modification
                        outstring.append('I' + str(float(c.Parameters['Q'])))  # substitution for SMC4motionController drilling
I could probably do something similar in UtilsParse.py but that would be hard coding in a general purpose file, counter to the purpose of the refactor .

This is probably best directed at LarryWoestman but I could not set up a ping without the unique member number and he is not in the pinger macro list yet.
LarryWoestman
Posts: 98
Joined: Fri Oct 09, 2020 4:56 pm
Location: Oregon, USA

Re: Refactored Post Processors Custom PP's

Post by LarryWoestman »

I did not design in that capability in the "refactored" code. I will try to take a look at the code this afternoon (my time, which is USA west coast PST) and see what it would take to make such a change.
bmsaus4ax
Posts: 255
Joined: Sat Nov 14, 2020 9:16 pm
Location: Bargara, Queensland, Australia UTC+10

Re: Refactored Post Processors Custom PP's

Post by bmsaus4ax »

LarryWoestman wrote: Sat Nov 26, 2022 5:26 pm I did not design in that capability in the "refactored" code. I will try to take a look at the code this afternoon (my time, which is USA west coast PST) and see what it would take to make such a change.
Thank you, it is not a pressing issue for me as I have a work around in calling Utils or PathUtils and the old code.

Another thing I do is insert blank comment holders for memory aids on setup for orientation and wpc etc. like an in code setup sheet reminder ( .....}
This is manually edited anyway so is not really an issue but a values[ ] token/symbol could be handy for custom output sections .
LarryWoestman
Posts: 98
Joined: Fri Oct 09, 2020 4:56 pm
Location: Oregon, USA

Re: Refactored Post Processors Custom PP's

Post by LarryWoestman »

Do you want to change the "Q" to an "I" in just the G73 and G83 G-codes? I assume that you don't want to swap "I" for "Q" anywhere else?

So far I haven't designed any way to easily swap in a different string of characters for a particular G-code command string ("G01" for example) or for a particular G-code parameter string ("Q", for example), but I have been thinking about possible ways to do it. There are tricky aspects. For example, it probably wouldn't work to just swap "I" for "Q" in all possible G-code commands, so there has to be some way to describe what string to use for what command string or what parameter string for what G-code command or commands.

In the short term, modifying the older not-refactored versions of postprocessors would probably be easier :oops:

I would like to understand the problem statement correctly, then file a feature request with that problem statement so it doesn't get "lost". I would like to eventually figure out a way to add that kind of capability to the "refactored" code, hopefully in a fairly general way instead of a "swap I for Q in a couple of drilling commands" special case solution.

As far as I can tell, the "stringsplit" routine in the Utils.py file is only used in the mp_post.py postprocessor script.

As https://forum.freecadweb.org/viewtopic.php?f=15&t=66972 points out, the "refactored" postprocessors will be changing quite a bit as more of the changes are merged, so you may not want to build dependencies on them yet.
bmsaus4ax
Posts: 255
Joined: Sat Nov 14, 2020 9:16 pm
Location: Bargara, Queensland, Australia UTC+10

Re: Refactored Post Processors Custom PP's

Post by bmsaus4ax »

LarryWoestman wrote: Sun Nov 27, 2022 1:00 am Do you want to change the "Q" to an "I" in just the G73 and G83 G-codes? I assume that you don't want to swap "I" for "Q" anywhere else?
It is only for the drill cycles , other cycles maintain standard "words".
There is a different interpretation on G28, as well as the standard version. One style is similar to G92 in standard gcode, another is a different form of offsetting and also something similar to G29, None of this is a concern as it is not needed in an output from FreeCAD.

"I" is used as standard in other operations and cycles, these drilling cycles are the only oddity in my controller.
LarryWoestman
Posts: 98
Joined: Fri Oct 09, 2020 4:56 pm
Location: Oregon, USA

Re: Refactored Post Processors Custom PP's

Post by LarryWoestman »

I have files a feature request for this topic:

issue #7918
User avatar
silopolis
Posts: 74
Joined: Thu Oct 20, 2016 10:06 pm

Re: Refactored Post Processors Custom PP's

Post by silopolis »

LarryWoestman wrote: Sun Nov 27, 2022 1:00 am ... I have been thinking about possible ways to do it. There are tricky aspects. For example, it probably wouldn't work to just swap "I" for "Q" in all possible G-code commands, so there has to be some way to describe what string to use for what command string or what parameter string for what G-code command or commands.
When I read the issue on GH I thought "Oh yeah ! A post-processor command mapping table, what a brilliant idea :idea:"
But indeed, on second thought, this would most probably need some kind of more or less advanced post-processor configurator allowing to set the address and parameters codes for each internal command.
LarryWoestman wrote: Sun Nov 27, 2022 1:00 am I would like to understand the problem statement correctly, then file a feature request with that problem statement so it doesn't get "lost". I would like to eventually figure out a way to add that kind of capability to the "refactored" code, hopefully in a fairly general way...
Let me try it:
Modifying or adapting a post-processor for a specific NC code variant today requires programming skills and Path WB code knowledge most machinists and NC programmers don't have. This, in most cases, forbids them FreeCAD adoption unless they find someone competent, available, and willing to do it for them. They may also have to pay for this service, which is good for FOSS funding, but possibly an issue for hobby or less wealthy users.

Allowing users, helped by their NC control reference manual, to configure mapping of internal commands (rapid, linear feed, tool change, etc.) and their options, to addresses (G00, G01, M06, etc.) and their parameters (I, J, K, P, Q, etc.) could allow them to _configure_ their PP without coding.

UI could take the form of a wizard and/or a tab in Path preferences.

HTH
LarryWoestman
Posts: 98
Joined: Fri Oct 09, 2020 4:56 pm
Location: Oregon, USA

Re: Refactored Post Processors Custom PP's

Post by LarryWoestman »

Thanks for the ideas!

I have discovered while working on refactoring 4 of the most common postprocessors that it isn't just "mapping" but in many cases also different "logic" or "reasoning" that is needed. It would be nice if all G-code interpreters were based on the same standards but in many cases the G-code interpreters were written first and the "standards" came along later with a lot of "implementation defined" parts. The postprocessors have a lot of work to do in some cases.

In code that hasn't been merged yet I have implemented "replaceable" routines for handling the parameters ("Q", for example). It would be possible to replace the "Q" handling routine with a different one that can look at which command ("G01", for example) is being processed and do something different for some of the commands or add as much extra "reasoning" as desired.

I'm still thinking about other aspects of this general kind of issue. We might solve a fair number of cases by just being able to replace "G01" with some other string, but that won't be enough for every case I can think of. A design that solves some of the cases will still be a step in the right direction.

My current goals (which are not all implemented yet) is that a person can start from an existing "refactored" postprocessor file and make many configuration changes using the "options" field in the GUI. If that starts to be too complicated then they should be able to copy an existing postprocessor file and edit it to add/delete/modify configuration options to address some cases. Only if that can't solve the case would they need to start modifying the code in some way. Hopefully many postprocessor solutions won't need more than using some already provided configuration options, but that remains to be seen. There are enough existing postprocessors which each solved their particular case in a different way that this is a challenging problem :shock:
User avatar
silopolis
Posts: 74
Joined: Thu Oct 20, 2016 10:06 pm

Re: Refactored Post Processors Custom PP's

Post by silopolis »

LarryWoestman wrote: Fri Dec 02, 2022 2:35 am Thanks for the ideas!
Thank you for welcoming them :)
LarryWoestman wrote: Fri Dec 02, 2022 2:35 am I have discovered while working on refactoring 4 of the most common postprocessors that it isn't just "mapping" but in many cases also different "logic" or "reasoning" that is needed.
...
Arf, this might have been feared :/
LarryWoestman wrote: Fri Dec 02, 2022 2:35 am My current goals (which are not all implemented yet) is that a person can start from an existing "refactored" postprocessor file and make many configuration changes using the "options" field in the GUI. If that starts to be too complicated then they should be able to copy an existing postprocessor file and edit it to add/delete/modify configuration options to address some cases. Only if that can't solve the case would they need to start modifying the code in some way. Hopefully many postprocessor solutions won't need more than using some already provided configuration options, but that remains to be seen. There are enough existing postprocessors which each solved their particular case in a different way that this is a challenging problem :shock:
That looks like a good plan
Keep it strong, and thanks a ton for the work invested and shared in Path WB
Post Reply