Locations of all the job/operation properties and parameters

[JulianTodd]

This is to separate from a discussion started here:
https://forum.freecadweb.org/viewtopic.php?f=15&t=33067

I think I have finally got an account of all the places where parameters and values are stashed away for a job/operation.

A Job contains Tool, Operations (which contain Paths), Body, Stock, SetupSheet.

Each one of these has a two tables of Property-Values, called "View" and "Data".

Additionally, there's a whole other set of "Job preferences" and "Dressup" preferences that can be accessed through the Main menubar Edit | Preferences | Path.

These Property-Values fall into two categories: Those whose values are used in a calculation, and those whose values are copied into another Property-Value when something is constructed, but are not used directly.

I had a lot of problem understanding the SetupSheet, because I was looking for something that looked like a Spreadsheet, when in fact it is just another pair of Property-Value tables associated to a non-geometric icon.

Notice that there is a total of 12 of these Property-Value constructed when you create one Job object.

Now, we can -- and should -- have many different opinions about where in these 12 tables (14 after you create your first Path object) certain values should go.

Ultimately, it's not a critical problem for the expert, because they have learnt where things have been put, and they know how to keep looking in all the different places if they don't know where it is until they find it.

The problem is, however, a serious issue for the beginner who doesn't know where everything is buried and is easily mislead. Their revealed opinions are more important than an expert's.

For example, they don't necessarily realize that the Property-Value table is different depending on which thing in the Job they have highlighted. I thought it was all one table for the Job, but different sections of this table would show up at different times. (This really stumped me.)

Mystery: Why couldn't I find the SetupSheet?

Here are three Property-Values that appear in the Data tab when you highlight the SetupSheet.

"Step Down Expression": OpToolDiameter
"Safe Height Expression" : StartDepth+SetupSheet.SafeHeightOffset
"Safe Height Offset" : 3.00 mm

Now, the programming convention is that internal links don't reference the container (or they call it "self" or "this"), and external links do.

So the value "OpToolDiameter" looks like an internal link, and "SetupSheet.SafeHeightOffset" looks like an external link, which was why I kept looking for the SetupSheet elsewhere.

Due to the mixed up nature of the SetupSheet (containing both used values and to-be-copied values), I was very slow to spot the deeper logic that Properties called "...Expression" are copied to some other place (in the table of an Operation) where "OpToolDiameter" is then an internal link, and "SetupSheet.SafeHeightOffset" is then an external link!

You could get rid of this mixing up by either changing this to "StartDepth+3 mm" or making a "Safe Height Offset Expression" property which is copied into the Operation and referenced internally from there.

This would make things a lot simpler for beginners, confused by interlinking references to values in one place or another, because they'd know that when they have an Path operation, everything is there. No references to "SetupSheet.property" would exist anywhere. The setup sheet could then become part of the Preferences/template because it contains nothing but to-be-copied values.


Where do properties belong? Properties belong to the Operation, the Tool, the Stock, the CNC machine, or a mixture of these four. The mixed parameters can go in either place, and other CAM systems will separate these parameters out differently.

I'd like to make a single page in the wiki that lists all the properties used in a particular operation, and suggests where you can find each of them.

When I wrote a CAM algorithms, many of my parameters related to tolerances, because of the trade-off between speed of calculation and tolerance value.

Here the "Geometry Tolerance" is filed under the Job, but by it's description it really should be called "Machining Tolerance".

"Geometry tolerance" should refer to the tolerance to which the Base body model is converted to triangles (necessary for all free-form 3D surface operations).

And "Machining Tolerance" actually belongs with each individual operation, because some operations are finishing and some are semi-finishing.

In what I've worked on today I've done Contour machining with an "Offset Extra" of 0.1mm, and then a second single Contour machining finishing pass with "Offset Extra" of 0.0 to make the surface clean.

In this case the "Machining tolerance" of the semi-finishing pass can therefore be set to 0.05mm, because there it's okay to wander around within that width in the uncut material, but we need to tighten up the value for the finishing cut.

It's good practice to have some discussion and points of view expressed somewhere like here, so that when new parameters are required (for example, for any 3D surface machining), they can be put in the least-bad place to begin with.

[chrisb]

