LinuxCNC Features - a kind of NGCGUI

Hi Fern,
Hi Nick,

as I said before: I have no automatic tool changer, and normally I write only
G-code working with one tool. That is one thing you find in my subroutines...

What I start using a tool changer ( or write G-code for someone else having a
tool changer):

How do I get the tool diameter???

In all of my subroutines, I do the tool compensation by calculating the offset in G-code by myself.
I never used the tool offset functions from G-code. So I allways have entered the tool diameter
as a parameter.

When I now write G-code for tool changing: I know I have to give the G-code the tool number.
And some kind of hardware (or manual) will change the tool.
But then?
How to calculate the path offset when NOT using the g-code internal functions?

Do I have to enter tool number AND diameter as a parameter?

Or is there a trick?

I just reviewed the system parameters of LinuxCNC.
I have not found a system parameter where I can read out the diameter of the active tool.

Any hints?

Thanks,

best regards,

Martin.

Hi Martin

turbospeedskater wrote: But I am using a mouse. not a touchscreen.

So do I

turbospeedskater wrote: I think, the original one is better for touch screens.
So can we have both? Selectable vie commandline parameter?

Yes, both are available. I left the menu as standard because I think this is what most
people will use with the larger icons even with a touch screen.
The "top_features toolbar" is also standard and the add "+" button
is available only when USE_ICON_VIEW_DIALOG is set to True in features.py
Images can be resized easily let's say to 80, 90 or any pixels size that best suit your display
Same for icons in the menu.

Catalog 'mill.xml' is the same everyone actually use except for this change :
you add <SEPARATOR/> where you want some in the menu.
This line is ignored while building the dialog.

One change in the "top_features toolbar" is that you decide how many TOP features you want
in the left part of the separator and they do not show twice. The TOP are cumulative use
and will change much in the beginning while the others are the other ones you use in the session.
The usage file is saved in the catalog folder as "catalog_name.xml".use

turbospeedskater wrote: Your windows with the two treeviews is also a good idea.
The only problem I see there is, that on low resolution screens, the height of the
display may be too small to use it. Can the bottom treeview part be moved
right of the top one (also switchable via commandline parameter or config file)?

Yes it can be easily done, will I implement this ?

Placing it on the right would mean to resize Features
(a dialog to configure this is already accessible via a menu even when it is embeded in LinuxCNC).

If you have a low res screen, It may then leave not much space to see the result.
The purpose of Features is to create ngc code easily while seing the result immediately after any changes.

What I am planning is a button that would switch from 2 views to a single one and back.
When in 1 view mode, PARAMS would all be available to modify in the view,
and in dual mode params are only in the bottom one and only the COMMENT is editable in the top view.
(Last mods planned is the use of other widgets in the bottom view, like checkboxes, comboboxes, spinners,
etc. by only changing the param "type" in ini files. When done I think the interface will be the best it can be, or will it?
Who knows what new ideas someone can come up with ?)

My work computer has a screen of 1600X900 and I think it is a very good choice.
I purchased it used for a very low price.

turbospeedskater wrote: One thing we should discuss is my work on the subroutines folder:

Have you had success in using it in your menue structure?
There was one post saying, only the top level is working.

I did not try much, I am currently finalizing the interface

My opinions about subroutines now ?

Nick has done a fantastic job so far. With the interface and subroutines.
He designed it so anyone can create his own code and ini file to suit their needs.

However, like the interface needed refinements, the subroutines also need some.
In order to become the standard tool to use with LinuxCNC, we will have to come up with standards.

I think a feature is like a snippet of code, you build a complex program by selecting the ones you need
and set parameters accordingly. They should give unlimited choices, like using 4 or 5 different tools
in the same job, use templates, reuse part of code anywhere in a new job, etc.

I think a feature should have a significant display name but short like 'Radial Array' and short type name like 'rad-arr'
and be limited in parameters, like 10 or 12. If more are needed they should be part of another one.
Ex : Cut start, cut step and cut depth should be in a 'Group' like which should be named 'Task'
and include anything else that would make a standard for any task and include anything else as items like tool change,
arrays, circles, etc.
Naming rules should also apply to PARAMS. Avoiding numbers that do not help while writing code.
Tool_tip should be helpfull and used for every param.
Maybe 'help' should name a file that would be easily edited with a tool like Amaya (I think that file should not include
the image png because it would be added automatically, but anything else could be used to make a good help)

Folders should be standardized also and writing new subroutines and ini should be well documented

