Printable View
I have read the docs on the Granite website, but I don't see a description of how the external brake behaves, other than during variouse fault conditions.
1) is the 24V an on/off singnal or is it analog and varies?
2) can the brake be controlled via command to the drive?
3) is the brake normally engaged (ON) whenever the axis is stationary?
This is an important issue in my application and I'd appreciate any info or experiences that anyone can share about this feature.
Thanks!
the brake on the motor is off when the drive is powered and off when it is unpowered. the sole purpose of the brake is to keep the z axis from falling if the power goes down for any reason. if you wanted to use the brake for extra holding power in a rotary axis for indexing, you would need to run it through an axillary relay circuit.
As it happens, that is exactly what I am doing. I have a 4th axis with a pneumatic disk brake. A 24V solenoid pneumatic valve actuates it and I use a relay to trigger the valve, but it requires manually inserting macros into the gcode.Quote:
Originally Posted by Montabelli
What I seek is an automatic way to engage the lock any time the motor is not moving. I was thinking maybe the 'position reached' output on the Granite drive could be used to engage the brake.
It sounds like you have the type of 4th axis that requires a brake when in position, the other style is that there is no brake and the servo hold position, these latter types are usually capable of interpolated motion with the other axis.
In your case you need to disable the drive when in position at the time the brake is applied.
IOW, you should never keep the motor engaged or active when the brake is on.
If the Granite drive has a In-Position signal which is only on when the motor is stationary, you could maybe read this signal and then in turn issue an output that turns the drive enable off, this would be OK as long as the motor remains in position however.
This may require some simple logic, either in the controller or external.
Al.
My 4th axis is somewhat unique in that it is both. This creates the interesting challenges. You can see an earlier prototype switching back and forth here (short video): Both this 4th axis prototype and the little mill are now gone (replaced by larger stuff) but you can see the 'chamelion' like characteristic from this older vid. You can follow the whole progression by watching the other videos if you are so inclined.Quote:
Originally Posted by Al_The_Man
[nomedia="http://www.youtube.com/watch?v=b2-Kdud7eiA"]YouTube- Mini Machining Center - final design 4th axis - scratch built servo powered[/nomedia]
I was using Mach3's 'swapaxis' function to use both the 'A" axis for indexing, rotary engraving and simultaneous 4 axis machining and then 'swapping' the servo drive input to the spindle axis for high speed turning, and then switching back and rehoming for indexing, hard tapping, etc. I now have a harware solution that does the same thing, so I'm not tied to Mach3. The remaining challenges are activating the spindle lock automatically (I now have to embed macros manually in the g-code), and getting a high enough step rate to spind the 4th axis over 2,000 RPM with a belt reductioon and an 1800 line encoder.
You should really disable the drive when the brake is on, just to be on the safe side.
I am not sure if the Granite device keeps track of the position when disabled.
I only use closed loop systems so it is easy to know when in posn and simply turn off the drive signal.
Al.
According to their docs, it does keep track. You can even control how aggressivle it seeks out the correct position on re-enable. I'm waiting for them to tell me if the 'position reached' is still alive when the drive is disabled.Quote:
Originally Posted by Al_The_Man
They have been very resonsive to questions so far, so that in itself is encouraging. If the 'position reached' is still active with the drive disabled, then theoretically it could be used to engage the brake and disable the drive and then release the brake and re-enable the drive once steps start flowing in again.
I would be interested in any other ideas about how to eat this particular elephant.
Hi folks,
This is the exact code from VSD-E firmware which decides "servo ready" output status (requires understanding of C code to read):
So it is combination from many status bits. When drive is disabled by user, the servo ready goes 0.Code://update SERVO_READY status
if(isStatus(STAT_RUN) && isStatus(STAT_INITIALIZED) && !isStatus(STAT_FERROR_RECOVERY) && !isStatus(STAT_HOMING) && !isSignal(SIG_HOMING_ABORTED) && !isStatus(STAT_RUN_SEQUENCE) )
setStatus(STAT_SERVO_READY);
else
clrStatus(STAT_SERVO_READY);
VSD-E brake output is off whenever drive is controlling motor (not disabled and not faulted). Brake output behavior can be altered by firmware customization if necessary (this was also discussed with simpson36 by emails). So we can modify to switch on during static position holding.
The default brake control code is very simple:
Code://update brake output
if( isStatus(STAT_FAULTSTOP) || !isStatus(STAT_ENABLED) )
setStatus(STAT_BRAKING);
else
clrStatus(STAT_BRAKING);
simpson36,
I have two questions 1) is there any concern that an automatic brake set will will be turning on and off perpetually because of short code segments in any of what you do? 2) is there any chance that the pneumatic operation would be too slow to match up with the electronics, there by causing even more problems? I have seen some pneumatic systems that were extremely variable on timing issues.
Xerxes, custom firmware is one of the solutions I am considering, and it may be the answer in the end, but right now the Granite firmware is under active development and I can forsee issues where a user upgrades the firmware using the lastest downloaded version and looses the customized lock function. In addition I do not have enough information or testing completed to construct a set or requirements for the function. If a special 'lock while holding' function was made a configurable part of the standard firmware, that would be the best solution.
Thanks for the info on how the 'servo ready' is triggered. My interest specifcally was whether the 'position reached' function remains active when the drive is 'disabled'. If it IS active, then is there a reason it could not be used to trigger an external relay to control the lock?
Montebelli, 1) yes! the 'chamelion' behavior of my 4th axis is such that an automatic setup as proposed by custom firmware would work fine for indexing but could potentially cause trouble with simultaneous axis moves as in rotary engraving or milling, where the lock should be completely 'off line'. So if some method is developed to automaticaly control the lock during indexing, it must be able to be 'turned off' for all other operations. I can do this fairly simply by adding an 'enable/disable' pin on the lock relay, but it must be triggered by something external to the drive because the drive has no way to know what kind of lock operation is needed for a particular cut.
2) Yes, latency has always been a concern (only for lock release) and I built delays into the code during developent in the early stages and then reduced the delays a little at a time to see the result. I have just completed quantifying the results and the lock release is not adding any significant folllwing error. Taking into consideration any reasobnable accelleration setting and any reasonable following error fault, the maximum negative result is only a few % and easly absorbed by normal servo operation. I can easily make the pneumatics far faster than they are now, but it looks like that will not be needed.
Al-The-Man, this project has interesting challenges because it seems that every idea has upsides and downsides. I developed the 'Super Duty' verison for heavier duty operations like holding a trunnion table. In such an applicatin, disabling the drive is a bit scary because if this was initiated with no air to the lock, the trunnion, often with weight far off center would be free to rotate. This would be like having a similar feature on the Z axis. Imagine the mill head in a free fall if air pressure is lost during the lock event while the drive was diabled.
Most mechanisms like this are fail-safe, IOW it requires air, power etc to REMOVE a lock or brake.Quote:
Originally Posted by simpson36
This is the principle usually applied to servo motor brakes, power is required to take the brake OFF.
If the mechanism is the reverse, e.g. the air has to be on to brake, then usually a detection device is used such as a pressure switch has to be on as feedback to the controller to continue.
Z axis Hyd or pneumatic shot bolts are usually fail safe also.
Al.