DynaPath Delta PP Assistance Requested.

[luvtofish]

Hi All,
I've been making great progress with the PP now that my spindle control has been rebuilt and re-installed in my vertical mill. With a now working CNC Mill, I've found a few issues with the post that required further modification in order to get things working properly. I now have the following items working:

> command line args working for: modal, axis-modal, precision, units, line-numbers among others.
> g2/g3 arcs are now converted to absolute values as needed by the control in eia/iso events
> added 2nd reference plane "O" parameter to G81-G83 events and made = to ClearanceHeight as default.
> All comments are converted to conversational style for display integration.
> fixed units gcodes to match dynapath delta
> fixed fixture codes to match dynapath delta
> other code fixes and cleanup.
> removed spacing since this is only allowed inside comments and the program name
> added program name entry
> added program end character to bottom of file

With all that said, I'm finding with a very simple program that merely performs a face profile operation, I'm getting some strange output and not sure why it's occurring? See attached pic of the two issues found. The first "G0Z0.187 entry serves no purpose, not sure why it's being output there? The second G0Z0.187 errors out and will only work if the following X and Y coordinates from the following line are including together. I've attached the model used to generate this code. I do not see anything in the PP that would be causing this and all other items seem to work just fine. Curious what others would get using the same simple model?

Screenshot from 2022-05-06 19-35-55.png (80.5 KiB) Viewed 1431 times

Code: Select all

OS: CentOS Stream 8 (GNOME/gnome)
Word size of FreeCAD: 64-bit
Version: 0.20.28774 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 716213b)
Hash: 716213beacd25a907f2c164ad8ef8309b8a284b0
Python 3.9.12, Qt 5.12.9, Coin 4.0.0, OCC 7.5.3
Locale: English/United States (en_US)
Installed mods: 
  * Render 2022.1.0
  * A2plus 0.4.56

[chrisb]

How about providing the postprocessor?

[bmsaus4ax]

Hi All,

With all that said, I'm finding with a very simple program that merely performs a face profile operation, I'm getting some strange output and not sure why it's occurring? See attached pic of the two issues found. The first "G0Z0.187 entry serves no purpose, not sure why it's being output there? The second G0Z0.187 errors out and will only work if the following X and Y coordinates from the following line are including together. I've attached the model used to generate this code. I do not see anything in the PP that would be causing this and all other items seem to work just fine. Curious what others would get using the same simple model?

Screenshot from 2022-05-06 19-35-55.png

Those "Z " figures don't fit with the Operation settings, the Safe Height and Clearance Height do not appear at all, the Rapid move is straight to near the surface.
The Inspect Path Commands shows them, but they disappear for the post output?
Something seems to have gone amiss in the file. If I post-process with linuxcnc I get the same as your output.

EDIT: the first G0 you note comes from PathPost.py when processing the Fixture section. ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

Code: Select all

    def buildPostList(self, job):
        """
        Parses the job and returns the list(s) of objects to be written by the post
        Postlist is a list of lists.  Each sublist is intended to be a separate file
        """
        orderby = job.OrderOutputBy

        fixturelist = []
        for f in job.Fixtures:
            # create an object to serve as the fixture path
            fobj = _TempObject()
            fobj.Label = f
            c1 = Path.Command(f)
            c2 = Path.Command(
                "G0 Z"
                + str(
                    job.Stock.Shape.BoundBox.ZMax
                    + job.SetupSheet.ClearanceHeightOffset.Value
                )
            )
            fobj.Path = Path.Path([c1, c2])
            # fobj.InList.append(job)
            fixturelist.append(fobj)

        postlist = []

....................................

Try the extra Jobs in the attached modification of your file, with your post-processor. ( one based on a Part WB model, and one on a new Part Design WB model)
I don't believe it is a post-processor issue, just something in the model file.

Used the same FreeCAD version.
.

Code: Select all

