what's wrong with my tooltable?

Hi,

I generate a tooltable from my toolmanager and I expected, that the format was linuxcnc-conform ...
When I load the file in axis toolmanager - it get's loaded without errors, but when the backend reads the file, the Z-values are not as expected.
Diameter-values are processed and get the right value, but not the Z-value.

At first try i was pretty imprudent and used just the standard conversion for decimal values.
When Z-parsing failed, I tried fixed 6 decimal digits, added the sign, tried positive and negative values, but no way ...

Any hint is appreciated!

I tried an entry of your tool table sample and it seemed to work for me.
We would need more detail to help further.

Chris

Hi Chris,
.

I tried an entry of your tool table sample and it seemed to work for me.

Did you check the feedback tooltable in the status area of shared memory for Z-values?

When I start axis with the file from first post linuxcnc starts without errors, but when I read the tooltable from shared memory with my app, there are no Z-values. All other values are present and as expected.
This behaviour differs from all other tooltables provided by linuxcnc. Whenever a tool has a Z-value it is reflected in the status area of shared memory.

So I guess, when the backend writes a tooltable without Z-values, they would not be used with G43 or so.

Lately I thought, that Z-axis dimension could be to small, so I rised the min/max values from Z-axis and corresponding joint, but that did not change anything. Z-values keep as 0 value.
.

We would need more detail to help further.

Well, there's very little to tell.
I start axis (with axis_mm as default, sometimes with axis_9axis as crosscheck) from linuxcnc script (out of a rip installation) to have the linux apps setup and running and then I start my app from development enviroment (eclipse).

are you sure you are using the tool table you think you are?
are you reloading the tooltable if you change it outside of linuxcnc?
are you using g43 to actually use the offsets?

There are a lot of things that can be wrong - it is just hard to diagnosis here with nothing to test with.

The screens often do a lot in the background to hide details that probably should be handled by linuxcnc it's self.

Chris

are you sure you are using the tool table you think you are?

not sure completely, but yes - pretty sure

I start with the original tool table from axis. When I open the tool table of my app (which reads the status area) everything is fine. Then I overwrite the tool table with content from my tools and send a reload tool table command to linuxcnc. After a few seconds I read the status area again and get the messed up result.

This is consitent with the behaviour, when I start axis with the new overwritten tool table - as already mentioned. No errors (neither axis nor the error channel wich I read with my app), but no Z-values.
So something is wrong and I don't know, how to get rid of the error.
.

are you using g43 to actually use the offsets?

I don't use G43 already, as I work with sim configurations only.
The G43 failure was just an anticipated guess ...
.

There are a lot of things that can be wrong - it is just hard to diagnosis here with nothing to test with.

Well - you have the same test environment than I
I have my PC only - nothing more.

Well - you have the same test environment than I

Yes but I don't have your app - nor did I have a complete description of what you are doing.

I think maybe your expectations of what should happen is not what linuxcnc expects to happen (but I am guessing)

I again put your sample tool table in a sim config and loaded axis_mm.
turned on and homed.
t6 m6 for tool change
g43 for loading offset
and the offsets show up.

now if I modify the tool table outside of linuxcnc (so using an editor)
then reload the tooltable in axis
then issue g43
the new offset shows.

So there is nothing wrong with the tooltable you supplied in this thread.
It seems from your message you are not issuing G43 - so unless you have a special remapped tool change that adds the G43 then that would seem to be the problem.

Does this sound right?

Chris

Hi Chris,
.

Yes but I don't have your app - nor did I have a complete description of what you are doing.

Ok, if you like to give my app a try ...

I build a snapshot which may be usable. I collected some words to a readme, which of cause is no replacement for my todo list. But you may get an idea ...

Follow the instructions from the readme and then - best way to start is to start your favorite linuxcnc screen to get the enviroment up and running. Then start my app.
After that you can operate your app and watch my app

The archive is available at: https://c.gmx.net/@327787708095142731/h-nlhTfFSLi7NjsUPLTrbw

Hi Andy,

good thought! - so I cut off the comment, but no change.
Then I thought about fileformats and finally I thought: what if my numbers are to big and linuxcnc wants inch values?

So I added a divider of 2.54 with an unbelievable result.
First the tooltable that I wrote to disc:... and ...
as the numbers are too big for a screen shot, here is the log from the import of the new tool table from backendLook at the completely incredible sizes! And what I don't understand too: the numbers generated from backend have nothing in common with the numbers I sent.

But ok - now there's a trace that we can follow.

Andy - do you know, where the (re-)parsing of the tooltable (in code) happens?
Found it. Will extract it and debug few cases.

OK, and here the result:

I extracted loadToolTable() function to a standalone app together with a print function, that tells me the newly read toolTable.
Whatever format or value I export - with or without national language comments, loadToolTable works as designed and the print function prints out the expected values.

But ...

... as i generate the tooltable file from my app, I can see, what the backend tells me about the generated file.
And that situation keeps unchanged. No Z-values - no matter what I export or avoid to export.

For me that means: as loadToolTable works as designed and expected, another instance is corrupting the tooltable after reload. I have to confess, that I'm not the right man, to follow that trace.
I don't know nothing about the backend, so I'm messed up the same way as the backend.