And using your own code and folders the way you want it should remain.

About tool diameter, you set the diameter of the tool in the tool table (under Folder menu).
When changing tool, this is where LinuxCNC gets the diameter. Optionnaly, you also set the Z size
to use the tool changing sub I wrote that allows to use many tools in the same job. WITHOUT a tool changer.
But set the diameters first and use tool compensation G40, G41 or G42.
In 'youraxismill'.ini file, you may add in DISPLAY section
TOOL_EDITOR = tooledit Z DIAM COMMENT
this will limit the columns you see to the ones you need

Best regards
Fern

What I am planning is a button that would switch from 2 views to a single one and back.

I think this is the best option. When you have treeview for both the features and parameter you can navigate and change everything very quick just using the keyboard, which is not so easy for two veiws.

Last mods planned is the use of other widgets in the bottom view, like checkboxes, comboboxes, spinners,
etc. by only changing the param "type" in ini files. When done I think the interface will be the best it can be, or will it?

That would be awesome!
But it will be better if we will be able to use those widgets in the treeview as well. I'm not sure if it is possible or not. Treeview is a kind of complicated widget, I've spent a lot of time to get it work .
By the way can anybody write drag/drop for the treeview (for grouping objects)? Because I gave up. It just out of my mind...

In order to become the standard tool to use with LinuxCNC, we will have to come up with standards.

+100!
Probably we should make an article in wiki to define a standard for the subroutines and for named parameters of the features?

I think a feature should have a significant display name but short like 'Radial Array' and short type name like 'rad-arr'
and be limited in parameters, like 10 or 12. If more are needed they should be part of another one.
Ex : Cut start, cut step and cut depth should be in a 'Group' like which should be named 'Task'
and include anything else that would make a standard for any task and include anything else as items like tool change,
arrays, circles, etc.
Naming rules should also apply to PARAMS. Avoiding numbers that do not help while writing code.
Tool_tip should be helpfull and used for every param.

Agree.

Maybe 'help' should name a file that would be easily edited with a tool like Amaya (I think that file should not include
the image png because it would be added automatically, but anything else could be used to make a good help)

Do you think help should be a separate file? Opened on demand?
May be we can make online documentation, using wiki engine to create documentation for the subroutines - thus it can be easily changed / expanded / translated by everyone in community. Or if there's no need to have wide help, we can try to provide it inside subroutine.


PS There are some functions which are hard to realize with same way features work.
One of them Draw and Spiral depth procedure. the worst thing - everything has to be written in Gcode. I've done a procedure for spiral mill depth for the straight lines. But that's so ugly and can have a lot of bugs. :sick:
So I've decided to create a procedure that will make Gcode on fly. It will generate the gcode by given parameters and then will post it line by line back to the interpretator..
I'm not sure if this code is in the features main repo...
Yep it's there:
This is the procedure to call python script and get gcode back on fly
github.com/cnc-club/linuxcnc-features/bl...ll/draw/draw.ini#L46

Hi Nick,

Nick wrote:

What I am planning is a button that would switch from 2 views to a single one and back.

I think this is the best option. When you have treeview for both the features and parameter you can navigate
and change everything very quick just using the keyboard, which is not so easy for two veiws.

Instead of a button, I will have a View menu with options for 'Single View', 'Dual View (Top and Bottom)' and
'Dual View (Side by Side)'. People will select what they want and it will be done on the fly
I agree that a single treeview is easier to navigate with the KB, I forgot to try to switch from one tree to the other with TAB

Nick wrote:

Last mods planned is the use of other widgets in the bottom view, like checkboxes, comboboxes, spinners,
etc. by only changing the param "type" in ini files. When done I think the interface will be the best it can be, or will it?

That would be awesome!
But it will be better if we will be able to use those widgets in the treeview as well. I'm not sure if it is possible or not.
Treeview is a kind of complicated widget, I've spent a lot of time to get it work .

Yes, it would be better. I am doing it with Delphi but in different columns.
With gtk, we can use many different CellRenderers and custom ones but in the same column ? I will see later.

Nick wrote: By the way can anybody write drag/drop for the treeview (for grouping objects)?
Because I gave up. It just out of my mind...

I know you tried and wrote about that. Instead, I added some shortcuts :

• Ctrl + D : will duplicate/copy selected feature and it's children as next
• Ctrl + Delete : will delete selected feature and it's children
• Ctrl + Up : will move up selected feature and it's children
• Ctrl + Down : will move down selected feature and it's children
• Ctrl + Right : will 'append to a group/indent' selected feature and it's children
• Ctrl + Left : will 'remove from a group/unindent' selected feature and it's children

