[kvom]

It's hard to believe that an extra second of carousel rotation time would be that big a deal. Reliability would be the key IMO. Looking good.

Just made a 1-off part yesterday that took 9 tools; an ATC would have been convenient.

[AUSTINMACHINING]

It's hard to believe that an extra second of carousel rotation time would be that big a deal. Reliability would be the key IMO. Looking good.

Just made a 1-off part yesterday that took 9 tools; an ATC would have been convenient.

Agreed. Reliability #1. Nice work as usual Ray. I hear you kvom. The plastic part I posted in the other thread requires a lot of tool changes. The ops are so fast, it's not worth walking away from the machine. If it weren't for Rays PDB, it would be a real PITA.

[SCzEngrgGroup]

Finally, some real progress! Today I got the transfer arm lift mechanism working properly. It turned out to be surprisingly difficult to get it running fast, smooth, and quiet. After re-designing a few small parts, it's now doing all three, and, since it's a servo, and I can modulate current, it will allow me to detect not only where within it's stroke the lift is at all times, but I can also limit the applied force when inserting and removing tools, and detect if the tool is either stuck in the spindle or ATC receiver, or fails to properly insert into the spindle or ATC receiver. That will preclude anything on the ATC actually being broken or bent in the event of a jam, which is customary on every TTS-based ATC I've ever seen.

I'll try to post a video tomorrow.

Regards,
Ray L.

[SCzEngrgGroup]

Here is a short video of the lift mechanism in action:

http://youtu.be/CpDT-Y7-fmw

It's working nicely now, and certainly has plenty of power. I tested it with what is, by far, my heaviest tool - a 6.5 pound Glacern 4" face mill with R8 shank. It lifts it with no discernable decrease in speed.

Regards,
Ray L.

[LeeWay]

Nice! Looking good, Ray.

[SCzEngrgGroup]

I haven't given an ATC update for a while, because I've been chained to my PC getting my a$$ kicked by the firmware, specifically the motion control code. I've ended up scrapping almost everything I started with, and starting over, writing my own motion control library. I now have a very nice C++ object that encapsulates a complete servo controller - trajectory planner, encoder, PID, and H-Bridge. It supports all the commonly available H-bridge interfaces, and has settable limits for PMW range, velocity, acceleration, deceleration, encoder resolution, PWM deadband, and whether the motion is linear or rotary. Finally, just today, it is starting to behave, and is basically functioning correctly, though I still have several things to check out, and a few kinks to iron out. I still need to add a few features, in particular damping on the D-term in the PID. Due to the characteristics of the hardware, I'm pretty sure I'll end up having to use multiple control algorithms on the carousel to get the best performance. I expect to use a crude, but effective "fast" positioning algorithm to get close to position, then turn on the PID to do the fine positioning. I may be able to accomplish this just by on-the-fly switching of PID parameters. But, with luck, in a few more days, I'll have the carousel positioning working nicely. Right now, its positioning well, but not as quickly as I'd like.

Once the new servo library is fully debugged, it will be used to control all the motors on the ATC.

I also received a nice "care package" from a very generous fellow Novakon owner - a pair of Torus Pro X-axis ballscrews, and an NM-135 BLDC spindle motor and controller. The ballscrews will be used to build a power broaching fixture. The PDB and ATC both have broached parts, and doing them with a hydraulic press is not only slow and tedious, but also error-prone. - it's hard to ensure the broached hole is perfectly parallel to the part axis. The new fixture will make the operation both fast, and accurate. I expect to use both ballscrews, and two of the stepper motors and drivers I removed from my Pro (one driving each ballscrew). That should give me more than enough thrust to do the broaching, and should reduce the broaching operation on the PDB drawbar couplings from about 3-4 minutes apiece to probably 20-30 seconds apiece. The fixture will use swappable broach holders and workpiece holders, so everything can be kept straight and true. I'll use an Arduino and LCD display to build a simple controller, with programmable start position, stroke, and speed, so broaching will be a one-push operation once setup.

Regards,
Ray L.

[FannBlade]

I now have a very nice C++ object that encapsulates a complete servo controller - trajectory planner, encoder, PID, and H-Bridge. Ray L.

Lost me here,but I'm excited to see it working. :cheers:

[SCzEngrgGroup]

Lost me here,but I'm excited to see it working. :cheers:

Yeah, lost me too.... :-) I now know FAR more about PID and motion control than I ever really wanted to know. But it's working!

Regards,
Ray L.

[mklotz70]

I know you're really busy, but I'd love to see a build on the new broaching setup.

[SCzEngrgGroup]

I know you're really busy, but I'd love to see a build on the new broaching setup.

I will do a build thread on the power broacher.

Here is a short video of the ATC carousel, with only VERY rough tuning. It's actually working pretty nicely. This "jiggle" at the end of each move is largely due to the small amount of backlash in the gearmotor. There will be a light "drag" on the carousel that will largely damp that out. This is just the "rough" positioning, which intentionally over-shoots, then reverses to take out the backlash. Final positioning is done using a Hall Effect sensor that exactly aligns each tool receiver to the transfer arm, so that even if the receivers are not exactly evenly spaced, each one will still be perfectly aligned to the transfer arm.