OS: Ubuntu 20.04.4 LTS (ubuntu:GNOME/ubuntu)
Word size of FreeCAD: 64-bit
Version: 0.20.28774 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 716213b)
Hash: 716213beacd25a907f2c164ad8ef8309b8a284b0
Python 3.9.12, Qt 5.12.9, Coin 4.0.0, OCC 7.5.3
Locale: English/Australia (en_AU)
Installed mods: 
  * Curves 0.4.2
  * CurvedShapes 1.0.3

[luvtofish]

bmsaus4ax -- I tried to run the models in your file but the only one that would work with my PP was JOB002. The error had to do with how I'm using the document Label to name the program file. JOB and JOB001 didn't have a document label assigned. All that aside, JOB002 inserted the same two Z axis lines exactly as before.

The PathPost.py file you provided indicates a move in the Z axis as part of the fixture list output. I have to ask WHY? This is occurring before the first tool is called and the spindle is fired up. This is clearly a BUG or feature that is incorrectly implemented. Anybody have thoughts on why this happening?

For safety sake, any first move towards the work piece in the "negative" Z direction should occur after the X and Y have been executed. Any movement away from the work piece (at end of cycle) should first move positive in the Z and then traverse in the X Y to home. The Delta control performs this way as a built in feature so long as the X,Y,Z occur on the same line.

For the last Z move item, I'm not quite sure why it is being inserted the way it is? As mentioned above the first XYZ move should include all three axis at the beginning of the cycle and bring the tool to the starting point of the work piece.

[luvtofish]

I'm attaching another example. I've included the model and the gcode output. I've annotated inside the gcode file where the issues are. I'm also including my Dynapath Delta PP file -- it is a WIP so if you intend to use it, please do so at your own risk.

[bmsaus4ax]

bmsaus4ax -- I tried to run the models in your file but the only one that would work with my PP was JOB002. The error had to do with how I'm using the document Label to name the program file. JOB and JOB001 didn't have a document label assigned. All that aside, JOB002 inserted the same two Z axis lines exactly as before.

My comments on the Z values are incorrect as I now see your output is for inches I didn't notice G20
.

The PathPost.py file you provided indicates a move in the Z axis as part of the fixture list output. I have to ask WHY? This is occurring before the first tool is called and the spindle is fired up. This is clearly a BUG or feature that is incorrectly implemented. Anybody have thoughts on why this happening?

Looking at the licence header, this is a very early FreeCAD days file, if it was even Freecad path then. Probably never been a priority to modify as it shouldn't cause problems if the Fixture info is correct. The movement ordering aside.
.

For safety sake, any first move towards the work piece in the "negative" Z direction should occur after the X and Y have been executed. Any movement away from the work piece (at end of cycle) should first move positive in the Z and then traverse in the X Y to home. The Delta control performs this way as a built in feature so long as the X,Y,Z occur on the same line.

A number of commercial control systems have System Parameters which can be set for the order of axis movement, presumably in freecad this is adopted as the original safety strategy.
.

For the last Z move item, I'm not quite sure why it is being inserted the way it is? As mentioned above the first XYZ move should include all three axis at the beginning of the cycle and bring the tool to the starting point of the work piece.

Some operations have these initial moves hard coded this way e.g. PathDrilling.py
Others it is not obvious where it is happening e.g. PathMillFace.py

[luvtofish]

What is the risk of modifying path script files such as PathPost.py? I’m assuming the biggest issue is losing my edits after the next version bump?

I’ve corrected the fixture Z path output by modifying pathpost.py, will look at the drill op next. Also found an issue in G83 where it ignores hole #1 but peck drills subsequent holes perfectly fine. Plenty more stuff to cleanup before the post processor is in working order.

[chrisb]

What is the risk of modifying path script files such as PathPost.py? I’m assuming the biggest issue is losing my edits after the next version bump?

First of all you should keep a copy outside of the FreeCAD install path.

Changes to PathPost.py should be of general interest and then you should make a pull request to include them in the general version. We are already in feature freeze for 0.20 so only bugfixes can be included in stable 0.20, but as soon as 0.20 is out you can get a 0.21 with your changes.

[luvtofish]

Okay, sounds good. Thank you Chrisb.