It makes it very fast and I think easier than using Drag and Drop
Selecting 'items' before adding a feature will add the new feature to selected 'items'

Also, double clicking a feature header line will expand/contract selected path
I have other changes I do not remember now

Nick wrote:

In order to become the standard tool to use with LinuxCNC, we will have to come up with standards.

+100!
Probably we should make an article in wiki to define a standard for the subroutines and for named parameters of the features?

Probably

Nick wrote:

Maybe 'help' should name a file that would be easily edited with a tool like
Amaya (I think that file should not include
the image png because it would be added automatically, but anything else could be used to make a good help)

Do you think help should be a separate file? Opened on demand?

Optionaly one attrib could be 'help_file' and loaded on demand and if not in attrib use 'help' if in attrib
Instead of Amaya, I think an editor like email or this forum message editor would be sufficient, there are enough format options.
Just have to see that it would load OK

Nick wrote: May be we can make online documentation, using wiki engine to create documentation
for the subroutines - thus it can be easily changed / expanded / translated by everyone in community.
Or if there's no need to have wide help, we can try to provide it inside subroutine.

I think before long, Features will need a web site with all the documentations, tutorials, etc
Online documentation would work only for included/official features.
I noticed this thread is very popular but not many readers share their comments.
I think they are observers waiting to jump in when enough refinements are done in the app and ini
Before long we will have to ask for contributors, for icons, web creating, NGC coding, etc

Nick wrote: PS There are some functions which are hard to realize with same way features work.
One of them Draw and Spiral depth procedure. the worst thing - everything has to be written in Gcode.
I've done a procedure for spiral mill depth for the straight lines. But that's so ugly and can have a lot of bugs. :sick:
So I've decided to create a procedure that will make Gcode on fly.
It will generate the gcode by given parameters and then will post it line by line back to the interpretator..
I'm not sure if this code is in the features main repo...
Yep it's there:
This is the procedure to call python script and get gcode back on fly
github.com/cnc-club/linuxcnc-features/bl...ll/draw/draw.ini#L46

As I wrote before, I was never able to make draw.ini work. It bugged at the beginning milldraw.py.
I do not remember the message but did not try to debug (had no debugger then)
(btw, if you have not installed Eclipse and pydev plug-in yet, you should)
Instead of draw.ini, I created my own 'polyline.ini' all in gcode. Yes it was difficult but needed to be done only once.
Any number of lines can be added and only thing not finalized is the entry (for compensation)
You can see the result in a prior post. How does it compare with 'draw.ini' ? I do not know.

Best regards
Fern

Hi Martin

turbospeedskater wrote: Hi Fern,
Your windows with the two treeviews is also a good idea.
The only problem I see there is, that on low resolution screens, the height of the
display may be too small to use it. Can the bottom treeview part be moved
right of the top one (also switchable via commandline parameter or config file)?

Your idea of having it side by side is a very good one. It is much, MUCH, MUCH better... If you have a wide screen.
This is my work computer with 1600 X 900 screen.
(Please do not pay attention at the fake job there, it is just to give an idea how it is to work with it)




Best regards
Fern

Hi Fern,
Hi Nick,

wow... looks great. I think I have to buy a 16:9 screen for my milling machine

In the moment I am thinking a bit about the G-code and parameter entry and so on.

Because I am only writing single tool jobs, I would like to know what is
normaly done if you have a tool changer.

I am normally not using tool correction from GCode. I am calculating
offsets in my subroutines. The big advantage I see is, that I can check
if the next operation is possible with that tool. (e.g. you can not mill a 3mm
radius if you have a 10mm tool....).

I am not sure what will happen if you use G41/G42 and mill a structure
too small for the diameter. I never tried... Any idea?

If I have a tool changer, and change to tool #x, I have to find out it's diameter to do checking.
In the meantime I have found, that there is a variable (#5410), where the diameter is
stored.

I would like to know: is that variable available also on other kinds of G-code controlled
machines? I think it would be nice if Gcode from Features is not limited to LinuxCNC use.

In General:
Maybe it would be an option to have two different "styles" of programming:
One with only one tool and the tool diameter as a parameter, and another
where you select the tool via it's number as a parameter and then get the
tool diameter from the #5410 variable....

What do you think?

best regards,

Martin.