M6 Remap for ATC with carousel

More
18 Nov 2021 23:49 #226934 by Michael
Also further down in the document:
settings.tool_table This is an array of CANON_TOOL_TABLE structures (defined in src/emc/nml_intf/emctool.h), with CANON_POCKETS_MAX entries. Indexed by "pocket number", aka "slot number". Index 0 is the spindle, indexes 1-(CANON_POCKETS_MAX-1) are the pockets in the tool changer. On a random toolchanger pocket numbers are meaningful. On a nonrandom toolchanger pockets are meaningless; the pocket numbers in the tool table file are ignored and tools are assigned to tool_table slots sequentially.

Please Log in or Create an account to join the conversation.

More
21 Nov 2021 17:47 #227211 by andypugh
This refers to the data from the Python interface.
I think that the HAL pin iocontrol.0.tool-prep-pocket should correspond to the pocket number column in the tool table.

Please Log in or Create an account to join the conversation.

More
21 Nov 2021 19:10 #227220 by Michael
It probably does but with an umbrella tool changer there is no pocket prep needed. To me it seems that it would be easier if non random used the pocket numbers in the table. The other issue with this is that tool table editor doesn't reflect a sequential order of the actual tool.tbl and it is possible to make a tool table entry in the wrong spot that won't be sequential on the tool.tbl

"On a nonrandom toolchanger pockets are meaningless; the pocket numbers in the tool table file are ignored and tools are assigned to tool_table slots sequentially."

If it will help I can replicate this with screen shots. But to me it seems like very odd behavior considering the ability to just use the actual pocket on the table. 
 

Please Log in or Create an account to join the conversation.

More
21 Nov 2021 20:25 #227227 by andypugh
The expectation always was that a tool-changer would use the HAL pins to know which pocket to align to the tool head.
That works as expected, the pin value matches the pocket column number.

The Python interface linuxcnc.stat().pocket_prepped does appear to give the index number in LinuxCNC 2.8, so is not useful.

You seem to be reading the "code notes"?

What are you trying to do? What isn't working?

If your changer can not use the HAL pin then you need to do a bit of work in your Python code (assuming that this is a Python remap). There is an example of how to do this in the stdglue routines:
github.com/LinuxCNC/linuxcnc/blob/master...glue/stdglue.py#L125

Please Log in or Create an account to join the conversation.

More
22 Nov 2021 00:47 - 22 Nov 2021 00:51 #227257 by Michael
I have it all working but the fact that it doesn't use the pocket number from the table and instead goes in order of tool listed in tool.tbl creates some workflow issues. It's just an undesirable behavior.

Typically I would have a tool.tbl with say 50 tools. I should be able to assign each a pocket number where they reside up to my max of 22. The remaining 28 tools without pocket numbers assigned exist on the tool table but would not be callable.

If I wanted to have T2 in P2 and place T50 in P2 it should be just as easy as editing the tool.tbl pocket numbers and placing the physical tool in that pocket in the carousel.

Currently if I did that and called T50 the carousel will rotate to P6 (wrap around 22+22+6=50) and place that tool in the spindle with the offset of T50. This is because the physical order of tools in tool.tbl assigns their actual pocket number and the P value in tool.tbl is completely ignored.
Last edit: 22 Nov 2021 00:51 by Michael.

Please Log in or Create an account to join the conversation.

More
22 Nov 2021 23:28 #227337 by andypugh

I have it all working but the fact that it doesn't use the pocket number from the table 

 

Define "it"...

 

Please Log in or Create an account to join the conversation.

More
23 Nov 2021 02:07 #227357 by Michael
It would be the internals of Linuxcnc. The commands to the carousel are based off the order of the tool.tbl list and not the pocket number assigned within the document.

My changer works fine as long as the actual table file has whatever tool numbers listed in order they will be called based of the order of the list. I can assign whatever pocket number to them within that file but Linuxcnc completely ignores the P value and just goes down the list.

Please Log in or Create an account to join the conversation.

More
23 Nov 2021 09:43 #227388 by andypugh

 but Linuxcnc completely ignores the P value and just goes down the list.

No it doesn't. It sets the HAL pin correctly, for example. Similarly the stdglue routines set the #<_pocket> parameter correctly. 

How is the pocket number passed in to your ATC? If it is a Python remap then you need to get the pocket number with the function that I pointed at earlier. 

I agree that the stat() object gives the wrong number. 
 

Please Log in or Create an account to join the conversation.

More
24 Nov 2021 06:53 #227478 by Michael
My tool change is not pure python. It is an ngc with the stdglue.

Let me see if I can explain it a better way. This is my tool.tbl file in this exact order
T1 P22
T2 P21
T3 P20
T4 P19
T5 P18
T6 P17
T50 P16
T8 P15
T9 P14
T10 P13
T11 P12
T12 P11
T13 P10
T14 P9
T15 P8
T16 P7
T17 P6
T18 P5
T19 P4
T20 P3
T21 P2
T22 P1


I call M6 T1 G43 and the carousel will move to pocket 1 of the carousel and load that tool but display the tool loaded as T1 when in reality it loaded T22. The P value was ignored (should have went to pocket 22) and it assigned pocket values based on the order of the list. So continuing on:

Call M6 T5 G43 and it goes to pocket 5 (P value of 18 is ignored)

Call M6 T50 G43 and it goes to pocket 7 (P value of 16 is ignored)

So something in the non random tool changer logic of an NGC remap of M6 causes the P value not to be passed as the pocket number and instead assigns pocket numbers based on the order the tools are on the list.

Please Log in or Create an account to join the conversation.

More
24 Nov 2021 08:37 #227479 by andypugh
Did you code the remap yourself? does it use the carousel component?

Please Log in or Create an account to join the conversation.

Time to create page: 0.280 seconds
Powered by Kunena Forum