Messages

811

Show"N"Tell ( Your Machines) / Re: Success! Mini Machining Center under Mach3 control - Video link

« on: May 10, 2010, 04:30:41 PM »

Here is the latest video of the 4th axis. This one is by request also. I've had quite a number of queries about form tools ever since I mentioned it a while back. This vid demonstrates a form tool that I finally got time to make for cutting curvilinear form teeth. Also shown is the hideously painfull way I was making them before the form tool. The contrast is  . . . well, just take a peek.
http://www.youtube.com/watch?v=ViN4t4YI_T4

Thanks for the suggestions and comments on the lock operation. It is pretty much sorted out now. For Mach3, a couple of options are available already. It is just a matter of seeing how 'automatic' I can make the operation for the purpose of making the dual indexer/lathe capability easily implemented in a variety of setups, not just Mach. While I am waiting for the modifications to the Dugong, I am going to try other drives that already have the features I need to automate the lock function.

Also I am thinking now about making a trunnion table. That was the reason for the 'Super Duty' version of the 4th axis, so I may as well have one for myself. I do have applications for it. I would love to hear from people who are using or would like to be using a trunnion table. What's good What's bad. What would you like to see?

I was looking at Tormach's 'Duality Lathe' approach. Anybody have comments on that setup? Tormach has the lathe tools in a fixture that appears to be clamped to the spindle. My spindle is servo powered and has a spindle lock like the 4th axis. It occurs to me that a relatively simple fixture clamped to the spindle could hold a bunch of different tools in a carousel arrangement.

812

Show"N"Tell ( Your Machines) / Re: Success! Mini Machining Center under Mach3 control - Video link

« on: May 01, 2010, 01:19:02 PM »

I don't think using sleep in a VBscript contributes to following error. I don't know that for a fact, but sleeps are inserted to put Mach on hold while functions execute, otherwise it can get ahead of itself.  Another example is that you have to put G4 delays in the G-code or Mach won't update the variable monitor.

Inserting sleeps and 'while is moving' and so on are execution holds that have nothing to do specifically with the 4th axis or the lock. Those are in there because Mach needs them. Maybe a scripting Guru will chime here and quantify the time period of sleep(10), but it ain't much . .  few milliseconds I would guess.

I hear you on the fault issue, I had some Gecko 320s  . .  briefly. The drive I am using is a Dugong which has a settable following error up to the 10s of thousands. These drives are tractors. Not too fancy, but just big brutes. I'm using a NEMA34 DC brush motor with a 40A max draw and the Dugong just slaps it around. A momentary error of 200 on a 7200CPR encoder is not much considering the test parameters. Swinging a heavy chuck with stupidly fast acceleration and instant direction changes and long moves . . actually I had the thing pushed to a limit just below where the servo motor would go ballistic and break into violent oscillations. i.e. the test was intentionally not real world. The test settings were quite in excess of anything you would use in normal machining operation.  

813

Show"N"Tell ( Your Machines) / Re: Success! Mini Machining Center under Mach3 control - Video link

« on: May 01, 2010, 02:19:26 AM »

Is that running with the macro to lock/unlock ? Using the macro it is a sure thing no problem
TO be seamless you have to eliminate the macro right?

There will always be error on a servo, so the goal was to see how much error was added by the lock. The test program contains lock and unlock macros, with no g-code commands between the unlock macro and the 'A' axis  move. The release Macro and a G0 'A' move back to back is the worst case scenario. The same program was run with and without air to the lock. Without air, the lock is inoperative and cannot add following error due to release latency.

If by 'seamless' you mean transparent to the CNC control software (MACH in this case), then yes, the Macro has to go away.

There are three basic challenges to making the 4th axis work as I want.

1) a way to run the A axis continuously.

2) operation of the lock function

3) ability to run a high res encoder at high RPM.

For use with Mach3, all of these have been solved. (1: swapaxis board  2: embedded macros  3: step mulitplier, smoothstepper, kflop)

For 'universal' use with other CNC setups, only the first is solved and I am working on the other two. Solving the second challenge for 'universal' use (my current focus) will also benefit Mach by eliminating the need for macros embedded in the G-code by manual editing or modified post proc.

