ATC Project - Debug phase

Hi spumco,

I'm slowly catching up with the project. Carousel.comp seems to work just fine for the time being (index, 2 sensors, 16 pockets - need to work on mechanical alignment). I am now in the process of leaving behind gmoccapy as probe_screen does not work in python3 anymore.

I have looked at the source of probe_basic. If I understand it correctly, the interaction of the macros with the python based GUI visualization are done using (DEBUG, EVAL(...statement...)). The relation of toolnumber to pocketnumber is done using numbered parameters and takes place in macros. the ATC widget merely does visualization. Can you confirm this?

Seems straightforward then. There is just one more thing. I do not want to use numbered variables to track pocket numbers but rather the pocket number of the tooltable. Does anyone know, if the prolog statement forwards the correct pocket numbers within 2.9? This used to be a source of major headaches.

Thank You.

Best Regards
Guido

[Sorry, been a bit absent in the past few weeks. Landed a bid for some turning work that's been a time-suck.]


Yes, you have it exactly right as far as I've been able to work out.  Persistent variables are added to the .var file which represent pocket numbers.  All association with tool numbers are done through the macros.

Regarding the pocket numbers...  When LCNC is set to NONRANDOM tool changer it ignores pocket numbers.  And when it's set to RANDOM, then the spindle tool is installed in the pocket of the tool replacing it.

As I've pointed out in another post (and others have elsewhere), there is no middle ground for 'semi-random' tool changers. i.e. a carousel (or chain, or rack) where pocket number may not match tool number, but it absolutely must go back in to the same pocket it came out of.

This, I believe, is why ATC macros or ladder schemes are so complicated - they're all essentially workarounds for this LCNC blind spot.

It's also (probably) why the Probe Basic devs hide the pocket number column in the tool table tab.  With the Probe Basic scheme, there's no point in having a pocket number column which is ignored.  If you unhide it by editing the custom_config.yml file you'll see that all tools have a pocket number value of "-1".

And thus the ATC screen widget isn't just a fancy-but-superfluous feature.  It is, in fact, they only easy way to figure out what tool is in what pocket.  The only other way would be to somehow query the .var file and write those values to a constantly-updating GUI table.


Doesn't matter if it does or not...  And when I was trying to work around the issue that's when I discovered - or at least started to digest the fact - that LCNC ignores pocket numbers.  Tool number = pocket number; Finkle is Einhorn, Einhorn is Finkle.

You can put any pocket number you want in the tool table, but LCNC will only recognize the tool number if TOOLCHANGER = NONRANDOM

An alternative is to keep track of things with tool numbers... but you must edit your tool table so you only have tools #1 through #n (n = total pockets).  To switch tools to one higher than 'n' means changing the numbers in the tool table.  This is how (some) old-school CNC machines did it: you want a new tool... you call up tool #1, replace it in the spindle with some other tool, then adjust the tool table values for #1 to match the new tool.

A glimmer of light on the horizon is the recently-created Tool Database.  There's now a demo in axis, but there's no 'standard' database GUI to use.  I believe this would be useful for ATC tool-pocket management, but I simply don't understand much about it - much less how an implementation would work.  Based on past history, I expect it to be novice-user ready in about a week to never.

spumco wrote:

[Sorry, been a bit absent in the past few weeks. Landed a bid for some turning work that's been a time-suck.]

Code:

Can you confirm this? Yes, you have it exactly right as far as I've been able to work out.  Persistent variables are added to the .var file which represent pocket numbers.  All association with tool numbers are done through the macros. Regarding the pocket numbers...  When LCNC is set to NONRANDOM tool changer it ignores pocket numbers.  And when it's set to RANDOM, then the spindle tool is installed in the pocket of the tool replacing it. As I've pointed out in another post (and others have elsewhere), there is no middle ground for 'semi-random' tool changers. i.e. a carousel (or chain, or rack) where pocket number may not match tool number, but it absolutely must go back in to the same pocket it came out of. This, I believe, is why ATC macros or ladder schemes are so complicated - they're all essentially workarounds for this LCNC blind spot. It's also (probably) why the Probe Basic devs hide the pocket number column in the tool table tab.  With the Probe Basic scheme, there's no point in having a pocket number column which is ignored.  If you unhide it by editing the custom_config.yml file you'll see that all tools have a pocket number value of "-1". And thus the ATC screen widget isn't just a fancy-but-superfluous feature.  It is, in fact, they only easy way to figure out what tool is in what pocket.  The only other way would be to somehow query the .var file and write those values to a constantly-updating GUI table. [code]Does anyone know, if the prolog statement forwards the correct pocket numbers within 2.9? Doesn't matter if it does or not...  And when I was trying to work around the issue that's when I discovered - or at least started to digest the fact - that [b]LCNC ignores pocket numbers.  Tool number = pocket number; Finkle is Einhorn, Einhorn is Finkle. You can put any pocket number you want in the tool table, but LCNC will only recognize the tool number if TOOLCHANGER = NONRANDOM An alternative is to keep track of things with tool numbers... but you must edit your tool table so you only have tools #1 through #n (n = total pockets).  To switch tools to one higher than 'n' means changing the numbers in the tool table.  This is how (some) old-school CNC machines did it: you want a new tool... you call up tool #1, replace it in the spindle with some other tool, then adjust the tool table values for #1 to match the new tool. A glimmer of light on the horizon is the recently-created Tool Database.  There's now a demo in axis, but there's no 'standard' database GUI to use.  I believe this would be useful for ATC tool-pocket management, but I simply don't understand much about it - much less how an implementation would work.  Based on past history, I expect it to be novice-user ready in about a week to never.[/b]

[/code]
 

Hi spumco and thanks for confirming my guesses:).

With regard to your comment to nonrandom toolchangers:

I guess I need to extent the background information:
My setup is as follows:
-Carousel for 16 tools
-No tool change arm or mechanism
-Direct placement of tool in carousel by moving the spindle accordingly
-This is on a DIY router, speed and improvement of toolchange time is not a concern:).

