[WMFG]

Hi guys,

I already perform tool offset checking on our LB3000's, but robustly checking them on the Multus is a little more complicated.

If the operator is following procedure and using the touch setter, or AUTO CAL, you should be able to read out the offsets for any position / mode and check those. But, I want to protect against an operator manually entering a bad value in just one position, so I need to check everything x8:

• BT=0 / BT=1
• M602 (A) / M603 (B)
• G140 (main) / G141 (sub)

I'm just not seeing a way to specify these individually stored offset positions, using system variables:





Any ideas?

[Algirdas]

am I getting your point correctly?
You want to check al the tools offsets in order to be sure they are correct. Right?
Of You don't trust Your operator, just lock the Parameter function.

[deadlykitten]

hy i can help, discussing your actual methods for LB, and aproaches for other machines

besides offsets, there are also other things / kindly

[WMFG]

am I getting your point correctly?
You want to check al the tools offsets in order to be sure they are correct. Right?
Of You don't trust Your operator, just lock the Parameter function.

I don't want to lock the parameters screen. I want to safeguard against mistakes by checking each tool offset to ensure it is within a safe range.

If an operator builds a tool with the wrong stickout, or worse yet, touches off a tool into the wrong offset number. These can easily be caught with logic in the code.

The Multus just stores a lot more of this data per tool, which I haven't yet found the system variables for.

Six data fields: X, Y, Z, RZ, RX, P

Times 8 cutting position combinations.

Equals 48 data fields per tool

[WMFG]

hy i can help, discussing your actual methods for LB, and aproaches for other machines

besides offsets, there are also other things / kindly

Hello, I don't so much need help with the methods, as I do finding the system variables that store all the additional Multus offset data.

[deadlykitten]

hy look over these :
... main : vdtf + x y z
... wear : vdtw + x y z
... R : vdnr + x y z or vdnrr
... P : vnrpn or vdnrp

the argument [ mmkkkk, mmkknn, mmmkkk, etc ] may not be identical to the one after T, as multus T comand may vary, and is subject to parameter status, and also your way of coding comes into play

touches off a tool into the wrong offset number.

such things are into the complementary category, like, for example, using only 10 turret post out of 12, and all 10 ok, only that those posts that are not used will actually cause an interference

different aproach is required here

I don't so much need help with the methods, as I do finding the system variables that store all the additional Multus offset data

please fix 1st those system variables, and then, if you wish, will discuss

along the years, i have been proofing agains colisions with low frequency chance, and not caused by operators, thus there is a special suite of critical cases

i understand the rush for the system vars

Equals 48 data fields per tool

some automation can be added, thus making things work in background for you, like automatically T comands indentify in g-code, or custom tool change

please, feel free to ask anything / kindly

ps : hy mr bunny

[WMFG]

hy look over these :
... main : vdtf + x y z
... wear : vdtw + x y z
... R : vdnr + x y z or vdnrr
... P : vnrpn or vdnrp

the argument [ mmkkkk, mmkknn, mmmkkk, etc ] may not be identical to the one after T, as multus T comand may vary, and is subject to parameter status, and also your way of coding comes into play

Thank you for the reply!

I think you are suggesting, for example on tool #120, that the Z offset would be:

VDTFZ[120]

my manual suggests it would be:

VTOFZ[120]

But either way, is that for:

Main spindle mode / BT=0 / A
Main spindle mode / BT=0 / B
Main spindle mode / BT=1 / A
Main spindle mode / BT=1 / B
Sub spindle mode / BT=0 / A
Sub spindle mode / BT=0 / B
Sub spindle mode / BT=1 / A
Sub spindle mode / BT=1 / B

The tool's Z offset has discrete values for each of those.