Hello Guest it is April 28, 2024, 04:04:28 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - HimyKabibble

181


My second ATC (still TTS, but could very easily accommodate 30-taper with pretty minor changes)

This will be quite a challenge, I would think.  Your TTS based design does not seem capable of gripping a stud. You must have something up your sleeve again.


Obviously the drawbar would have to be changed, but once that's done it should work.  Although, I could forego pullstuds and just use a screwed-in drawbar, as it it now.  I'd grab the toolholders by the groove, basically as I do now with TTS.  The carousel disk and spring "forks" would have to change, as would the fork on the transfer arm, but those are all simple changes.  I think it could be done by changing only about a half-dozen parts, and perhaps changing the "lift" travel.

I'm up to my eyeballs in KFlop stuff at the moment.  I've made quite a few improvements to my controller app recently, and I'm now doing some re-wiring in my E-Box, to clean things up.

Regards,
Ray L.

182
I am currently working on the sensors and control software. The last sensors are for the arm up/down and I could find no way to get those on the shaft that satisfied me. It is more complicated than it looks because the shaft will be covered by a rubber corrugated bellows below the gearbox and by either the same bellows or just a cover tube between the air cyl and the gearbox . .  and of course the whole shaft rotates. Also I'm not crazy about the air cyl being mounted separately from the gearbox. So I had to go on hold with that until I get a new cylinder with position sensors on the cylinder itself. I have the cylinder on the way and I plan to mount it on a tube supported by the gearbox.

My secondary task was working on the software, but I am building on top of the InTurn™ motor controller and in a moment of apparent masochism, I reasoned that this was a good time to do a major upgrade to the controller and launched into that. Among other things, I changed the interface from serial modbus to plug-in modbus . .  which took more than a few minutes.  :P  THEN, after a few brewskies, it seemed sensible to move my own development box to TCP modbus. After all the setup on MACH's side is similar to the plug-in serial, right? Well, in my setup, the "PLC" runs the modbus slave, so moving from 'serial anything' to TCP was a rewrite of a significant part of the code.

Those are my excuses. If I come up with better ones, I shall post them separately. The work is completed and working now, but apparently too late as it seems the tortoise has crossed the line.

So, Ray, if you are declaring your 'first' ATC completed including all sensors and controls, then all I can say is CONGRATULATIONS and where do I send the beer  :)

I accept your challenge to finish my first before you finish your second. However, I counter challenge you to see who is the first to have a completed and sold version operating in the field. I believe I have the drop on you there.  :-X

Anyway, at the time you took the checkered flag, I was on this lap: Note that the carousel gearbox can be rotated in 90 degree increments and the drive motor will be tucked in at final assembly. It is flying out there now to make the thing easier to work on and observe the actions.


Steve,

Wow!  That is an impressive bit of machinery.  I don't understand it....  But I'm sure it'll make sense when you post the first video!   :-)

I declared by first ATC "done" some time ago, and it's been in-service for a month or more, with no problems so far.  The only "missing" piece, briefly, was spindle "stopped" sensing, which is now provided by the VFD.

My second ATC (still TTS, but could very easily accommodate 30-taper with pretty minor changes) is now completely designed, and I'm busy sourcing components, and doing CAM.  If you beat me to the first "sold" unit, it won't be by very much!  I'm actually designing this one for a machine manufacturer, and designed it specifically to be almost trivial to adapt for virtually ANY machine by changing only the mounting brackets and the length of the tool transfer arm, which can easily be made adjustable length.  Not hardly as impressive as yours, but obviously aimed at a very different market.  I actually think it's about the best work I've ever done - a number of things I've never seen done the way I did them, which is the secret to the very low cost.  It can easily sell for FAR less than any ATC of comparable capacity and performance I've ever seen.  And, it does not really sacrifice performance either - I expect complete toolchanges to be under 10 seconds, from spindle stop to spindle start, compared to 20 seconds on my current one.  The motor-driven PDB is *tiny* - only a 2" x 3.5" footprint, 9" tall, but capable of well over 30+ ft-lbs drawbar torque (actually, it's capable of generating enough torque to just twist the drawbar right off...), but MUCH faster than my current one.  The ATC is 12-tools, with a fixed carousel, only 10" in diameter, and a high-speed tool transfer arm (relatively speaking - not in the same league as yours!).  The PDB, carousel, and transfer arm are all servo-driven, and there are sensors on *everything*, so virtually any fault will be detectable.  Only one air cylinder in the whole thing, a small one at that, to operate the "lift" that inserts/removes tools to/from the spindle.  Sensors include carousel position, transfer arm position, transfer arm tool "claw" lock sensor, transfer arm "lift" position, voltage and current for all the servo motors, and more.  With luck, the prototype will be done sometime in March.  Can't start fabrication until I complete the current build (biggest to date) of one of my other products.

When do we get video?

Regards,
Ray L.