For example, they don't necessarily realize that the Property-Value table is different depending on which thing in the Job they have highlighted. I thought it was all one table for the Job, but different sections of this table would show up at different times. (This really stumped me.)

This is common usage in FreeCAD. Whenever you select an element in the tree the corresponding properties are shown and offered for editing.

I cannot add much to the rest of your post, as I never struggled with it, but increasing consistency is always good.

[mlampert]

Nobody (except developers) should have to deal with the SetupSheet - if it was possible to hide it in the Tree I would've done so. It's existence is the result of constraints in the FC object model. IMO all those settings belong in the Job itself, but they can't be there because that would introduce a circular dependency. In order to break that I introduced a separate data object for them.

As for the expressions referencing back to the SetupSheet - we wanted the ability to change the SafetyHeight and such for all operations through the change of a single value - without enforcing this approach. Again, due to the circular dependency limitation those global op parameters cannot be attached to the Job itself - so we did the next best thing which was implementing the management of those values into the job editor.

[JulianTodd]

@mlampert I can't see where the circular dependency is for the values in the SetupSheet. However if all its values were of the type "...Expression" (ie to-be-copied values) there would be no dependency on anything, as copies are made at the construction of each operation.

The only compromise is that you may introduce intermediate Property-Values into an operation that aren't directly used in that operation, but are in the calculation of other values that are used. But this isn't a problem; we have local variables in our functions all the time when it makes the computation clearer.


@chrisb This common usage in FreeCAD is not good for someone whose first point of contact is the Path module. This could happen, if they come to it from having designed their patterns for cutting in Inkscape or LibreCAD for example. 14 different Property-Value tables -- some of whose values are reflected in UI boxes -- relating to one machining operation presents a steep learning curve when you are not familiar with all the different dialogs.

