surface don't work

[herbk]

Hi sliptonic,
you added a new function "facing operatin" on path WB. If i try to use it, i got a this error messages:

Code: Select all

Traceback (most recent call last):
  File "/usr/lib64/FreeCAD/Mod/Path/PathScripts/PathMillFace.py", line 330, in setEdit
    taskd.setupUi()
  File "/usr/lib64/FreeCAD/Mod/Path/PathScripts/PathMillFace.py", line 613, in setupUi
    self.addBase()
  File "/usr/lib64/FreeCAD/Mod/Path/PathScripts/PathMillFace.py", line 506, in addBase
    self.obj.Proxy.addFacebase(self.obj, sel.Object, i)
  File "/usr/lib64/FreeCAD/Mod/Path/PathScripts/PathMillFace.py", line 147, in addFacebase
    elif  PathUtils.findParentJob(obj).Base.Name != ss.Name:
<type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'Name'

I have the same message on Opensuse and Mint

[bill]

Works here:

OS: Ubuntu 16.04.1 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.8939 (Git)
Build type: None
Branch: master
Hash: cb16eda2165d1af34ebbd73628f82aa00037f667
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 6.8.0.oce-0.17

Below, shows making 5 passes at 0.1mm to complete.

facing.png (73.21 KiB) Viewed 4012 times

P.S. BTW, thanks for this facing operation sliptonic;

[sliptonic]

herbk,
I think you have not selected a base object in your Job. Either that or your job might need to be deleted and recreated.

[herbk]

herbk,
I think you have not selected a base object in your Job.

Hi sliptonic,
yes, that was the foult i made... and maybe (i don't check it) it's the same base for my drilling problem.

But the reason why i don't select the base object is: on other operations, like "profile based on faces" it works without selcting a base object.

There we are back by the workflow problem... To geting a path, it should be on all operations by the same way...

[mlampert]

There we are back by the workflow problem... To geting a path, it should be on all operations by the same way...

Do you have an idea on how to make all ops work the same?

[herbk]

Hi mlampert,

Do you have an idea on how to make all ops work the same?

All operations, which are implemented before the change from "project" to "job" as base for path operations, working at that way, that they are returning the base geometrie and the face (or edges) by clicking on a face.
Only the operations implemented after the change "project" to "job" needing that a base geometrie is defined in job.

I don't see any reason why the new operations not can work at the same way as the old....

In my mind the problem is based on in the thought (which comes up with the change to job), that on a mill only can made one part at once.

[sliptonic]

Only the operations implemented after the change "project" to "job" needing that a base geometrie is defined in job.

I don't see any reason why the new operations not can work at the same way as the old....

In my mind the problem is based on in the thought (which comes up with the change to job), that on a mill only can made one part at once.

You don't see any reasons but trust me, they are there. The old project structure was deeply flawed. It had many limitations that were keeping us from improving the functionality of Path overall. Let me try to explain a really big one:

If your part model isn't oriented the same way in the assembly as it will be on the milling table, you will have to establish the correct orientation so the CNC operation can be calculated correctly. I see three basic options:

1) Actually move the part model.
2) Make a copy of the part model and move that.
3) Determine how you would move the part and store that transformation information to use in calculating the gcode.

Number 1 and 2 are really easy but break down as soon as you want to do CNC work on more than one side of a part. Then you either choose one or a make multiple copies. That starts to get ugly fast.

Obviously #3 is the best long term answer but also the most complicated. We can't do it yet, but that's where we want to go. It's also pretty hard to do in the GUI in an intuitive way and you're definitely not going to want to do this over and over for every single operation. So that means storing the transformation at a 'higher level'. So we will store the transformation at the 'Job' level. That makes sense and also lets us do some cool things with Bounding boxes and virtual vises, etc.

And here's the rub: That ONLY works if there's a 1:1 relationship between the job and the part model. If there's two (or more) parts in the job, we would have to store all those transformations and correctly relate them to the underlying operations. This, I think, is a nightmare for developers and users.

Once we have jobs working right, it should be much easier for us to aggregate them into a higher level compound to cut multiple parts from a single piece of stock but we'll need to be a bit patient for that.

[mlampert]

All operations, which are implemented before the change from "project" to "job" as base for path operations, working at that way, that they are returning the base geometrie and the face (or edges) by clicking on a face.
Only the operations implemented after the change "project" to "job" needing that a base geometrie is defined in job.

I don't see any reason why the new operations not can work at the same way as the old....

I think the only operation that doesn't require selection of a Base Face or edge is Contour - right? All others still work the same as they did before.

Now I realise that we are starting to have two different discussion in this thread - I can juggle that but if you (herbk) feel very strongly about Job and Project you might wanna start a separate thread. It is a very important discussion to have as sliptonic mentioned in his introduction video to the new workflow and one that we should definitely have if Job isn't working for some of us.

I think the lack of combining multiple Jobs or copies to create a single g-code file has been acknowledged, we just didn't get to that yet. If you have an idea on how to accomplish that by all means let us know. For all the reasons sliptonic mentions above Job is here to stay - the good news is that Job is flexible enough to have more than on of them in a single document (another reason why Project wasn't a very good concept)

The question I'm trying to get at here is, is Job, and the fact that it has a Base object which defines the universe for that Job, really a/the problem?

IMHO for machining a single Part Job is the correct answer. What the Path WB is currently missing is a way of combining multiple jobs.

[herbk]

Good morning sliptonic,
good morning mlampert,

You don't see any reasons but trust me, they are there.

That i realy trust, no doubt... And if a "old way" to do somethig has too many limits you have to go a "new way", - also no doubt.
I only want to point out early, if, in my mind, some "problems" comming up - and i know that things need time,..

Now I realise that we are starting to have two different discussion in this thread

yes, but it comes up because the themes are related...

The question I'm trying to get at here is, is Job, and the fact that it has a Base object which defines the universe for that Job, really a/the problem?

In my mind yes it is a problem, or better it will be one in many cases...

Machining a single Part is only a good workflow if you have a machine like this:
On this type of machine will be done each part at its one.

But much more people, especially private users, are using CNC machines like this:

At this type of machine you mostly froduce more than one part et once. And so the workflow (the workflow on the machine) is totaly different.
You don't workpart after part ... you work tool by tool, because it is the path with the least effort,.. you first drill all holes, than you make all things with tool 1 then all with tool2, and so on...

"Job" offers a dropdown menue for the "job type". in that moment there is only milling to select, but maybe for that two types of machine and it's differnt workflows it is necessary to go two different ways, to create the pathes for, too.

[mlampert]

"Job" offers a dropdown menue for the "job type". in that moment there is only milling to select, but maybe for that two types of machine and it's differnt workflows it is necessary to go two different ways, to create the pathes for, too.

Interesting idea, we could have a "Router" job. We'll have to think through the implications and how this would look like from an implementation perspective.

Personally I'm not very familiar with the router workflow. If you could write that up, we can start looking into it.