Basically, the carousel is a rolled up rack. This also means that I am not using a random toolchanger, since I have to go back to the pocket a tool come from, drop it off and only then am I able to pick up a new tool.

Accordingly my M6 sequence roughly works as follows:

Check if tool in spindle
No: proceed to pickup sequence
yes: drop off tool either at carousel or at manual drop off point based on pocket number
Pickup sequence: Is tool in carousel?
yes: move carousel, grab tool, done
no: move to manual pickup, grab tool, done

Based on my experience (see old setup GitHub ), a setup like the one you describe as semi random (i.e. tools must go back to pocket but toolnumber may be different from pocket number) can be realized reasonably well.

The process was as follows:
I manually edited the pocket number in the tool table within gmoccapy. This allows to change the pocketnumber independent from the toolnumber AND the sequence of the entries in the tooltable (i.e. the line number of the entry). Using the change-prolog from stdglue.py provides four variables
Note: The comment "this is probably nonsense" is from the source directly.
current_tool is just that, the tool currently in the spindle
selected_tool is just that, the tool specified by "Tx"
current_pocket: Has been affected by bugs (I vaguely remeber that this was fixed) - In the past it would provide neither the pocket number nor the tool number but rather the line in which the entry is placed. Something you will not notice if you have sequential toolnumbers. I use a tooltable of >100 tools with substiantial gaps in the numbers (which works perfectly fine as of 2.8.x). Workaround: Handle the appropriate value with a persistent variable (see PB approach)
selected_pocket is just that, the pocket of the new tool - I have encountered instability here as well. There may be two ways of working aroudn that: 1) use "#<_hal[iocontrol.0.tool-prep-pocket]>" in macro (unstable as well at the time), 2) Get value from iocontrol.0.tool-prep-pocket using M66 and an motion.analog-input (I ain't stupid when it works)

This used to work just fine for me. I was thus thinking about maintaing that approach.
To make full use of PB's visualization capabilities, I have since understood how I can pass the relevant information to DynATC widget. Love it:). I agree with both spumco and lcvette that I could skip my old approach altogether.
>>There is a BUT comming though:
I would like to create a bit of code that allows me to manage assigning tools to pockets. I could do this manually with the aid of the visualization, but it would be great if I could just trigger a function that 1) determines if there is space in the carousel/rack 2) drops the tool right there and 3) stores the location of that tool.
This could be done using macros and the PB approach, but this is also why I wondered if I could write to the tool table from a macro (see other thread ).

GuiHue wrote:

1) use "#<_hal[iocontrol.0.tool-prep-pocket]>" in macro (unstable as well at the time), 2) Get value from iocontrol.0.tool-prep-pocket using M66 and an motion.analog-input (I ain't stupid when it works)

To explain what is happening here, #<_hal[ioconrol..... will return the value in that HAL pin at the point that the line is _interpreted_. This might, or might not, return the right value depending on queue-busters and remapping etc.
Reading the pin with M66 will read the pin at the point that the M66 is _executed_ so is much more likely to be correct.

Sorry to be late. I think you had either a modules or firmware problem in both machines.

Linux kernel has all modules it knows. So, you can take a hard disk from a machine, put in in another, and expect it to work, unless that machine needs a kernel module (driver) that kernel doesn't have. And there aren't any CDs with the module to be installed on a running system, windows-style. You need a kernel that has that module. This is an usual problem if one buys the lastest model on the market. On Debian, this means you need at least testing, perhaps even Sid. Of course, on Sid, you can expect to find another, untested problem. Easiest way to dodge that is to use Debian stable in machines that are at least a couple years old.

Also, Debian, unless you get the non-official download, doesn't include almost any firmware from the beginning, just because they are free software fundamentalists, and most firmware blobs are not free. Two items that usually need firmware are wifi and graphics cards. To dodge that, you can install with an ethernet cable, because wifi cards need that non-free firmware, get a running system (but perhaps it's just a non-graphic one), then look for missing firmware with "dmesg | grep firmware" as root. Then you can edit /etc/apt/sources.list, add "contrib" and "non-free" to the repository lines, and finally install the firmware you need. Then your hardware will work with full capabilities.

Last but not least, this is a nice thread. I'm not really sure why having an encoder is a problem, I think there are cheap ones that could perhaps do the work, but I found this thread quite interesting

Thanks for the reply... but did you mean to respond to this ATC thread?  If so, I'm not clear on your response.