Ticket #4111 - climb / conventional (inconsistent cut direction in 3Dsurface)

[Russ4262]

A little advice please.

Sure thing, Sir.

Presumably this is the text which is seen on all the path tools which offer the choice. Why don't is see it in the GUI?

Yes, those are the choices, but only for 1/2 of the GUI. With this particular edit only the choices for this tool will be affected.

Part of what makes FC unique is the separation between the GUI side and the command line side. For this reason if one wishes to address a property list, like obj.cutMode, accross all GUI interfaces, the property list must be edited on the general GUI side, which is Qt based, and in the python side where you have made your edit.

The good news is your edit should be visible and usable, but only in the Data tab -> Properties View for Cut Mode. It will not be visible in the window editor for the tool - that is the Qt side of the GUI, and is not python based, except for the interfacing with the command line side.

I don't have FC in front of me, but look in the property list in the Data tab for the Cut Mode property. Your updated selection labels should be in effect there, but not in the window editor available upon initial clicking of the 3D Surface tool icon. Also, you should know, based on your description of the edit, you will likely have to delete your current 3D Surface path and recreate it with your updated PathSurface script now in place.

Hope I addressed your issue. Unfortunately my ability to provide more details and exact FC terminology and references is hindered without FC in front of me. I'm on an Android device.

Glad you're tinkering.

Russell

[freman]

Thanks Russ, that explains a lot. A few questions:

1. Why is there this dup of content which needs to be manually synced? Are there cases where the two need to be different?
1b. Couldn't this be done programatically using PySideUic.loadUi() ?

thanks.

PS. can you confirm that I'm not misunderstanding what we have in terms of tool path direction? 3D surface is based on line which is expressly intended to produce same direction cuts and at first view seems to include lines to flip min,max to make that happen. Yet my example model shows exactly the opposite is being produced, with alternating cut directions. Am I right in thinking that 3D suface path tool should have produced same sense paths on that model? thx.

If the two version of the UI text do not match, the path fails to produce anything. I get this error on the report window:

Code: Select all

'Conventional' is not part of the enumeration'

[freman]

OK, I just did a fresh pull this morning that the coolant droplist is now in place and the previous error disappeared. Thanks dub for fixing that one.

However, there is no property editor for cut pattern.

obj.CutPattern = ['ZigZag', 'Line']

Since ZigZag is the first entry presumably this is what my path defaulted to. That would seem more consistent with the results.

I wanted to check the contents of my FCStd file so I unzipped it.
There is document.xml where I find cut pattern has integer value "0".

I do not have direct access to this from the GUI, so it seems that zig-zag is the default and that seems consistent with the output. I hand edited it to "1" and it made no difference, so it seems that the value is not read or is ignored.

I'm a little confused since Russ said zigzag was not yet complete and only line was. Can any one comment on the state of development here? Is this a slip up and it should be defaulting to 1 to give line output?

Thanks for any clarifications.

[Russ4262]

@freman

I glanced at PathSurface again as my children and I play the matching game...

A couple things:

1. I've noticed from your technical language that you are more familiar with programming than I. For that reason, I may not be able to answer all your technical questions. To avoid ambiguous, inaccurate, off-target, or incomplete answers for some of the more technical questions, you may have to direct those at one of the actual programmers in the forum. Some questions are just above my skill level.
2. Looking a the PathSurface code, it looks like "Line" is not properly implemented to observe CutMode: Conventional/Climb. If it were, it would cut a line, raise, return to beginning of line, jog laterally the StepOver value, and proceed in a parallel path to the first line, repeating this process. I recall leaving "Line" functional, but it clearly is not complete.
3. Zig-zag is not correctly coded either. However, the current "Line" option is behaving like an unfinished "Zig-zag" - lacking the rotational influence.
4. It appears neither pattern available is really correct, as you have discovered with much frustration.
5. Please feel free to join in the coding boom happening here in PathWB and fix this pattern issue.
6. I'm glad to work with you and assist as I can. Work has me busy, as well as a separate personal/work-related coding project.

