Lathe tool wear

A very good solution input tool wear into a tool table .
Can I suggest ?

for example
1.for T4 we have a correction 10004 = -0.100
2.change correction, now -0.070
3.10004 = -0.070
4.It would be better to show 10004 = -0.170
Is it possible to do it ?
What do you think about that question ?

Take a look at the lathe_fanucy sim config:
github.com/LinuxCNC/linuxcnc/tree/master...im/axis/lathe-fanucy

(Though on re-reading perhaps I don't understand the question, does Gmoccapy do wear-offsets in the UI? )

andypugh wrote: does Gmoccapy do wear-offsets in the UI?

Linuxcnc 2.8.... pre .....gmoccapy 2.3.3.3

andypugh wrote: Take a look at the lathe_fanucy sim config

...is it possible to enter into Linuxcnc2.7.12 gmoccapy 1.5.9 ?

dinkata wrote: ...is it possible to enter into Linuxcnc2.7.12 gmoccapy 1.5.9 ?

yes :


M6 T#<tool>
G43 H#<tool> ##### OK

but :

O100 IF [#<wear> GT 10000]
G43.2 H#<wear> ##### ???
..I think it does not work : see picture, 10010 is not show !

I don't know how tool handling works in Gmoccapy. It looks like it might have its own (larger) tool table.
If you look at the actual tool.tbl file with a text editor, are the offsets there?

I feel that I might be leading you in the wrong direction here, it is entirely possible that Gmoccapy handles wear offsets at the user-interface level.

Gmoccapy uses the standard glade tooledit widget!
IMHO that one is not very well designed and the wear offset handling can be done in a more user friendly way.

I am working on gmoccapy 3 and that one hopefully will include a tool table based on sqlite3 with much more options and many industrial features.

So just wait a few years till it is presentable?

Norbert

newbynobi wrote: I am working on gmoccapy 3 and that one hopefully will include a tool table based on sqlite3 with much more options and many industrial features.

Let's not do that in the UI. Much better to make the tool table a database for all UIs.
I think Rene has done some work on that (as did I, a long time ago).

I did get it working, and have a fairly adaptable database schema . The plan would be to hide that complexity in the default installation, of course. The tooledit widget would just need to populate itself from the database and write back to the database. Then I would envisage a column-chooser type of thing for more complex setups.

Hallo Andi,

I am in close contact with Rene, we did already some work on that. We have a already SQL based tooltable, but there is still some way to go, as we would like to get rid also from the tool amount limit. If all that is done, and we are allowed to merge our patch to master, also the tooltable editor will be completely rewritten and can then be used as a normal glade widget.

I am trying also to get a Qt version of such a solution, as I am convinced, that some day we will have also Qt based GUI's.

Norbert