http://youtu.be/MYSPjEgCwzU

This servo development has been interesting. I never realized before how many different variations of a PID there are, each with its own advantages and disadvantages. I haven't seen the exact configuration I'm using before, though I'm quite sure it has been used. But this latest incarnation seems to work nicely, is not very difficult to tune, and is much more stable than the others I've tried. I have no doubt I can improve it further by additional filtering, and better tuning. I was also able to reduce the encoder resolution, which lets me run higher speed, as the poor little Arduino was getting saturated with encoder interrupts at the high resolution. I can now run as fast as the motor is capable of without saturating, despite the rather lengthy floating point PID update calculations every 10 mSec.

Regards,
Ray L.

[SCzEngrgGroup]

The servo is now looking very good indeed. I've made further improvements to the PID algorithm, and improved the tuning (which is now rather easy). It now very quickly, and reliably, positions to within a single encoder count. The only (minor) issue evident in the video is the slight oscillation at the end of some moves. This is caused by the mechanical backlash in the gearmotor exciting the PID, and is completely eliminated by the addition of a very slight amount of mechanical damping on the carousel. I will add either a friction or viscous damper to the carousel to take care of this. For now, I'll ignore it, as it has no impact on performance, just aesthetics.

In this video, you'll see that when powered up, the carousel "homes" itself, to the tool 1 position, then begins making random tool selections.. The positioning is now working so well, I don't think I really need the Hall Effect sensing of the tool receiver locations. So, I am considering re-purposing that sensor to instead indicate whether each tool receiver actually holds a tool or is empty, which would give me a means of confirming that each tool is locked in place in its receiver, or removed during each tool change. It will also allow me to preclude attempts to remove a tool from an empty receiver, or put a tool into an occupied receiver.

http://youtu.be/p1RNP2c1kr0

Regards,
Ray L.

[kvom]

What's the planned method for loading the carousel? If it's like a Haas VMC, you issue a tool change for an empty slot, then load that tool into the spindle with the PDB. Reverse method for unloading.

I'm also wondering how the ATC knows the carousel position at power up.

[SCzEngrgGroup]

What's the planned method for loading the carousel? If it's like a Haas VMC, you issue a tool change for an empty slot, then load that tool into the spindle with the PDB. Reverse method for unloading.

I'm also wondering how the ATC knows the carousel position at power up.

There will be some convenient means of loading it, but I don't know the specifics yet. It will basically involve the user inserting a tool into the "active" position of the carousel, then hitting a key to activate the tool lock, then rotate to the next position.

The ATC not only doesn't, but can't know the carousel position on power-up, and making any assumption would guarantee problems at some point. That's why the carousel has the ability to home itself to Tool 1, as seen at the start of the latest video. It will also be assumed that the spindle is NOT loaded on power-up as well, and it will be the users responsibility to remove any tool from the spindle before using the ATC, as there is also impossible for the ATC to know the state of the rest of the system on power-up, especially following a system crash or other abnormal event.

Regards,
Ray L.

[neilw20]

With the simplicity of non-volatile storage these days, and the amount of time you can run on a battery, ( and do I remember you having one in the head for the PDB?) it is becoming quite easy to to have an absolute encoder, so that the system always can read the carousel position. You only need 4 at most 5 bits to to store. Just a cmos latch, at it's simplest. You already have lots of computing power with Arduino cpu.

[SCzEngrgGroup]

With the simplicity of non-volatile storage these days, and the amount of time you can run on a battery, ( and do I remember you having one in the head for the PDB?) it is becoming quite easy to to have an absolute encoder, so that the system always can read the carousel position. You only need 4 at most 5 bits to to store. Just a cmos latch, at it's simplest. You already have lots of computing power with Arduino cpu.

And absolute encoders are typically a LOT more expensive, and have more complex interfaces (several more signals at a minimum). Homing the carousel on power-up takes a few seconds. What problem are we trying to solve?

Regards,
Ray L.

[neilw20]

Well, absolute, in the effect, it does not need homing or referencing, more than once in a battery life, the extra bit needed.

[SCzEngrgGroup]

Well, absolute, in the effect, it does not need homing or referencing, more than once in a battery life, the extra bit needed.

Again, what problem are we trying to solve? An absolute encoder would add easily $20 to the BOM cost, which means at least $50-75 more in the retail price of the ATC. And if you want to do the same for the transfer arm encoder, double that cost. The carousel will be homed LONG before the PC has even booted, much less Mach3 is up and running, and the machine itself is homed and ready to run. It can also re-reference, or at least re-verify,itself every time it passes the home position in normal operation. So, what benefit do we get to offset the significant added cost?

Regards,
Ray L.

[Tkamsker]

I Agree absolute Encoder add no value. I retrofit an bridgeport 412 i which did Same Thing in Morning One init longest Way (1 Turn ) is 14 seconds then i know Tool 1 Position for sure ,..
I wrote now an linuxcnc component for that ,..


Gesendet von meinem iPad mit Tapatalk

[kvom]

I guess my question on power up is how the ATC knows which position is #1?

[SCzEngrgGroup]

I guess my question on power up is how the ATC knows which position is #1?

There is a sensor, just like on the X/Y/Z axes.

Regards,
Ray L.