Units for feedrate

[herbk]

Hi sliptonic,
we are mostly talking about the shown units in metric system, not about changing from metric to imperial system.

speed3.jpg (167.79 KiB) Viewed 2396 times

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.

[sliptonic]

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.

I understand but the proposed solution takes us backwards, I think.

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.

[herbk]

Hi sliptonic,

This won't solve the display problem, but that's not a Path issue

absolutly not, and with all you say i agree.
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...

[sliptonic]

Hi sliptonic,

This won't solve the display problem, but that's not a Path issue

absolutly not, and with all you say i agree.
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...

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.

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'))

[herbk]

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.

[sliptonic]

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.

This makes no sense. The change to the postprocessor won't have any affect on the job creation.

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.

[herbk]

Hi sliptonic,

This makes no sense. The change to the postprocessor won't have any affect on the job creation.

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.

lincnc.png (32.09 KiB) Viewed 2336 times

[chrisb]

Is it possible that you have a dialog open in the second tab "Aufgaben". That would explain the behaviour which you describe.

[herbk]

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.

[JoshM]

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