I'm glad your're invovlved, Sir.

If I have some time tonight, I may load PathSurface in the text editor and look at what changes are necessary to implement a correct "Line" pattern. I know "Zig-zag" will require a more complex algorithm to account for the angular rotation, as is available in other ops with "Zig-zag" pattern available.

I can be found in https://gitter.im/FreeCAD/Path from time to time.

Have a great weekend.
Russ

[Russ4262]

1. Why is there this dup of content which needs to be manually synced? Are there cases where the two need to be different?
1b. Couldn't this be done programatically using PySideUic.loadUi() ?

1b. might be over my head.
Based on what I've seen of GUI interface with python, I think the possibility of some user inputs(combo boxes, checkboxes, etc...) being produced/coded dynamically in python and passed to the Ut GUI at run time would be possible.



1. Some of the properties(settings) of operations/tools do not need to be exposed to the user in the window editor, but only made available in the Properties List view - like more advanced settings, or trivial settings that are not expected to change much. Another reason for the duplicity, is the separation between the GUI and command-line sides of FreeCAD. The addProperty() methods (and related list declarations like obj.CutPattern=['Zig-zag', 'Line']) are for the command-line side first, but also as required variables for storing the same input from the GUI side, when available. We do have a percentage of the FC community that uses the command-line side regularly.

The python-GUI interface has a built in set of functions that convert the addProperty() functions and related values into the two-column GUI table that is the Properties List view. For this reason, I think some of the other inputs(combo boxes, checkboxes, etc...) could be created dynamically on the python side and passed to the GUI side to unify the two. But, what we have works well, and once understood is manageable (IMHO). There are also great resources (@sliptonic and @mlampert) who are more than willing to assist new-comers to the FC code structure and class structure.

Great questions. Not so sure my answers are technically up to par, or adequate for your inquiry.

Have a good one,
Russ

[freman]

many thanks for the detailed replies Russ. A great help. It seems like current output is closer to ZZ even if it is not complete. I'll do some more reading and see whether I can develop enough understanding of all this to start poking it around a bit. The paths are there, if it just did them all in the same direction it would be a start. Properly doing climb could be a complex issue on a more generalised shape but doing it on my test piece should realisable.

If you are using a text editor you may find Geany good. It's programming syntax aware editor. ( www.geany.org ).

enjoy you time with the family, sorry to get in the way.

[Russ4262]

enjoy you time with the family, sorry to get in the way.

I am enjoying my family, thanks.

You're not in the way, nor interfering, Sir. I did not mean to come across as crass, cross or rude. Collaboration with an international community here on the FC project presents unique challenges inherent to the very type of project and those involved. It's fun. And, it has its challenges for the ambitious and problem solvers. Some of us are able to be involved with some regularity, some, like @ChrisB, just live in the FreeCAD matrix and are available 24-7, while others of us are like the seasonal storms on the Atlantic, that when present are intense and exuberant, but then dissipate and leave others wondering what just happened and making inquiry as to where we disappeared for the unknown length of time - to only reappear in another season some time later.

No worries here, @freman. Glad to have you in the FC community, along with all the others who we interact with here in the forums!

Russ

[Kunda1]

Collaboration with an international community here on the FC project presents unique challenges inherent to the very type of project and those involved. It's fun. And, it has its challenges for the ambitious and problem solvers. Some of us are able to be involved with some regularity, some, like @ChrisB, just live in the FreeCAD matrix and are available 24-7, while others of us are like the seasonal storms on the Atlantic, that when present are intense and exuberant, but then dissipate and leave others wondering what just happened and making inquiry as to where we disappeared for the unknown length of time - to only reappear in another season some time later.

By golly, if that isn't a poetic summary of an important aspect of Open Source that is not fully understood. Well said Sir @Russ4262

[freman]

Yes very poetic, I suppose surface3D does look a bit like it's been hit by a tropical cyclone right now Better call out the red cross !

[RatonLaveur]

I like to look at it as the concrete foundation for a new building more than a natural disaster location.