Hi all,
here we have a postprocessor for a Fagor 8060 milling machine. This is a modification of GRBL postprocessor.
I just removed the G21 that makes my machine crazy, enabled the G0, G01 drilling because the parameters eather match.
OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.22846 (Git)
Build type: Release
Branch: master
Hash: 1f46b72491a0008384a6db4f2615a656249f6f08
Python version: 3.8.6
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: Spanish/Spain (es_ES)
Postprocessor Fagor 8060 working
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
-
- Posts: 3
- Joined: Wed Dec 23, 2020 6:22 pm
Postprocessor Fagor 8060 working
- Attachments
-
- fagor_post.py
- Fagor 8040 postprocessor
- (21.45 KiB) Downloaded 237 times
Re: Postprocessor Fagor 8060 working
Can you add a pull request so it will be added to master?
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Postprocessor Fagor 8060 working
If this is a GRBL post processor with minor modifications - would it make sense to extend the GRBL post processor and add the functionality as an option for it?
The main reason I ask is that way the post processor would get all improvements made to the GRBL post processor which has an active user and maintainer base.
The main reason I ask is that way the post processor would get all improvements made to the GRBL post processor which has an active user and maintainer base.
- sliptonic
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Postprocessor Fagor 8060 working
Best to extend grbl. But if it's added as a new post, please add copies notes to the beginning of the file explaining how it's different.
At some point, we're going to have to refactor the postprocessor system and recreating/testing is going to hurt without some explanation of what it should do.
At some point, we're going to have to refactor the postprocessor system and recreating/testing is going to hurt without some explanation of what it should do.
- RandomWebUser
- Posts: 3
- Joined: Sun May 01, 2022 5:26 pm
Re: Postprocessor Fagor 8060 working
I plan on trying the postprocessor on my machine, it uses a Fagor8055m panel with a tool changer I think the G and M codes have all the same functionality. Been using this site ( http://www.helmancnc.com/fagor-8055-g-codes-m-codes/ ) and even the newer panels seem like they could work. My biggest concern is how the tool change is handled since the machine holds all the tools parameters and the postprocessor only needs to call the tool (T# calling the and then M6 for the change). Worked with someone who used bobcad-cam and was surprised about this since Haas machines would define the tools in the postprocessor.
Thank you for your contribution, will update when I try it out
Thank you for your contribution, will update when I try it out
-
- Posts: 73
- Joined: Tue Feb 22, 2022 9:16 pm
Re: Postprocessor Fagor 8060 working
If I may, I would like to comment on whether post-processors for different machines should be combined or kept distinct.
I hope you will allow me to share my experience (as the responsible person in a process development team) outlining requirements for post-processors, and doing machine-tool prove-in of first RS-274-D compliant programs for, new machine-tools. For that organization (a large aerospace manufacturer), it was their experience, from a safety standpoint, that unless two machines were identical in every manner (G-code set, M-code set, machine limits, min/max spindle speed, min/max feeds, tool chucks/holders, tool changer capacity), the code-set for each post-processors should kept as its own distinct code set.
We were fully cognizant that there were huge chunks of code overlap, but post-processors being what they were, translating from a "Neutral File" detailing all actions, into machine-specific "Tape Instruction Set", a post-processor for a given combination of CNC control and physical machine-tool was always a frozen asset, once the initial proving of the Machine Manual's outline of command interpretations were translated into final code, verified by the test-part program that would test every permutation of the machine-tool's possible G/M code and displacement combinations.
We just couldn't risk having ongoing changes to a post-processor which might inadvertently result in a machine being damaged because of a change done for a new addition to the plant's capacity. This was dictated by close-calls experienced by others years before I was given that role.
I just want to point out that the most important facet to such an "architecture" is a stable (preferrably frozen) "Neutral File" format, ASCII APT CLDATA (ISO 3592:1978). That ASCII form was more easily accessible for inspection of the inputs generated from Catia, Graftek or Pro/ENGINEER, while troubleshooting the appropriateness of the translation into machine instruction sets (ISO 6983-1:1982).
I hope that helps you in making your decisions regarding combined vs distinct Post-Processors.
I also have some strong opinions against STEP-NC, but I see I am out of step with the times.
I hope you will allow me to share my experience (as the responsible person in a process development team) outlining requirements for post-processors, and doing machine-tool prove-in of first RS-274-D compliant programs for, new machine-tools. For that organization (a large aerospace manufacturer), it was their experience, from a safety standpoint, that unless two machines were identical in every manner (G-code set, M-code set, machine limits, min/max spindle speed, min/max feeds, tool chucks/holders, tool changer capacity), the code-set for each post-processors should kept as its own distinct code set.
We were fully cognizant that there were huge chunks of code overlap, but post-processors being what they were, translating from a "Neutral File" detailing all actions, into machine-specific "Tape Instruction Set", a post-processor for a given combination of CNC control and physical machine-tool was always a frozen asset, once the initial proving of the Machine Manual's outline of command interpretations were translated into final code, verified by the test-part program that would test every permutation of the machine-tool's possible G/M code and displacement combinations.
We just couldn't risk having ongoing changes to a post-processor which might inadvertently result in a machine being damaged because of a change done for a new addition to the plant's capacity. This was dictated by close-calls experienced by others years before I was given that role.
I just want to point out that the most important facet to such an "architecture" is a stable (preferrably frozen) "Neutral File" format, ASCII APT CLDATA (ISO 3592:1978). That ASCII form was more easily accessible for inspection of the inputs generated from Catia, Graftek or Pro/ENGINEER, while troubleshooting the appropriateness of the translation into machine instruction sets (ISO 6983-1:1982).
I hope that helps you in making your decisions regarding combined vs distinct Post-Processors.
I also have some strong opinions against STEP-NC, but I see I am out of step with the times.
- RandomWebUser
- Posts: 3
- Joined: Sun May 01, 2022 5:26 pm
Re: Postprocessor Fagor 8060 working
I finally got to test out the post-processor on my Mill and here are the issues I ran into (for running on a Fagor8055 Mill with auto tool changer):
[*]The tool change operation is backwards, the post calls M6 and then the T## (Tool number), For the Fagor 8055 panel the tool needs to be called first and then the M6 which does the tool change.
[*]The speed line command is backwards as well, which would require the speed to be set first S#### and then specifying the direction of the spindle with (M03 Clockwise spindle rotation) or (M04 Counterclockwise spindle rotation)
Also, the feed rate only needs to be called once at the beginning instead of having it posted on each line at the end and called again when needing a different speed.
[*]The Comments for the post-processor are written within brackets which causes the machine to spit out an error. It should use a semicolon which skips the line, I don't think there is a way to display comments, I would have to look into that.
I did try to make changes to the post-processor to resolve the above issues, however, it was a waste of time because it just causes errors and Im not familiar with python script
[*]The tool change operation is backwards, the post calls M6 and then the T## (Tool number), For the Fagor 8055 panel the tool needs to be called first and then the M6 which does the tool change.
[*]The speed line command is backwards as well, which would require the speed to be set first S#### and then specifying the direction of the spindle with (M03 Clockwise spindle rotation) or (M04 Counterclockwise spindle rotation)
Also, the feed rate only needs to be called once at the beginning instead of having it posted on each line at the end and called again when needing a different speed.
[*]The Comments for the post-processor are written within brackets which causes the machine to spit out an error. It should use a semicolon which skips the line, I don't think there is a way to display comments, I would have to look into that.
I did try to make changes to the post-processor to resolve the above issues, however, it was a waste of time because it just causes errors and Im not familiar with python script
Re: Postprocessor Fagor 8060 working
You can make a pull request to provide it to the community.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
- RandomWebUser
- Posts: 3
- Joined: Sun May 01, 2022 5:26 pm
Re: Postprocessor Fagor 8060 working
I can not make a Pull request, as I do not know what that is or how it is made. I do not have any coding experience besides G Code, and my trial & error testing method. Apologies for the inconvenience.