ATC Project - Debug phase

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.

Sorry by the late response, have been quite busy...

Yes, I was responding to thuis thread. I'm under the impression that a) you got quite a bunch of problems having linuxcnc working, trying different distros, etc, and b) That there are other ATCs working but they are using encoder output while your project uses Hall sensors.

Am I wrong? If so, I beg your pardon...

Yes, you're observation about my struggling with distros and linux in general is spot on.  I think I've got a stable setup now, but the past year has been painful.  A non-computer guy with a little Windows experience trying to get LCNC running right in the middle of the Python2/Python3 mess...with a GUI that's somewhat experimental... I might not have timed things very well.

Regarding the ATC, it appears to be all set now.  I still haven't had time to run a physical tool change test, but all the motion appears to be sorted out.  My setup uses a closed-loop stepper (encoder to drive, not LCNC) and a 5:1 gearbox driven by a 7i76ED.

Carousel.comp is controlling the ATC disc rotation, and it's set to 'counts' mode (i.e. step & direction).  There's a single home pin triggering an inductive proximity sensor.  No hall sensors, no disc encoder - just a single home pin.

Once enabled, carousel.comp searches for the home pin and sets that location as pocket #1.  After that, carousel figures out the distance/steps to a particular pocket and also does the shortest-path calcs.  If the stepper loses steps it'll alarm and shut everything down so I'm not worried about pocket feedback.

The recently updated carousel.comp also has a feature for slow-searching to a pocket pin.  This feature was working for normal pocket commands, but jogging one pocket position would wind up missing the pin in one direction (but not the other).  I realized I didn't need this pin-search safety feature and disabled it.

I just got all the brackets and mounts back from the powder-coater and have it reassembled & rough aligned.  I'm still planning on writing up something a bit more detailed than my typical forum ramblings over the past months, but I'd rather wait until it's actually proven to work.