814

Show"N"Tell ( Your Machines) / Re: Success! Mini Machining Center under Mach3 control - Video link

« on: April 30, 2010, 06:14:31 PM »

BUT you will have to be able to turn the function off IF you want to do interpolated 3d work.
I think most users are going to want it to do both functions once they start using the 4th(;-) it is like Crack once you get the 4th YA CAN"T LIVE WITHOUT IT. (;-)

Yes on all counts.

I did some testing and have some quantified results. Settings:
Step per degree: 25.6
Step multiplier:    5x
Velocity:            82k
Acceleration:     14k

The test program did nothing but G0 moves with lock on before and off after - G0 move is next line in code after lock release macro. Macro has sleep(10) after DeActivate. No programmed G-code delays. Heaviest chuck I have (a customer's special wood holding chuck). The machine was literally slamming around in a way that it would never experience in normal use.

Encoder 1800line (7200CPR)

Absolute MAX following error on G0 moves ranging from 30 to 180 degrees each direction:
Without lock:       151 to 189
With lock @50psi  171 to 203

Notes: Above are MAX and occur only once during the run. Most times error is under 10 between moves with or without the lock.
With acceleration set to something reasonable, max error is in the 50's with most moves generating about 5. Negligible difference lock on or off.
Looks like custom firmware is not going to be needed.

815

Show"N"Tell ( Your Machines) / Re: Success! Mini Machining Center under Mach3 control - Video link

« on: April 30, 2010, 02:08:23 AM »

By the way good job on the 4th axis setup. Have you looked at the system that TORMACH uses with their 4th axis indexer/lathe set?

Is this the one where they have an entire small lathe that is mounted on the mill table?

816

Show"N"Tell ( Your Machines) / Re: Success! Mini Machining Center under Mach3 control - Video link

« on: April 30, 2010, 02:06:45 AM »

OF course IF you used a special buffered input servo drive THEN it may work on simple A axis "non interpolated" moves as the drive MIGHT be able to buffer the data stream enough to allow the brake time to release before it errors on position.

It had not occurred to me that you were trying to do this on a linear axis! That would be a LOT more crucial since you would be cutting metal during the period. It is impressive that you could get that to work at all. My application is strictly 4th axis and within that, only non simultaneous A axis rotations, with no cutting going on during the period. Following error can be very high allowing, as Bob said, the servo to fall behind and catch up after the Lock released. This would have no practical effect on the machining phases because the period in question (possible fall behind) would strictly be at the beginning of positioning moves between cuts. I have no intention to have spindle locking active during simultaneous multi axis cutting. If fact, I specifically designed a double reduction belt drive for that purpose. 

It would be necessary for any servo drive to buffer the input stream to some degree in order to track following error, I would imagine. However, I can see where a fixed small following error that some drives have together with a high res encoder would leave precious little time for releasing a mechanical lock.

BUT THEN you have created a unique realtime mini drive system that the average user does not have. (;-)

I am going to try and avoid this if possible, but I am only looking at drives that have field flashable firmware. If there is no other alternative, I could provide a custom firmware for certain drives, if not the entire drive. I am already be providing the swapaxis hardware, TTL splitter, and solid state relay.

817

Show"N"Tell ( Your Machines) / Re: Success! Mini Machining Center under Mach3 control - Video link

« on: April 29, 2010, 03:45:37 PM »

Here's a thought, probably not fruitful...
First, you need to know precisely how long it takes the brake to lock/unlock. 
Second, what's the pulse rate and how far does it make your 4th travel during that lock/unlock time.
Remember, your axis must also accelerate and decelerate, so it will be moving slower than the rapids rate when it starts or stops.

The only part of this that is not 100% accurate is where you say it may not be fruitfull. You are exactly on the mark.

Now the probably useless thought:
Given that information, can you just let the servo drive catch up?  It's a function of the pulses during the lock/unlock not exceeding the follow error and causing a servo fault.  Obviously a drive that allows you to adjust that would be helpful.
Depending on your feedrates, it might be workable.  It surely would be simple if it is workable. 

This is my conclusion as well. By both theory and observation. You give me another idea of how to quantify. The Dugong drive has a real time Encoder DRO in its tuning software which can be active while the drive is ruining . .  a very neat feature that I have used many times. I could simply monitor the error during program execution. I don't know why I did not think of that  . . .  so . .  I'll just blame Dan  . . . Dan, this is all your fault . . 

PS As you have surmised, lock is probably ok, its unlock that is touchy.

Batting 1000

818

Show"N"Tell ( Your Machines) / Re: Success! Mini Machining Center under Mach3 control - Video link

« on: April 29, 2010, 03:35:16 PM »

Other than the axis attempting to move before the lock can release, I don't see a fatal flaw in the process, but I would definitely want to know if anyone else does.

Exactly! This is the main problem and especially because of the requirement to make it "transparent"  to Mach. You got to have something in Mach that would trigger just before it starts sending pulses to the 4th axis. Once it's started sending pulses to the drive it's too late to try and do something on the hardware level to unlock the brake. That is unless may be if you have a servo with an incorporated brake and some clever drive that can take care of it all.

You do not have to do anything in Mach. I already know this can be done with custom firmware from at least two different vendors, so there is no need to discuss whether it is doable at all, only what approache might be best and why. This is just a dialogue and I am interested in what others have tried and what their issue were.

To addresss your comment specifically, if in theory the lock could be released instantaneously with zero latency when the very first new step crossed the drive's input terminal, then you would have to agree that everything would work just peachy, yes?

So then it is actually only a matter of timing. A servo motor driving a 4th axis with a workpiece does not instantaneously accellerate even to a low G1 speed. If for example, the actual accelleration of the axis is '*********' and we assume for the sake of argument a zero latency for the electrons flying around within the drive, then we only need consider the time to move the physical plunger in the pneumatic solenoid valve and the time it takes for few CCs of air to move thru about 5" or 1/8" tube to atmosphere. I have not measured either of these, nor do I have equipment to do so,  . .  BUT . .  it IS working now using macro commands embedded in the G-code. I started with delays in the macros and then also have used G4 delays. I have whittled those now down to nearly zero and the lock seems to be working fine. There remains a sleep of only 10 in the macro, but that is there to wait on MACH to do something, not the lock mechanism

Interestingly, it has occurred tome as I am typing that I have a video of the entire cycle which I could simply count the number of frames needed and get at least a rough idea of the latency. Look here and observe the red indicator light which signals that the lock is engaged.

http://www.youtube.com/watch?v=B8l6lH4ydd4

819

General Mach Discussion / Re: Rotary Axis Blues

« on: April 29, 2010, 02:36:24 PM »

I think most people who have tried this with Mach have had one problem or another at some point.

Perhaps you could elaborate on what you do know.

What generated the g-code. Why do you say it seems that it was incorrect?

820

Show"N"Tell ( Your Machines) / Re: Success! Mini Machining Center under Mach3 control - Video link

« on: April 29, 2010, 02:29:26 PM »

Doing it at the servo drive level won't work either, Tried that as well using the servo brake

Anything you see at the drive level is already BEHIND the time curve of the buffered data AND mach has no idea what is happening at the servo level movement wise so it cannot STOP the data flow out of the port.

My goal it so make the function transparent to Mach so what mach knows or doe not know would be irrelevant. What is or is not in a buffer would also not have any practical effect.

By way of example, a hypothetical scenario would go like this:

Premise:
4th axis is in 'indexer' mode connected to the A axis drive. G-code commanded position: G1 A425 The servo drive only sees A axis steps and no other.

1)Upon reaching azimuth 425, the drive reports 'position reached'
2)That signal (+5V) is used to trigger the lock ON   (** and perhaps simultaneously disable the drive)
3)new A axis steps come into the drive.
4) within 1ms (I am told) the 'position reached' line goes low and the HV to the motor come on (**IF the drive is enabled)
5) that signal (0V) released the lock (** and perhaps enables the drive)
6) Axis moves to new azimuth and the process repeats.

Other than the axis attempting to move before the lock can release, I don't see a fatal flaw in the process, but I would definitely want to know if anyone else does.


Can you elaborate more on what it is you tried at the servo level?