Hello Guest it is April 28, 2024, 06:22:14 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

251
General Mach Discussion / Re: What buttons on your control?
« on: December 04, 2012, 05:52:23 PM »
John,

No, I don't.  What I did was bought a VistaCNC P2 pendant (they don't seem to make this one any more, but it's almost identical to the P1A).  I then opened it up, re-wired it to use RS232 instead of USB, and completely re-wrote the firmware to suit my needs.  It works flawlessly, and I can very easily modify it to make it do whatever I want it to.  I'd be happy to post the modified firmware if you want to go that route.

Regards,
Ray L.

252
General Mach Discussion / Re: What buttons on your control?
« on: December 04, 2012, 12:25:37 PM »
I have a custom pendant that does most everything I need:

EStop
Run, FeedHold, Stop
Jogging all axes (Step/Velocity and Continuous modes)
Setting jog increment or continuous jog speed
Mist/Flood Coolant, Spindle on/off
Homing all axes
Probing all axes in both directions to set fixture offsets
Grab/Release PDB
Cycle toolchanger
ToolComp on/off

This is all shoe-horned into an off-the-shelf pendant with an MPG, EStop switch, two six-position rotary switches, and a single push-button switch.

I also have a dedicated control panel next to the computer display which duplicates many/most of these controls.

For actual on-machine controls, I would stick with those you really need when doing setup, plus, of course, E-Stop.

Regards,
Ray L.

253
You've got it basically correct.  Current limiting in the Gecko determines torque.  I limit torque during tightening, and run full torque for loosening.  I loosen 1-1/4 turns, and on tightening I go 1-1/2 turns, stop, the go an additional 1/4 turn.  In most cases, the first move will stall near the end, and the second is just ensuring full tightening torque is reached reliably.

There is no reason this would not work just fine with a G203V.  When the drawbar stops, the Gecko will limit current, and should not fault.  It will only fault if the motor outputs are shorted.

Yes, the air cylinders provide enough down-force to pop the collet free of the spindle.  Wouldn't be a workable PDB if it didn't.  There is no "hammering" motion, it is simply about 300# of down-force.

Regards,
Ray L.

254
Sure, I have a membership at the zone, but I have to disagree, I think the design I propose has quite a few advantages.

Namely-
springs can be altered.
springs can be of various sizes.
Air cyl can be used instead of impact or gearmotor.
Sensors not needed. Only one hard stop for downward travel.
table mounted tools, no swinging arm, carosel etc...
no dependance upon the air ratchet type PDB engaging correctly.
No need to have a gearmotor with its drive, switches sensors etc, not to mention making sure it engages correctly before turning.

 
Pretty much all of those, with the exception of "springs can be of various sizes" can be accomplished with a more conventional design, and you won't have to deal with the VERY considerable issue of keeping a rotating spring stack and housing well enough centered and balanced as to not be a serious safety hazard.  Keep in mind that "extension" will rise above the end of the spindle by at LEAST the amount of quill travel, and it will, necessarily, be rather large and heavy, making perfect centering and perfect balance an absolute necessity.  MANY power drawbars use air cylinders, hydraulic cylinders, air-over-hydraulic systems, linear actuators or even motors (see mine, earlier in this thread).  Keep in mind, too, that if you're talking R8 or TTS, you need a BIG air cylinder - they are typically done with about a 4" diameter triple-stack cylinder to get sufficient force (required drawbar force for TTS is about 2500#, unless you're running a fractional horsepower machine).  Sensors are not needed for any of these.  And, even if you feel they are, what's the problem with using $3 micro switch or inductive proximity sensor?  A table-mounted wine rack tool rack can be made to work with any of these.  There are several examples on CNCZone.  Making sure a rotating PDB engages before starting rotation is also not necessary - I don't bother to do that on mine, and it works perfectly.  If it does engage on the initial downward movement, it will as soon as the socket and drawbar rotate into the proper position, so it's self-engaging.  In fact, I don't think I've ever seen a power drawbar that makes any effort to ensure engagement before rotation starts.  You're creating solutions in search of problems.

