LinuxCNC Features - a kind of NGCGUI

Hi Martin

I agree that saving to XML is a must so we do not have to start over again for the same or very similar job.

I do not know if you came across this page :

www.pygtk.org/pygtk2tutorial/ch-TreeViewWidget.html

but I think this one and the followings are where we will find the most usefull information, everything seems to be there

When this issue is solved I will work on the Duplicate/copy function issue where the ID is not changed

I am not a programmer myself but the owner of a small business. I learned Delphi from D3 then D5, D2006 and finally D2010. Most of the apps we use I programmed. Three years ago I started a motion simulator and then I learned microcontroller programming first with Arduino and quickly shifted to STM32 which is more powerfull but I had some time getting used to all the peripherals.

I only started last fall to use Python (and I will never be a fan) because I found too many things not working in Features.

Btw, does it happen to you that after LinuxCNC updates you have to re-install Features ? Is there a way to prevent updates to recreate the content of /usr/lib/pymodules/python2.7/gladevcp, /usr/share/pyshared/gladevcp/ and /usr/share/glade3/catalogs ?

I had to re-install about once every month

Regards
Fern

Hi,

I am sure now that the problem is in converting to XML and back

I modified the code to manipulate the treestore directly for moving up/down or inserting/removing from a group.

I then added 10 features and 4 groups.
I moved up/down, inserted/removed from groups about 30 times and ALL features stayed in their groups. I then added a new feature and every other features moved to the first group.

I moved everything so I can have about the same layout I had before then saved to XML, cleared the tree and reloaded with again ALL features in the first group. Every time it is converted, it is messed.

I think I am close to the solution.

Regards
Fern

Regards

Hi Martin, Nick

I solved the problem with groups

replace def treestore_to_xml_recursion(self, iter, xmlpath):
with the following including definition line

def treestore_to_xml_recursion(self, itr, xmlpath):
while itr :
f = self.treestore.get(itr, 0)[0]
if f.__class__ == Feature :
xmlpath.append(f.to_xml())

# check for the childrens
citer = self.treestore.iter_children(itr)
while citer :
p = self.treestore.get(citer, 0)[0]
itm = p.get_attr('type')
if (itm == 'items'):
pa = f.get_attr('path')
xmlpath_ = xmlpath.find(".//*[@path='%s']/param[@type='items']" % pa)
if xmlpath_ != None:
self.treestore_to_xml_recursion(self.treestore.iter_children(citer), xmlpath_)
citer = self.treestore.iter_next(citer)

# check for next items
itr = self.treestore.iter_next(itr)

To make sure the tabs are right,
download the attached file



Regards
Fern

Hi Fern,

great work!!! Thanks. Now it works!!!

As I expected, I have not had even a minute last weekend to think about this....

My next step will now be to write some kind of documentation about the things I have done
to the features library and about my subroutines. And I hope to get some input what functions
you and other user would like to have.
As long as I can do improvements in "xml" files, "ini" files and G-code: no problem...

Thanks,

best regards,

Martin.

Hi Martin

Hera are some screenshots

I prefer menus


This one shows a design bloc and reference lines that diasppear when '/' is toggled


Not sure I need to add arcs to this


This week I will try to solve the problem of copying where the ID is the same

Next thing I would like to see is this :
When many features a added and expanded, the tree is a little confusing. I intend to split the view in 2 where the top one would only show the header and items and the bottom view would show the params of the selected feature. What do you think about this ?

Regards
Fern

Hi Martin,

Problem with copy is SOLVED

This is before (note how deep levels can be)


No 2 elements have the same id


This is the function to replace the "Features.copy" one
I adapted the code for unmodified file. I hope it works for you
(I will later modify "import_xml" to copy to a specific position, only possible with File:Inport XML)


Regards
Fern

Wow!
Great work!

I prefer menus

Features was originally intended to work with touchscreen, that's why there are huge icons in the catalog.
Menus is a good option, we need to find a way to combine them, or make a choice between menus and big icons.

Btw have you already made those menus from those screenshots?

Hi Nick,

The "Add" menu part is defined in xml file similar to what you did and can be easily modified to suit needs. The base menu is part of "features.glade"

No change to ini files is needed.

There are different ways to make both as options:
It could be available as 2 different download or in the same download with 2 different folders, but it would be more difficult to maintain and improve, better in one file only
but we must consider that it would have all to be done by code instead of "features.glade" where I removed bars and added the menu. But by code would have to be done only once. I think it would be the best way.

I will post the needed files if you have a real interest in this

Regards
Fern

Hi Fern,

wow...... looks great!!
I would also prefer the menues!!

@Nick: Big pictures and touchscreen sounds good, I also have a touch screen on one of my machines, but:
During work with dirty fingers you allways have a dirty screen. So I don't use my touchscreen anymore. A mouse
will also work when it is dirty.