183
I think Steve and I need to have another contest, to see if he can finish his *first* ATC before I finish my *second* one!  :-)  I've got the design done, just waiting on the new machine to arrive so I can get the final mounting dimensions.  This time I've gone with a very compact. fixed 12-tool carousel (vs 10 for my first ATC), mounted alongside the column - well out of the way of the user (never like having the carousel hanging next to the head....).  A high-speed transfer arm will move the tools back and forth quickly (not nearly as quickly as Steve's, but much faster than my current one).  I have an active "gripper" for TTS tools on the transfer arm, so I can rotate the arm pretty much as fast as I want, with no worries about the tool flying off.  The arm will be driven by a servo, so smooth, rapid motion should be very easy to achieve.  I'm keeping the Geneva mechanism, but re-designed it to internal, rather than external, Geneva for much smoother motion.  All told, only two small motors, and three very small air cylinders to perform all the motion.  One side-benefit is this design will be trivial to adapt to virtually any milling machine from an X2 to a full-size VMC, with only two very simple design changes - the bracket that attaches the whole thing to the column, and the length of the transfer arm.  Nothing else would have to change.  It would even possible to make a "universal" kit that could be adapted to almost any machine without any machining, other than drilling some mounting holes on the column.

Regards,
Ray L.

184
General Mach Discussion / Re: motion controllers working with Mach3
« on: January 24, 2013, 03:32:40 PM »
Ray are you saying that the MACH3 plugin for the Kflop does not work correctly?

(;-) TP


Terry,

No not at all.  The plug-in works just fine, but it has most of the same limitations as KMotionCNC.  You still have to do a fair amount of programming, unless your machine is very simple.  You still have to write code for limits, homing, probing, pendants, etc.  Now, the same code can be used for both Mach3 and KMotionCNC.  In fact, I set mine up so I can use the same code for Mach3, KMotionCNC and my own custom controller app.  Personally, if someone buys a KFlop, I don't know why they'd choose to use Mach3.  KMotionCNC will do all the basic stuf, and it is absolutely 100% rock solid.  You can even zoom, pan, and rotate the toolpath display to your hearts content, work on CAD/CAM or play AngryBirds WHILE the machine is running, unlike with Mach3.  It doesn't have all  the Mach3 bells and whistles, but presumably one goes to KFlop for stability more than anything else, no?

Regards,
Ray L.

185
General Mach Discussion / Re: motion controllers working with Mach3
« on: January 24, 2013, 01:31:06 PM »
KFlop can handle as many MPGs as you want - MPG functionality, as with virtually everything on KFlop other than coordinated motion, is defined *entirely* by user programming, so how many MPGs you have, and what they do, is entirely up to you.

Regards,
Ray L

So you have to be able to code to get it done?
Hood


Hood,

'Fraid so.  KFlop's greatest strength, and its greatest weakness, is its almost infinite configurability through writing C code for the DSP.  The KMotion libraries support the basic motion commands, G-code interpretation, etc.  But most "peripheral" functions - homing, limits, probing, pendants, MPGs, spindle speed control, etc. all require programming.  Most of it is quite simple, and there is a fair amount of sample code to start with, and outstanding support from Tom Kerekes, even for "newbies", but some of it can take some time.  I probably have a couple days time in my pendant/MPG code.  But, it does *exactly* what I want, and does it flawlessly.

Regards,
Ray L.

186
General Mach Discussion / Re: motion controllers working with Mach3
« on: January 24, 2013, 11:15:20 AM »
All I can find about KFlop and lathe threading, is it uses the KFlop's coordinated motion functions and can handle spindle speed fluctuations (both speed up and slow down).
I can't find anything on MPGs and Mach3, but if you were to contact Dynomotion, I'm sure they'd give you a quick answer (I've yet to see a single problem go unasnwered on their yahoo list!)

KFlop can handle as many MPGs as you want - MPG functionality, as with virtually everything on KFlop other than coordinated motion, is defined *entirely* by user programming, so how many MPGs you have, and what they do, is entirely up to you.

Regards,
Ray L

187
Steve,

"The soda can is just fore scale . . I did not make that part." - I was REALLY impressed, until I read that....  :-)

You've been busy!  All looking really good!

On the airflow control - look at automotive idle air control valves.  I'm not sure what the airflow range is, but the functionality is exactly what you need, and they're pretty cheap.  I suspect they could be modified for lower flow, if necessary.

Those are nice little solenoids you're using.  Where do you get those?  What do they cost?  I'll probably need some on the new 12-tool fixed carousel ATC I'm designing for my new machine.  All the ones I've found so far are stupid expensive.

Regards,
Ray L.

188
General Mach Discussion / Re: G-code Question
« on: January 22, 2013, 04:27:16 PM »
And....  Tom has already acknowledged this is a bug, and is hard at work fixing it....  I really do love the KFlop!  One will be going on my new machine just as soon as I finish its PDB and ATC.

Regards,
Ray L.

189
General Mach Discussion / Re: G-code Question
« on: January 22, 2013, 11:21:50 AM »
Hood,

Yes, this is something reported by a KFlop user.  KFlop seems to currently consider it ok to merge the two moves, then execute the M7 AFTER the merged move is complete, which I believe is incorrect, per the RS274 spec.  In fact, RS274 even says that if a G0-G3 occurs on the same line as an M7, the M7 MUST execute first, so it stands to reason if they are on separate lines, they should execute in the order in which they appear.  This "feature" has never caused me a problem just due to the way my code is structured, but I was just curious what was "correct" in this case.  One thing for certain - if it is "wrong", and I believe it is, it will be fixed within a very few days at most.  TomK, "Mr. KFlop", is VERY responsive when it comes to bug fixes and feature enhancements.

Regards,
Ray L.

190
General Mach Discussion / G-code Question
« on: January 21, 2013, 06:55:58 PM »
It has long been my understanding that G-code blocks should always execute in-sequence.  For example:

G0 X0
G1 X1 F10
M7
X2

This should turn on the coolant when X passes by 1.0.  However, on one machine, I see the coolant not turning on until X=2.  Is this correct or not?

Regards,
Ray L.