Regards,
Ray L.

255
You're kind of re-inventing the wheel.  Power drawbars for every kind of toolholder imaginable have been done to death, and what you describe would be less than ideal in a number of important areas.  I'd suggest you wander over the CNCZone, and see what other people have done for power drawbars and toolchangers.  There's little new under the sun....

Regards,
Ray L.

256
HimyKabibble-

If I get you correctly, You are saying that if you have the wine rack style tool holder on the table, and you use the quill for descending to pick up the tools, and then have the knee do the actual z positioning?

or are you saying that the knee is only for z height offsets. and that the quill (once correct offset is established with the Knee) does all of the Z positioning?

Seems to me that one of the biggest shortcomings on the BP as a cnc mill is that the Z travel is not much. After doing my conversion, I think I get a total of 4.5"

When using the Knee for Z offsetting, do you have it set up to unlock the knee, drive up or down and then relock? is the repeatability/accuracy suficcient? I always thought of the knee as a gross positioning device, and never thought that once unlocked, moved and relocked that the XY position would be repeated better than .002"-.005"

A few years back I thought that if the air cyl had to travel with the quill, that this could be effected by having the CNC Z axis on a (converted) BP also carry some sort of outrigger setup on both sides that extended up and then over the top of the head. I also theorized that a clamping assembley could hold the last .750" of the bottom of the quill and this could extend out and then have risers that would extend up and then back over. this would create an external "frame" like structure directly tied to quill movement and could carry the air cyllinder. Thus tool changes coiuld be effected at any Z height.

Another thought I have had was to have a linear tool rack that travels in X just in front of and mounted to the sliding head dovetail on a BP. it could move back and forth to set locations in a 4th or 5th axis in mach3 and would have trays in the assembley that would slide out via air cyl extension to position under the quill in Y. thus X would be moved to position by an additional axis, Y would be by air cyl pushout and retract in Y would be via Spring pullback.

Z travel would still be extremely limited because it would take 2.5/3 inches of its travel to raise up and have the new tool position under it for capture. I suppose the tools could be pushed both out (away from the mill body) AND up, by air cyllinder thus eliminating the Z travel of the quill being used to change tools. The entire Z quill travel could then be used to do machining ops.

No, you've got it backwards.  You use the knee for applying tool length offsets, and inserting and removing tools in the spindle from the wine rack.  You use the quill for all machining.  Unless you have single machining operations that require more than 4.5" of quill travel (I never have!), this works fine.  This is how I operate my knee mill.  Position accuracy should not be an issue if your knee is properly adjusted, and locking it should be completely unnecessary. 

Regards,
Ray L.

