Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: tcstar on June 03, 2010, 03:37:10 AM
-
I am a new user of Mach3
now I got a problem
if I want to release on when z axis moving
how can I do?
I thought I can check the "togo" of Z
if the var is not 0
release the brake
else brake up.
the problem is how can I know the "togo" of Z
and if I put this function in macropump, and i hope to add a timer to delay the Z axis move
how to do?
thx a lot..
-
Normally the brake would either be controlled internally by your servo drive or if thats not possible you would use an enable signal. In other words when the axis is enabled the brake will be powered and released. If the axis faults or is switched off then the brake will be applied as it loses its signal from the enable.
Hood
-
I told my customer like what u talk,
but he thought his head is too heavy and hope the brake can help the motor to hold the position..
-
I told my customer like what u talk,
but he thought his head is too heavy and hope the brake can help the motor to hold the position..
That is no use, he either needs to fit a counter weight or get a bigger motor.
Hood
-
I still need one way to realize the software function, to solve the problem or to prove his solution fail
Can anyone tell me the way to get the "togo" var of Z-Axis?
-
I still need one way to realize the software function, to solve the problem or to prove his solution fail
Can anyone tell me the way to get the "togo" var of Z-Axis?
I am wokring on a similar project, but for the A axis. My goal however, is to make the operation tansparent to MACH.
My current thinking is to use a 'position reached' output on a servo drive to activate a brake. That seems promising, but I have not had a chance to develop the idea yet. I am busy with other stuff at the moment, so it may be a while till I revisit this project.
-
For a rotary axis I can see the point but if this is as in the OP's case for a Z axis then I dont see the point. If the motor is not good enough to hold the axis in position when stationary then it will be no use when it is moving and cutting.
Just my opinion of course.
Hood
-
I found GetDRO(16002) seem to be use for get "togo" distance
but it didn't work when trying...
does anyone know why?
-
I agree with Hood, normally when an axis is in position a brake should not be applied on a servo when the motor is active, the drive has to be shut off or disabled while the brake is on, this implies that when the drive is re-enabled, the true position is re-established otherwise a jump can occur if the Z has moved at all
On a Z axis a counterbalance system should be employed.
A rotary table is often the exception, but the motor still has to be de-activated.
-
I agree that a counterbalance is a better solution for a typical Z axis, not only to reduce stress on the motor, but to eliminate backlash . . a benefit unique to the Z axis.
On the other hand, I disagree that a drive motor 'must' be deactivated prior to an axis being locked in all cases. I have been doing some research into this question and I find that there are many different applications and each has it's own set of variables to consider. I am wokring with a servo drive that already has a separate set of parameters that are automatically engaged whenever the motor is not moving, so manually disabling the motor *might* be superfluous (too early to tell just yet). I know of several stepper motor drives that automatically reduce power when the motor is not moving, so locking an axis in that situation would do nothing but prevent stress on the motors and potentially prevent lost steps in the case of an extreme force such as occurs during tool chatter while the motor is at reduced power.
Then there is the example of a rotary tool holder where it is evident that the motor is used only for positioning and a positive mechanical lock takes the cutting forces.
Axis locking is an interesting elephant, to be sure.
-
A stepper is a different animal, I was referring to a servo, if a servo that has a transconductance amplifier i.e. torque or current mode of operation, and the motor is clamped and left active, the current will climb in order to attempt to position the motor within the specified following error if any occurs.
You cannot guarantee that positioning a servo to a certain position and then braking it that there will not be any servo error occur at any point.
I personally would not want to chance it and have never seen any servo system that operates under these constraints.
-
I ever use the brake on servo motor system when the servo is still clamp, but i decrease the gain of PID control first....
OK..my point is using the brake to help my stepper holding the position....any good idea?
and why GetDRO(16002) always return "0"??
-
. . . and the motor is clamped and left active, the current will climb in order to attempt to position the motor within the specified following error if any occurs.
This is a function of the servo drive, and as I pointed out, some drives have the ability to automatically engage limits during the condition you describe. Some even allow you to set the range in encoder counts within which this limit is applied.
You cannot guarantee that positioning a servo to a certain position and then braking it that there will not be any servo error occur at any point.
Actually, you can. Again it depends on the servo drive you are using.
I understand the thought process that ends in "do not restrain an active servo motor", but while this advice was valid, I am finding that it is no longer universally applicable. An analogy would be the advice to 'pump your brakes when you are driving on ice' which was of course valid and taught in any driving class . . . until anti-lock brakes came along. I discover that there are some clever people out there designing servo drives that have actually though about this topic and built some interesting features into the drives. Not all drives mind you, but some. There are still a lot of cars on the road without anti lock brakes also, so 'pump the brakes' is still good advice, but not in all cases . . since pumping anti lock brakes is a decidedly bad idea.
[/quote]
-
I ever use the brake on servo motor system when the servo is still clamp, but i decrease the gain of PID control first....
OK..my point is using the brake to help my stepper holding the position....any good idea?
and why GetDRO(16002) always return "0"??
From the department of redundancy department:
If you are going to go into MACH to get variables, then you have already coupled your process specifically to MACH, so why not just write a macro to engage the brake and add that to the G-code between moves (with delays if needed). That is how I implemented the 4th axis spindle lock initially and it worked fine.
My quest for an autonomous function stems only from the goal to make the operation transparent to MACH, or more broadly, to any CNC controller.
Note that I am simply commenting on your question, not endorsing any particular idea.
-
From the department of redundancy department:
If you are going to go into MACH to get variables, then you have already coupled your process specifically to MACH, so why not just write a macro to engage the brake and add that to the G-code between moves (with delays if needed). That is how I implemented the 4th axis spindle lock initially and it worked fine.
My quest for an autonomous function stems only from the goal to make the operation transparent to MACH, or more broadly, to any CNC controller.
Note that I am simply commenting on your question, not endorsing any particular idea.
the part that I ever use brake on servo motor system is reply the position error for braking and servo motor active, my solution is reduce the PID so that system can hold by motor and brake together...
of course I can put M code for release brake in my process, but my stepper will lose pulse, that is why I want to know if there is a way to auto release the brake.
-
the part that I ever use brake on servo motor system is reply the position error for braking and servo motor active, my solution is reduce the PID so that system can hold by motor and brake together...
of course I can put M code for release brake in my process, but my stepper will lose pulse, that is why I want to know if there is a way to auto release the brake.
I'm afraid I don't understand what you are saying here. Also it seems you are using the terms 'servo motor' and 'stepper' interchangeably, which is not helpful.
-
I'm afraid I don't understand what you are saying here. Also it seems you are using the terms 'servo motor' and 'stepper' interchangeably, which is not helpful.
forget the servo....
my problem is using step and hope system can auto release before z moving and lock when z stop....
z-axis using stepper..
-
forget the servo....
my problem is using step and hope system can auto release before z moving and lock when z stop....
z-axis using stepper..
In this case, have nothing new to add to my previous comments. I was not aware that steppers had electronic brakes . . . . live and learn.
-
, my solution is reduce the PID so that system can hold by motor and brake together...
PID loop with a stepper??
-
O K here we go again(;-)
YOU "could" monitor the Z axis velocity and
IF Zvel =zero then apply output signal to apply brake
AND
IF Zvel <> zero then turn off output to release brake
BUT you run into the latency problem with using a buffered system. The Z moves are already stacked into the buffer ready to go AND when the signal comes to run there is NOTHING in machs design that will allow the buffer to hold UNTIL the brake is releases fully before the Z can safely move without a loss of steps do to the drag of the brake untill it has fully released.
EVEN IF you had an intelligent drive that could do the function you could run into an accuracy problem as MACH is assuming that ALL drive can react very closely the SAME. Testing has shown that 1 slow reacting drive out of 3 can cause a mispositional error . Mach has NO way of knowing the timeing points of the drives it just assumes ALL the moves have been made as a coordinated move. It would depend on the resolution and amount of drive dwell as to HOW MUCH error would be involved
With "any" form of monitoring the Gcode pulses to active or deactivate BY the time it "sees" the movement it is TOO LATE to release the brake.
In the normal world brakes are used to HOLD the axis when it is NOT active/enabled. It is UP to the motor to HOLD the axis in position when it is active/enabled. Mostly to HOLD the position when the machine is OFF and to Catch the axis in the event of a power failure and loss of holding force.
IF the axis cannot hold itself you have 2 options mentioned above. Increase the motor to the proper size OR counterweight it to require LESS holding force.
Hope that helps
-
BR549; just to comment on your statement, I also dislike the idea of monitoring MACH for the purpose of controlling a lock, and for the reasons you cited.
However, I did fairly extensive testing of the servo error induced by using a Macro embedded in g-code and most of the time there was no increase. In order to get even a measurable increase in following error (obviously we are talking servo here), the acceleration had to be set up to a rather ridiculous degree which would not be used in 'real life', so by any measure, the additional following error introduced by the embedded macro method was zero in actual practice. I posted the results somewhere in this forum.
The reason I believe there was no significant error introduced in *my* case, was the combination of two factors. 1) Mach was automatically prevented from starting the next coordinated move until the M code was processed and 2) the total amount of time required to release the disk brake either occurred within the time it took mach to start execution of the subsequent move . . -or- . . . . the time to release the brake occurred somewhere within the early part of the acceleration and therefor had a negligible effect.
In a 'transparent' arrangement, the drive itself (at least the one I am playing with) changes the pin state within in a few milliseconds of new steps coming in and the instant the air valve is closed, the disk brake begins to release as the air pressure bleeds out of the cylinder. I do not have equipment to quantify this effect, but it stands to reason that whatever residual drag the lock may momentarily impart would be handled no differently by the drive than any other variable force. In practical terms the rapidly diminishing drag that might be present from the brake at the start of a move would not be different than the additional drag imposed by a heavier workpiece. These types of load are automatically accommodated by the PID scheme utilized by the servo drive.
-
(;-) Where you have a built in wait state then that is not really a problem. BUT when you are trying to run the gcode transparently there is no way to avoid the time lag of the mechanism in relation to the flow of moves coming out of the buffer.
Try running your setup without the wait states, I bet you will randomly trip from positional errors with a servo OR miss steps from a stepper
The only way I have seen it done without problem was from a realtime system that incorperated the I/O sensing into the motion data control point so the movements could NOT occur until conditions were met.
-
Try running your setup without the wait states, I bet you will randomly trip from positional errors with a servo OR miss steps from a stepper
There are no wait states other than a sleep(10) in the macro that is there to make MACH execute reliably. 'Hard' delays seem to be needed in many cases or MACH gets ahead of itself. For example, Mach does not update the var monitor reliably without a G4 in the code where the update should occur. This is an anomaly in the software that has nothing to do with an axis lock or any other specific application.
In my testing, I was watching DROs that show both real time following error and record the max following error, so there is no need to speculate on how close it was to faulting. Theorizing is only meaningful prior to quantification. Why bet on a race that is already run. ;)
-
(;-) That was not theory, but the results from testing.
The sleep(100) is a wait state. running in VB/Gcode code IS a wait state as well. Running directly from the buffer there are NO wait states.
Let me know how it goes when you go LIVE with the tranparent version.
-
Both the swapaxis function and the spindle lock function are already transparent to Mach.
For those unable to accomplish a task, it is comforting to believe it impossible.
http://www.ucsofa.com/famousquotes.htm