Units for feedrate
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Units for feedrate
Hi sliptonic,
we are mostly talking about the shown units in metric system, not about changing from metric to imperial system.
if i set a speed for axis (the green circled) Freecad exports this to the gcode as "F290".
Freecad shows mm/s (the red circed) as unit, but Linuxcnc and Mach3 (and i think some more) machine software are interpretting "F290" with "work with speed 290 mm/min".
For that, the shown unit in the red circle should change to mm/min if a postprozessor for e machine is selcted which interprets the F comand in mm/min.
we are mostly talking about the shown units in metric system, not about changing from metric to imperial system.
if i set a speed for axis (the green circled) Freecad exports this to the gcode as "F290".
Freecad shows mm/s (the red circed) as unit, but Linuxcnc and Mach3 (and i think some more) machine software are interpretting "F290" with "work with speed 290 mm/min".
For that, the shown unit in the red circle should change to mm/min if a postprozessor for e machine is selcted which interprets the F comand in mm/min.
Gruß Herbert
- sliptonic
- Veteran
- Posts: 3460
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Units for feedrate
I understand but the proposed solution takes us backwards, I think.herbk wrote:Hi sliptonic,
we are mostly talking about the shown units in metric system, not about changing from metric to imperial system.
speed3.jpg
if i set a speed for axis (the green circled) Freecad exports this to the gcode as "F290".
Freecad shows mm/s (the red circed) as unit, but Linuxcnc and Mach3 (and i think some more) machine software are interpretting "F290" with "work with speed 290 mm/min".
For that, the shown unit in the red circle should change to mm/min if a postprozessor for e machine is selcted which interprets the F comand in mm/min.
The value that the user is inputting is a velocity and FreeCAD is capable of understanding it as that. If you type in '290 in/min' it will instantly be converted to mm/second and stored in the Path Command that way, which is exactly what I think it should do. It should NOT be storing '290' without a unit and it should NOT be storing '290 in/min'. Like all units in FreeCAD, it should be converting to base units internally and storing that.
Now that velocity is correctly represented internally, the question is how to get it out in the desired format. The post processor should have a property to represent the desired format. If you want something other than mm/sec, it can convert it at that time as I showed.
This won't solve the display problem, but that's not a Path issue. The problem is that the FreeCAD unit schema doesn't allow you to set user preference for velocity or time. There are some workarounds possible and it might be trivial to add an additional schema.
Re: Units for feedrate
Hi sliptonic,
The Problem is the interpretation of linuxcnc, and other machine softeware, which are working with the otherwise unusual unit mm/min and a big count of users which are the accustomed with it...
absolutly not, and with all you say i agree.This won't solve the display problem, but that's not a Path issue
The Problem is the interpretation of linuxcnc, and other machine softeware, which are working with the otherwise unusual unit mm/min and a big count of users which are the accustomed with it...
Gruß Herbert
- sliptonic
- Veteran
- Posts: 3460
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Units for feedrate
No, that's not the problem. The issue is that the post-processors are not using the F parameter as a velocity and converting it to a format that the user desires. They're just assuming that the F parameter is in the user-desired units.herbk wrote:Hi sliptonic,absolutly not, and with all you say i agree.This won't solve the display problem, but that's not a Path issue
The Problem is the interpretation of linuxcnc, and other machine softeware, which are working with the otherwise unusual unit mm/min and a big count of users which are the accustomed with it...
I've attached a modified linuxcnc_post.py. This isn't perfect because of floating point math. If I enter 25 in/min, It outputs 'F24.99' but it works otherwise.
It just adds this to the beginning
Code: Select all
from FreeCAD import Units
UNIT_FORMAT = 'in/min'
and replace a couple lines around 242-254 like this:
Code: Select all
# Now add the remaining parameters in order
for param in params:
if param in c.Parameters:
if param == 'F':
if c.Name not in ["G0", "G00"]: #linuxcnc doesn't use rapid speeds
speed = Units.Quantity(c.Parameters['F'], FreeCAD.Units.Velocity)
outstring.append(
param + format(float(speed.getValueAs(UNIT_FORMAT)), '.2f') )
elif param == 'T':
outstring.append(param + str(c.Parameters['T']))
else:
outstring.append(
param + format(c.Parameters[param], '.4f'))
- Attachments
-
- linuxcnc_post.py
- (9.88 KiB) Downloaded 67 times
Re: Units for feedrate
if i replace the file with the attached, the toolcontroller isn't a part of job as it is with the original file. For that it seams, that all changes i make have no effect.
Gruß Herbert
- sliptonic
- Veteran
- Posts: 3460
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Units for feedrate
This makes no sense. The change to the postprocessor won't have any affect on the job creation.herbk wrote:if i replace the file with the attached, the toolcontroller isn't a part of job as it is with the original file. For that it seams, that all changes i make have no effect.
I just retried here and the toolcontroller was created as part of the job like normal.
I then entered '25 in/min' in the horizontal speed of the TC.
And post processed.
Output was generated with F24.99
edit. FYI, there's something strange about the inputbox box that it doesn't want me to type 'in/min' very easily. I can get it done, but it's fussy.
When I hit enter though, it converts to "10.5833 mm/s" as expected.
Re: Units for feedrate
Hi sliptonic,
I try'd again, but it's the same: after replacing the orig. file with that from link above i got this tree and can't select a tool.This makes no sense. The change to the postprocessor won't have any affect on the job creation.
Gruß Herbert
Re: Units for feedrate
Is it possible that you have a dialog open in the second tab "Aufgaben". That would explain the behaviour which you describe.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Units for feedrate
Good morning Chris,
i didn't check that, i just made it like usual: create a job, add a tool.
After doing that 2 steps i have the order of job and TC like shown on the pic.
Now i'm back to the original linuccnc_post.py and it works like it should.
i didn't check that, i just made it like usual: create a job, add a tool.
After doing that 2 steps i have the order of job and TC like shown on the pic.
Now i'm back to the original linuccnc_post.py and it works like it should.
Gruß Herbert
Re: Units for feedrate
I just ran into this and am a bit confused.
To get around issues with Facing operation in later versions, I am using:
OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.12431 (Git)
Build type: Release
Branch: master
Hash: c397aee9ed3efcb2e33fa719313c98cc4867cf32
Python version: 2.7.8
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: English/UnitedStates (en_US)
But, the 3D Pocket operation causes issues--where I either run my tool through work on rapids, or I don't get to set fine depths for 3D operation using Ballnose tool... To work around this, I copied the output GCode which is only wrong on Rapids at beginning/end of operation and pasted into Custom GCode operation, then deleted the 3D Pocket. The custom GCode requires me to divide all Feedrates by 60 to get proper outputs due to issues described in this thread.
I am unclear from reading this thread if I found an old and understood issue, or a new twist?
Thanks,
-Josh
To get around issues with Facing operation in later versions, I am using:
OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.12431 (Git)
Build type: Release
Branch: master
Hash: c397aee9ed3efcb2e33fa719313c98cc4867cf32
Python version: 2.7.8
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: English/UnitedStates (en_US)
But, the 3D Pocket operation causes issues--where I either run my tool through work on rapids, or I don't get to set fine depths for 3D operation using Ballnose tool... To work around this, I copied the output GCode which is only wrong on Rapids at beginning/end of operation and pasted into Custom GCode operation, then deleted the 3D Pocket. The custom GCode requires me to divide all Feedrates by 60 to get proper outputs due to issues described in this thread.
I am unclear from reading this thread if I found an old and understood issue, or a new twist?
Thanks,
-Josh