Today I would like to show you a snapshot of my work...:

Some words to the background of everything I have done to the
features/subroutines.

I use one of my milling machines mainly for making frontpanels.
That means: cutting out holes, drilling screw holes, engraving etc.

Over the time I have written a set of G-code subroutines for
ngcgui, that I have now ported to the features software.

Some problems I see when using ngcgui:
- It is not easy to operate for "normal" users without CNC knowledge.
- Bigger "programs" containing multiple elements are not easy to write.
- Saving is a bit tricky. Only the final G-Code can be saved from within
LinuxCNC and manipulated using a text editor. And for that you need
to know G-Code.
- Just changing small details to a bigger "program" without changing
anything else is also not so easy, because either you need to edit
the resulting G-code, or you have to do every step in ngcgui again,
without making any mistake. And that is not so easy sometimes.
- No change to make "groups" of operations and save them for later
usage.

With that knowledge about ngcgui I have found the Features software.

What I allways wanted was a system, where I (and my colleagues) can easy
write "programs" that can be easy saved, modified and optimized later.

And I allways wanted an easy way to make groups of operations that can be
placed as a group on any place of the working area. I would call this
"Library elements". As an example I would describe a Display as a
combination of a rectangular hole (for the viewing area) and 4 mounting holes
(for the 4 screws at the 4 corners). This "library element" has its own
center point (normally the center of the viewing area) and can be placed
the same way as a single element anywhere in the working area.
(BTW: This is the reason why I really need the items in groups stay in
the group where they belong to...)

With the "Features" software, all of these things can be easy done now.

When I had the 1st look into the features subroutines/icons/xml/ini files,
I thought I had to find a way to understand how everything works together.
Otherwise I had no chance to port my G-code subroutines to Features.

So I started by making a new and empty "subroutines" folder, and tracing
through the features.py to find out what is needed at what place,
and how the contents must be to make the whole thing work.

As a result, I have now a complete own subroutines folder, that is different
in many points from the original version published by Nick. I have copied and
adjusted most of the features from Nicks subroutines folder to my one, but
not all. Some of them I don't need, because I have had something similar and
I wanted to use the routines I already know. And some of them I can not test
(mainly the probing things), because I don't have a probe....
So in my subroutines folder you find a mixture of Nick's routines (with
modified internal parameter names to fit together with my cutting-params.ini),
and my routines. Also I have made some new picture/icons wherever I thought
it is usefull, or where I had no time to look for an icon from Nick's library
that can be used.

As you see from the result, I am not a graphical designer . But I think the
pictures and icons are usable.

The main changes I have done to Nick's files and folders is:
Naming of parameters and putting sublevel routine definitions in folders
with the same level and name. That means the folders are having the same
structures as the menue.

Also I have added some parameter error checking. Some I have added to the
basic job data element (cutting-params.ini), and some to the elements itself.

I am sure there are still 1000s of possibilities to enter wrong parameters, but
at least the mistakes I have done up to now are prevented from being done again...

I would like to publish a snapshot of my work, so you can check it and give me
a comment.

To use it without changing anything to Nick's routines, I would recommend the
following way:

Put my subroutines folder in the same level where Nick's subroutines folder is.
Rename Nick's subroutines folder to "subroutines-Nick" or anything alse.
Then you can set a symbolic link from the folder you want to use to "subroutines"
in the same level. By simply changing the symlink, you can then switch back
to Nick's subroutines.

BTW: maybe that is a usefull feature for the features.py itself: having the
subroutines folder as a parameter....

Some more words to the changes I have done:

- My cutting-params.ini (you find it under misc->tool) now holds also the tool
diameter. So you need only one parameter entry for a whole job.

- There is a new-params.ini (also misc->tool) element for changing parameters.
It will give you a copy of the active parameters if you don't change
anything. But instead of entering all parameters again if you want to change
e.g. only the milling depth, you can use this element and only enter the
new depth.

- Most of my elements have two additional parameters: ENA and COMMENT
- ENA can be used to enable/disable the execution of an element.
- COMMENT can be used to place a comment for documentation.

For the work I do, that is usefull in my opinion. COMMENTs make it easier to
understand what a program is doing if you have to do changes months or years later.
And ENAble/Disable makes it much easier to handle variations in production.

I will try to write much more documentation later on, but to give you something
to play with, I will publish my subroutines folder snapshot now.

DISCLAIMER: The subroutines I distribute here are NOT FINISHED. There are for
sure many ways that they produce wrong/unsusable or possible dangerous G-code.
So before starting your machine with the G-code from my routines, check it
carefully!!!

Best regards,

Martin

Amazing! There are new developers!

Can you create your repository at github? And post your code there? (best way form Features, and then post there your changes)
Or I can grant you rights to post to main Features repo, where you can create new branch, thus we would be able to merge them together later.

Git is very useful to track the changes that have been made to the code.