257
"Real" machines don't have quills - the whole head moves up and down.  If you have a knee mill, you move the knee up and down to swap tools from a table-mounted wine rack, and you can define that tools can only be released at the top of the quill travel.  You'll want the knee automated anyway, for applying tool length offsets.  A tool changer without support for tool length offsets would be pretty useless.  Making a power drawbar that would work with the quill at anything but the full-up position would be a living nightmare.  Doing it on a BP would be darned near impossible, because there is so little space inside the pulleys where it would have to fit.  Besides, I really can't see any advantage to making it work that way.  Making one that works in the full-up position is quite simple.  With BT/ISO tapers, it's not a problem applying the drawbar load to the spindle bearings, as the load is relatively small (about #1300 pounds max for 30-taper), and the bearings can easily handle it.  But, making a drawbar that does not apply any load to the bearings is also quite easy.

Regards,
Ray L.

258
General Mach Discussion / Re: Will Mach 3 ever be used on a tablet
« on: December 02, 2012, 11:03:52 AM »
Mach3 v4 will run under Windows, OS/X and Linux, so, presumably, could also easily run under Chrome.  So, a tablet is not impossible. The current Mach3 will never run on a tablet.

Regards,
Ray L.

259
Finally had time to make a new Y/Z telescoping way cover (you can see it in the video) that clears the ATC, and all is installed and working perefectly:

http://www.youtube.com/watch?v=54s0aoAT37o

I've also got the new serial network working.  It's going to significantly reduce the amount of wiring on my machine, and especially reduce the number of connections back to the E-box.

All that remains on the ATC is installing the "skirt" and door, making a cover for the "works" on top of the carousel, and cleaning up the wireing and plumbing.  Functionally, it's already working 100%.

Regards,
Ray L.

260
Progress on the ATC has, once again, been interrupted by higher priority work, but it is nearing completion.  I've just finished getting the "sensors" working, so all that's left is getting the door mechanism going, putting on the "skirt", and doing some minor clean-up.  The mechanism is working flawlessly.  In fact, it's been running continuous toolchanges since early this AM - nearing 1000 just today.  So far, no problems whatsoever.  And, now that the sensors are in place, I believe it will correctly detect any problems, and halt operation.  I've tried everything I could think of to make it fail, and it has correctly detected every failure I've thrown at it, and simply stopped what it was doing, until I manually cleared the error condition.

On a related note, the functionality of my machine has been expanding for years, and has gotten to the point that the wiring around the KFlop has become something of a rats nest, and I'm starting to run short on I/Os. A friend and I started designing a KFlop-specific breakout board, and in the process of defining what functionality to include on it, I came up with what I think is a great idea to greatly reduce the overall amount of wiring, and the amount of required buffering of signals.

The signals connecting to the KFlop basically fall into a couple of very broad categories. First is the special function and time-critical signals, like axis
drive outputs, Home/Limit/Probe/E-Stop inputs, and a very few others, which MUST be connected directly to the KFlop. These make up about 30-40% of the total signal count. The remainder are not at all time-critical, nor do they really NEED to connect directly to the KFlop. This group includes spindle and coolant controls, power drawbar and tool-changer controls, etc.

A while back, I bought a VistaCNC USB pendant, which I proceeded to rip apart, completely re-writing the firmware for the embedded PIC processor, and converting it from USB to RS232, so it could communicate directly with the KFlop. The code in both the pendant and the KFlop is dead-simple, and the pendant has worked absolutely flawlessly since the day I first put it into service months ago. It uses a very simple purpose-built serial protocol. My
new hair-brained idea is to expand that protocol to allow additional external processors to be connected to that same RS232 link, by either a daisy-chained or star connection, so that all non-critical signals can be moved completely off the KFlop to any number of external processors, each of which can then be located near the device it controls, connected by only a serial link, rather than a mass of wires. Each processor will be separately addressed, so it will accept messages targeted to it, and ignore all others. All processors will be able to send messages to any or all other processors, including the KFlop. Each will be able to accept commands from the KFlop, or other processors, and to send status message (e.g. - current spindle speed) back to the KFlop.

I will re-configure my system so that there will be one processor in the pendant (it's there now, and will just require a few minor tweaks to support the new protocol), another in the E-box for several basic machine functions (spindle controls, coolant controls, etc.), one for the power drawbar and toolchanger, and one for the control panel (this is, essentially the pendant from hell - a console with MPG, and a bunch of dedicated-function buttons...), so I can operate the machine without a mouse.

So, for example, if the user want to release the drawbar, the KFlop will send a message to the PDB/ATC processor telling it to release the drawbar. Once the operation is complete, the PDB/ATC processor will send a message back to the KFlop either confirming the operation completed successfully, or return an error code, indicating why it failed. Similarly, to turn on the spindle, the KFlop will send a message to the spindle processor, telling it what speed to set the spindle to. The spindle processor will set the spindle PWM, turn on the spindle, and send periodic spindle speed updates until the spindle is turned off.

I plan to use off-the-shelf Arduino processor boards, because they're dirt cheap (starting at about $10), highly functional, and available in a broad range of capabilities, with a wide range of plug-in I/O expansion boards. But, ANY processor could be used, as long as it supports RS232. Since each will be
controlling only "local" devices, there is little need to any extra buffering or isolation, further simplifying the wiring. This will reduce the current mass of
cables going from the E-box to the machine down to just the motor/home/limit/probe wiring, and a single RS232 cable, daisy-chained to the
processor boards on the machine.

Regards,
Ray L.