Some questions related to Path with the latest daily build

[burtbick]

Latest daily Path is looking pretty good. Haven't had a chance to dig into the code much. Got sidetracked with a number of other things, including upgrading the Z Axis stepper and driver on my CNC machine with one with more holding torque. Improved things a lot. Doing a bunch of testing of other CAM packages. For now I've settled on CamBam for handling the things that Path can't do yet. But I still am using Path for simple jobs and should be able to get back into digging into the code to see where I can help.

OS: Linux Mint 17.1 Rebecca
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.7957 (Git)
Build type: None
Branch: master
Hash: 2ac560e7b027590e8d6b534b84020d4c1624ece5
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 6.8.0.oce-0.17

Played with the Holding (tabs) a bit. On initial creation of the Profile I entered 4 and they were showing in the generated toolpaths. but I wanted to edit them a bit. I was able to edit angles (didn't actually but it is there), Heights (again didn't try but it is present) and lengths which I did edit. But the Data view is missing the position. So then I double click on the Profile and click on Holding. This brings up the list but only the first tab that had been entered is there. I can add the other 3 back in and they are present and accounted and displayed in the toolpath and back in the Data tab. But if I want to change the position again when I double click on Profile it loses all but the first Holding tab entry.

I'm assuming that this is a bug? Also shouldn't the position attribute be available in the Data tab for editing there?

I have a secondary issue that I'm chasing down. If I browse to a location other than /usr/lib/freecad-daily/Mod/Path?PathScripts/ to pick the post processor to use FreeCad always uses the one found in /usr/lib/freecad-daily/Mod/Path?PathScripts/ even when the Machine Post Processor property is showing the path to my other Post Processor is still showing.

If FreeCad is going to ignore the entered (or browsed to) path for the Post Processor then shouldn't the Post Processor property in Machine reflect where it is actually pulling the Post Processor from? When I was initially testing the grbl PP I was working on I was trying to load it from the directory in my freecad_build tree, but had to copy it to the above directory in order to get it to be recognized.

Also any changes to the Post Processor do not take place until FreeCad is restarted.

I'll try to dig the related information out of the source but just thought I'd ask

Thanks,
Burt

[sliptonic]

Played with the Holding (tabs) a bit. On initial creation of the Profile I entered 4 and they were showing in the generated toolpaths. but I wanted to edit them a bit. I was able to edit angles (didn't actually but it is there), Heights (again didn't try but it is present) and lengths which I did edit. But the Data view is missing the position. So then I double click on the Profile and click on Holding. This brings up the list but only the first tab that had been entered is there. I can add the other 3 back in and they are present and accounted and displayed in the toolpath and back in the Data tab. But if I want to change the position again when I double click on Profile it loses all but the first Holding tab entry.

I'm assuming that this is a bug? Also shouldn't the position attribute be available in the Data tab for editing there?

Libarea has the ability to do holding tags natively and I just wanted to get something bare minimum working. Since the tabs don't work with OCC, I haven't spent a lot of time on the GUI. In fact, It might turn out that we shouldn't use libarea tabs at all and instead do holding with a Dressup so that the solution works for both. Until I have a better idea of the long-term vision for holding tabs, I'm reluctant to spend too much energy on the dialog.

I have a secondary issue that I'm chasing down. If I browse to a location other than /usr/lib/freecad-daily/Mod/Path?PathScripts/ to pick the post processor to use FreeCad always uses the one found in /usr/lib/freecad-daily/Mod/Path?PathScripts/ even when the Machine Post Processor property is showing the path to my other Post Processor is still showing.

If FreeCad is going to ignore the entered (or browsed to) path for the Post Processor then shouldn't the Post Processor property in Machine reflect where it is actually pulling the Post Processor from? When I was initially testing the grbl PP I was working on I was trying to load it from the directory in my freecad_build tree, but had to copy it to the above directory in order to get it to be recognized.

Also any changes to the Post Processor do not take place until FreeCad is restarted.

I've already started to play with some ideas to make post processor selection and configuration easier and I'll take a look at this specific issue as I go. Since post processors are just python files that are imported, they're cached until reloaded. You can force FreeCAD to reload the post in the Python console with reload(postprocessorname).

[burtbick]

Understood.

I figured that the post processor was being cached, but it was interesting that it seems to ignore the full path the the post processor if you browse to it or enter it.

Thanks,
Burt

[sliptonic]

When it actually imports the post, it splits the imported Path/mypost_post.py string and imports the the mypost_post as current_post. The path part is essentially ignored at import time.

I'm not a Python expert but I think this is normal behavior. Python just searches the Pythonpath and takes the first module which matches the name.

My thought was that the stock postprocessors we distribute with FreeCAD would be in /Mod/Path/PathScripts and the user could copy or create new ones in the Macro directory to customize. I always expected the user would rename the copied files though. Is it an important use-case to have a multiple postprocessors with the same name?

[burtbick]

HI,

In my case it wasn't so much having post processors with the same name. For example I had created a new post processor named grbl_post.py. While I was working with it I had it in a directory tree under my projects/freecad... path so that I didn't have to sudo to write to the file (although I fixed that later by changing the permissions on the file under the freecad-daily path.

So when I used the browse button I went to the my path in my user account space rather than the /usr/share... path. Since the property field allowed that and stored the full path it was a surprise that it was using the grbl_post.py from the /usr/share... path instead of the pathname that is shown in the property field. It is NOT a problem to have it use the /usr/share... path location for the Mod/Path/PathScripts. It's a low priority but it would be better to force the browse operation to only browse within the installed path to Mod/Path/PathScripts and not allow selecting a different path for the post processor file. -

Now that I know what it's doing and the intent it's not an issue, other than just a usability improvement after other more critical things are added/fixed.

Did I clarify what I was trying to describe?

Thanks,
Burt

[sliptonic]

Yes. Thanks for the clarification.

I think what I'd like to do for usability improvement is have the setting for post-processor become an Enumeration (ie dropdown select)

The list of all available postprocessors in /Mod/Path/PathScripts and in the user macro directory would be built and de-duplicated. The user would select from the available posts and never see the full path at all or have to browse for a file.

If the user has a post in their macro directory with the same name as one of the official posts, it will be ignored in favor of the official one. Perhaps we could write a warning about this into the report window but I don't know how to avoid the situation. It will be on the user to rename to something unique.

[quick61]

Yes. Thanks for the clarification.

I think what I'd like to do for usability improvement is have the setting for post-processor become an Enumeration (ie dropdown select)

The list of all available postprocessors in /Mod/Path/PathScripts and in the user macro directory would be built and de-duplicated. The user would select from the available posts and never see the full path at all or have to browse for a file.

If the user has a post in their macro directory with the same name as one of the official posts, it will be ignored in favor of the official one. Perhaps we could write a warning about this into the report window but I don't know how to avoid the situation. It will be on the user to rename to something unique.

+1 !

Mark

[burtbick]

I will +1 that as well. It will definitely be clearer.

Thanks,
Burt