And some of the values in the UI boxes do not appear in any of the Property-Value tables! For example, I wanted to shift my toolpaths 100mm to the right (positive X), and tried to use the "Move - XY" section in the "Setup" tab of the "Job Edit" UI box, and there was no way to set the value directly. All the controls are relative. So I had to type 100 into central box and click the right arrow once. (This feature is not in the documentation: https://www.freecadweb.org/wiki/Path_Job )

Unfortunately, while this drew two copies of the toolpath (original position in the Operations, and the shifted position in the Job), the output was not shifted. I have not been able to find any way to shift the toolpath in XY. The Placement in Operations makes no difference and there is no Placement on the Model group. In the end my final resort was to shift the origin on the controller.



Is there a process for coming to terms with the complexity already present when there are barely any toolpath strategies? What's going to happen with any 3-axis machining, with different types of linking, lead-ins and lead-outs, re-ordering, and path splitting (eg for down milling)?

[sliptonic]

And some of the values in the UI boxes do not appear in any of the Property-Value tables! For example, I wanted to shift my toolpaths 100mm to the right (positive X), and tried to use the "Move - XY" section in the "Setup" tab of the "Job Edit" UI box, and there was no way to set the value directly. All the controls are relative. So I had to type 100 into central box and click the right arrow once. (This feature is not in the documentation: https://www.freecadweb.org/wiki/Path_Job )

Not entirely true. Remember that the Job is actually working on a copy of the model. The copy (Job base object) is under the Job/Model node in the tree and each base object has its own placement. There's nothing to stop you from adjusting the placement manually. Open the Job/Model node. Select your object and change the X coordinate under Placement/Position.

I'm not suggesting this is easy/intuitive or user-friendly, but it is possible.

That said, the path UI can certainly be improved but it seems like UI/UX in FOSS projects always seems to lag.

Unfortunately, while this drew two copies of the toolpath (original position in the Operations, and the shifted position in the Job), the output was not shifted. I have not been able to find any way to shift the toolpath in XY. The Placement in Operations makes no difference and there is no Placement on the Model group. In the end my final resort was to shift the origin on the controller.

The toolpath is generated from the base model. It should update automatically if the base object moves. If it doesn't, try selecting the operation node, right-click and mark to recompute.

Is there a process for coming to terms with the complexity already present when there are barely any toolpath strategies? What's going to happen with any 3-axis machining, with different types of linking, lead-ins and lead-outs, re-ordering, and path splitting (eg for down milling)?

That's a pretty difficult and open-ended question to answer. I can't say there's any one process. I guess we keep making incremental improvements, fixing the flaws as we go

[c0depr1sm]

I just came accross a nice example showing Path's parameter and UI situation to beginners:

I was having issues when changing a cutting tool diameter: it had no effect on the only (face profile) operation of a simple job.
And would be so probably on any operation anyway: It looks like the job caches the value somewhere.
I got new diameter efffective after deleting the tool controler of the job and re-creating it with tool manager "creat tool controller" button to get a new tool diameter become efffective on a path. Is this working as intended? The tool is copied to the job. So ... unfortunately that would be a yes.

Steps:
1-Setup a tool and add a tool controller for that tool on a job. Create a path (face profile in my case). Execute the job check the Gcode, tool diameter is ok.
2-Get back on FC, click on the job's tool controller: no diameter setting.
3-Open the tool controller editor (double click) then the controller section shows. No diameter setting. (tool section is colapsed and I missed it)
4-Good willing beginner thinks " Well the right place ought to be the tool manager". then edit the tool in the tool manager. Mark operations for recompute and "Refresh"
5-Eventually discover there was no path change. Suspect a bug.
6-Delete the tool controller and add it again to the job from the tool manager. Then refresh path
7-Check and confirm the new path is right... And think about filling a bug report.
8-Meet FC Forum and become less of a beginner.

Ok, an expert would know the tool controller editor opens a copy from the job and has two section. The second one at the bottom (scroll down if need be). There is a "tool" colapsible section item which contains a diameter settings for the current instance of the tool used in the job.

Do I understand it right?

I had to cut a few pieces to start figuring my cumulative slight diameter adjustments had no effect.
Now Path is still in development and I am not complaining.

So the moto could be:

1- Parameters need to be effective when visible... and visible when effective. Corollary: Irrelevant settings (like the generic tool diameter setting) have to be out of the way or otherwise clearly labelled about their true meaning so they are not mistakenly considered.
2- Some parameters are hiden to beginners, while shown to advanced users. Using "advanced mode" or "advanced" colapsible ?
3- But -always- parameters have to be set right if hiden,. Corollary: unhidable when modified from default known good values.
4- And descriptions of parameters using figures are great (Thanks!)

# ifdef VERBOSE
I am coming out of the blue.
This is my first post on FC forum.
Tx Sliptonic for your great tutorials.
#endif

OS: Debian GNU/Linux 9 (stretch)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.15609 (Git) AppImage
Build type: Release
Branch: master
Hash: a14af0f2bd26f980d71be80a799ee48127bc7619
Python version: 3.6.7
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0

[JulianTodd]

@sliptonic The over-riding problem is that we've got no systematic way to document issues as they arise unambiguously enough so that people can look at them and decide if there is a consensus about what we all think -- especially if it differs from the author's initial intention. There is no effective place for debate.

So far, for every single issue that can be raised, there's someone out there who can immediately and specifically rationalize it. Even something as ridiculous as F0.0000 commands in the G-codes, that only one or two functions introduce into the Path objects by accident, but which every single post processor writer has to discover, debug and filter out to the detriment of their progress.

Anyway, here is an attached example where I've used the Move-XY in Setup of the Job UI panel to plot the toolpath shifted +30mm along Z (by filling in the central box with "10" and clicking on the right arrow 3 times).

A value which could be interpreted to mean "X+=30" appears nowhere in any of the SIXTEEN property-value tables that may be affecting it. I have done an exhaustive search. So, not only are there already way too many visible values, there are hidden values in here too -- doing stuff we don't know what.

[sliptonic]

@sliptonic The over-riding problem is that we've got no systematic way to document issues as they arise unambiguously enough so that people can look at them and decide if there is a consensus about what we all think -- especially if it differs from the author's initial intention. There is no effective place for debate.

There's two related but different things going on here:

1) effective place for debate.
On this I couldn't agree more. I think the forum is a poor place for design debate and discussion. It's too slow. It's too easy to be misunderstood. There's too much content to stay current. and there's no way to know whether the 'right' people even heard what was said.

I prefer IRC or Gitter chat. For a real discussion, Discourse, skype, google hangouts etc. is still the best bet. But you're right. We don't have an effective place to do this. I'm always logged into #freecad on IRC and there's a dedicated Path room on gitter which doesn't get nearly enough use. Suggestions? BTW, if a wealthy benefactor wants to fly all path developers to a common location for a summit, I can provide a list of available dates.

2) Consensus.
This is a FreeCAD culture thing. Getting any kind of consensus on plans is difficult impossible. There's no strong BDFL and the workbenches, at least some of them, operate as almost separate projects. Also, developers are coming on and going off all the time so there's very little long-term commitment.
Consensus on code is a bit easier. Small successful contributions lead to trust which leads to easier acceptance of bigger contributions.

