OS: Ubuntu 20.04.2 LTS (ubuntu:GNOME/ubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19. Daily
Build type: Release
Branch: unknown
Hash: e8566f22bbeb0b7204e3c45519d0963e8881100b
Python version: 3.8.5
Qt version: 5.12.8
Coin version: 4.0.0
OCC version: 7.5.1
Locale: English/United States (en_US)
The RampEntryDressup always returns to the current offset's X0.0 and Y0.0 coordinates and the clearance height in a straight rapid move before starting the actual milling operation:
...
(Finish operation: TC: 10mm Slot Cutter)
(Begin operation: RampEntryDressup)
(Coolant On:Flood)
M8
(Path: RampEntryDressup)
G0 X0.000 Y0.000 Z70.000
G0 X300.100 Y37.100 Z70.000
...
Is there a possibility to turn this off (or comment out the 'responsible' code in the PathDressupRampEntry.py)?
If this line serves a particular purpose and can not be avoided, I would suggest to retract the Z axis first, before returning to the offset zero coordinates (much like a G28 G91 X0 Y0 Z70.0 in Fanuc).
RampEntryDressup returning to offset zero
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
RampEntryDressup returning to offset zero
- Attachments
-
- Anschlag_vertikal.FCStd
- (43.76 KiB) Downloaded 26 times
Re: RampEntryDressup returning to offset zero
I'm not familiar with other machines, but my very old machine does it all by itself, so I thought it might be a de facto standard: If a rapid move goes up, then it moves Z first, and then X and Y. If a rapid move goes down, then it moves XY first and then Z.
This seems a reasonable strategy to avoid collisions.
This seems a reasonable strategy to avoid collisions.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: RampEntryDressup returning to offset zero
You're right, it would seem reasonable to have this strategy as a standard. But sadly my mill control and machine do obey this order exactly as writtenchrisb wrote: ↑Wed Mar 31, 2021 8:27 pm I'm not familiar with other machines, but my very old machine does it all by itself, so I thought it might be a de facto standard: If a rapid move goes up, then it moves Z first, and then X and Y. If arapid move goes down, then it moves XY first and then Z.
This seems a reasonable strategy to avoid collisions.
I think it would make sense to not output this line at the beginning of the RampEntryDressup alltogether. Apart from wasting time and potentially causing a crash, I can not see the purpose behind it.
Re: RampEntryDressup returning to offset zero
Agreed.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: RampEntryDressup returning to offset zero
There were several operations for which this behavior was corrected a few months ago. Sounds like there may be more operations that need correcting.
Gene
Gene
Re: RampEntryDressup returning to offset zero
Yes. I tried to suggest this some time ago but it wasn't well received. It could have been poorly worded on my part as I'm not a great communicator.
For English help on youtube check out Joko Engineering or Mango Jelly Solutions.
Look for recent videos, this software is updated at a rapid pace.
Look for recent videos, this software is updated at a rapid pace.
Re: RampEntryDressup returning to offset zero
Sorry for waking up an old thread, but I too have this problem with the RampEntryDressup always starting with G0 X0.000 Y0.000 Z something.
I have a lot of small pockets with rampentrydressup which means a lot of feeding back and forth to x0,y0 for no obvious reason. I can of course edit it out manually, which I will do, but it would be nice if one didn't had to.
I have a lot of small pockets with rampentrydressup which means a lot of feeding back and forth to x0,y0 for no obvious reason. I can of course edit it out manually, which I will do, but it would be nice if one didn't had to.