As a result, the most effective way forward seems to be this:
a) Use the forum to seek help, explanations, and the preferences of users when options are available.
b) Go ahead and do it the way you think it should be done. (Start small)
c) Send the PR and let the debate happen around that.

I know there's tons of places where Path can be improved dramatically and we'll have to pick them off one at at time.
FWIW, I've been really enjoying reading your posts. It's good (and humbling) to have outside expert eyes on things and I've learned a lot already.

So far, for every single issue that can be raised, there's someone out there who can immediately and specifically rationalize it. Even something as ridiculous as F0.0000 commands in the G-codes, that only one or two functions introduce into the Path objects by accident, but which every single post processor writer has to discover, debug and filter out to the detriment of their progress.

Yep, that happens too. I think mostly people are trying to explain, not rationalize but I see your point.

Anyway, here is an attached example where I've used the Move-XY in Setup of the Job UI panel to plot the toolpath shifted +30mm along Z (by filling in the central box with "10" and clicking on the right arrow 3 times).

A value which could be interpreted to mean "X+=30" appears nowhere in any of the SIXTEEN property-value tables that may be affecting it. I have done an exhaustive search. So, not only are there already way too many visible values, there are hidden values in here too -- doing stuff we don't know what.

It looks like the Job object's placement property is hidden. The placement is still accessible via Python

Code: Select all

>>> obj = App.getDocument("boxshift30").getObject("Job")

>>> obj.Placement
Placement [Pos=(30,0,0), Yaw-Pitch-Roll=(0,0,0)]
>>> 

The hiding is done in /src/Mod/Path/PathScripts/PathJob.Py #241 Perhaps it should be exposed.

The GUI stuff doesn't bother me too much. Part of the roughness comes from FreeCAD document model which we really can't change. Also, any CAM system is going to have a lot of 'moving parts' so configuring jobs and operations will always have a certain level of complexity. We've come a long way to make it better and I think this will continue to improve over time. So far, our users have proven to be pretty forgiving and adaptable while we figure it out.

The algorithm problems, like what you're pointing to in the helix discussion are another matter. Fortunately, I don't think we're locked into an all-or-nothing need for consensus around a solution. Operations are atomic so an entirely new implementation of Contour or helix, for example, doesn't have to replace the old one initially. It can live side-by-side or perhaps as an Experimental feature until 'consensus' decides it's sufficiently mature that we can deprecate the old one.

[Giulio Buccini]

I revamp this post because I'm currently stuck when setting the step-down for an operation.

I usually do not rely very much on the SetupSheet, so my habits was to modify the Step Down value by entering a numerical value for every new operation I just added. This was enough to avoid the boring "OpToolDiameter" set as default.

Now I want to make some tests with different DOCs (deep of cut) and it would be nice to modify the step down just in place for all of the operations.
So I entered a fixed numerical value in the SetupSheet (i.e. 0.6 mm) and then I tried to enter for the operation step down property:

<<StepDownExpression>>
StepDownExpression
<<SetupSheet.StepDownExpression>>
OpToolDiameter / 5 (this was just to try an expression)
.
.
.
... and many other combinations

No way.
I always get the operation marked as error with the following description:
Failed to convert to quantity in property binding 'StepDown'

What the hell I should write to refer a property in the Setup sheet?
Help!
I'm lost...

[Giulio Buccini]

The expression

SetupSheet001.StepDownExpression

Seems correctly calculated to the value in the Setup-sheet (0.6 mm). But still something is wrong (see image below).

Selection_7624.jpg (72.68 KiB) Viewed 1851 times