Hello Guest it is June 16, 2019, 07:24:50 AM

Author Topic: THC Settings in Mach  (Read 20703 times)

0 Members and 1 Guest are viewing this topic.

Offline BR549

*
  •  6,871 6,871
    • View Profile
Re: THC Settings in Mach
« Reply #10 on: September 25, 2011, 03:13:00 PM »
OK lets think WAY outside the box for a minute.

A simple servo drive IF you do not give it any input to move and you slightly rotate the shaft WILL return back to the position it was at(Up to the fault point). WHen it sees the encoder move it sends the move signal to the Motor to move back in the opposite direction to the setpoint. It knows where it was and how to get back there QUICKLY.

SO could we do the same thing with the THCfunction???   The linear encoder hooks to the drive as normal and the motor outputs go to a set of relays to run the THCup(forward)  and THCdown( reverse) . AS it will never get an input to move the drive it should try to auto correct the error it sees. We just tell it to move backwards to correct the height change.

Remember it is NOT like we are moving INCHES at a time just a few thousandths at a time???

Just a note we are running the THC% at 50%(;-) It does move fast.

??????  , (;-) TP



Re: THC Settings in Mach
« Reply #11 on: September 25, 2011, 07:24:06 PM »
As far as I can tell, the 2 big problems with the THC functions are overshooting due to the limited control of the axis (up/down) and speed due to the lack of controlled acceleration.  While the THC functions may work for me, the system will likely either be too limited on on my overall feedrate or will have excessive jitter on the Z.  I may play with this anyways since the interface is so simple to implement.

As far as I can tell, in order to get a quick and robust system, I'm going to need to implement a system that uses PID to compensate for overshoot.  Also, some means of controlling the acceleration would avoid problems with the mechanical side being able to keep up.

So... some possible options:

1) Attempt a rudimentary PID loop tuned to my Z axis to avoid over-shoot.  Given the realtime nature of Mach and the AVR, I should be able to select a duration of up/down that helps with over shoot.  If the timing is mostly accurate, duration on along with feedrate = distance travelled.  This still doesn't solve my acceleration problem.  It's simple to build but difficult to tune.  I'd have to setup a variety of known height changes and tune the system.

2) Close the loop within Mach.  Send real-time encoder outputs to Mach and build a plugin or brain in order to process the data and feedback.  I understand that Brian has built a THC plugin that has a PID.  I'm not sure how he's controlling the Z though.  He could just be sending Up/Down commands.  I'd love to get the source code for his THC plugin.  I'll ask him if he can make it available.  I need to find out if there is some way to control Z axis from a plugin/brain that will use the acceleration curves and allow me to adjust feedrate as required.

3) Close the loop outside of Mach.  Implement my own height control system.  Theoretically, I could use the same mechanical hardware and share the step/dir signal between the lpt port and the AVR.  Also, with ModBus, I could potentially send data to and from Mach in order to make the whole process somewhat seemless.

Any thoughts will be greatly appreciated.
Brett

Offline BR549

*
  •  6,871 6,871
    • View Profile
Re: THC Settings in Mach
« Reply #12 on: September 25, 2011, 10:47:28 PM »
WELL you may need to know that MACH is a buffered system. Mach does all the planning and then Stacks up the moves in the Buffer then it controls the buffer real time. BUT the only way I know of that you can overide the buffer is with the THC function(Art Magic).

Being that what you require has to be in real time  the thc function seems to be the only way . SO IF you cannot get teh THC to act like a servo I am not sure it can be done.

BUT I am thinking more and more it can be done(;-)  BUT that is just my thinking Your mileage may vary due to local conditions.

Time and testing will tell the REST of the STORY(;-) Keep us up to date on how it goes.

(;-) TP
Re: THC Settings in Mach
« Reply #13 on: September 25, 2011, 11:43:00 PM »
OK lets think WAY outside the box for a minute.

A simple servo drive IF you do not give it any input to move and you slightly rotate the shaft WILL return back to the position it was at(Up to the fault point). WHen it sees the encoder move it sends the move signal to the Motor to move back in the opposite direction to the setpoint. It knows where it was and how to get back there QUICKLY.


That's all done inside the servo drive, not Mach3.  Using the THC commands, you're still controlling the axis using on/off commands at a fixed feedrate.  The result will be the same thing we see in a THC.  Mach senses that an adjustment is needed via the encoder and triggers a THC UP.  When it hits the target, it stops but overshoots, which triggers the same routine in the opposite direction.

Here he's using an encoder to trigger the THC where we use tip voltage.  The end result is the same.
Re: THC Settings in Mach
« Reply #14 on: September 26, 2011, 01:03:16 AM »

BR549:
Quote
WELL you may need to know that MACH is a buffered system. Mach does all the planning and then Stacks up the moves in the Buffer then it controls the buffer real time. BUT the only way I know of that you can overide the buffer is with the THC function(Art Magic).

Well, that clears everything up  :)  Looks like the THC functions are the way to go.

I too think that it should be possible to mostly eliminate overshoot.  We'll know soon enough since I'm going to do my best to implement the THC version first.

rrc1962:
Quote
That's all done inside the servo drive, not Mach3.  Using the THC commands, you're still controlling the axis using on/off commands at a fixed feedrate.  The result will be the same thing we see in a THC.  Mach senses that an adjustment is needed via the encoder and triggers a THC UP.  When it hits the target, it stops but overshoots, which triggers the same routine in the opposite direction.

While implementing a fully proportional control may not be possible, I don't see why over-shoot can't be minimized.  Given that Mach3 is operating in real-time, the duration of THC on-time should dictate the distance traveled by the Z.  So, to avoid overshoot, we just need to know how early to stop moving.  For the most part, the Axis drive system is static, therefore, I should be able to implement a PID that is tuned to a a given feed rate and the current hardware.  To further enhance the system, the current feed rate and THC percentage could be sent to the AVR to adjust the motion.  Sound viable?

Writing things out always helps to clarify the thinking...  Now that I think about, I don't see how this could be much worse than a totally external THC.   Given that an external THC doesn't have any information about Mach's motion, I don't see what else it can be working with.  Aside from being able to change the speed of motion, what other parameters can it be working from.  It has a sensor and a motor.   All it can do is move based on a change and then check the result.  Since the system is in motion, it can't actually know whether the result of a commanded motion is off because of overshoot or has changed because the height has changed.  Also, I don't see any way that it can viably change the acceleration, since we always want to move as fast as the mechanics can drive.  We have to, since the height controller doesn't know how fast x and y are moving, it has to assume it must move as quick as possible.

This is my logic, no matter how flawed it may be :).  Please correct me if I'm off.

Brett
Re: THC Settings in Mach
« Reply #15 on: September 26, 2011, 09:25:55 AM »
By the time you do all that, you could just do it all in the AVR and have a system that works much better.  

The concept of a PID loop is to alter the feedrate based on the rate of change of the process variable.  By using Mach's THC function, you're still using on/off control at a fixed feedrate.  A high end THC uses a PID loop to control the Z drive directly.  That allows high speeds with no over-shoot.  It does not in any way, shape or fashion use the Mach3 THC functions.  The only thing Mach does is send a torch on signal to the THC and receive an Arc OK signal from the THC.  Mach has nothing to do with the motion control at all.
Re: THC Settings in Mach
« Reply #16 on: September 26, 2011, 12:02:21 PM »
By the time you do all that, you could just do it all in the AVR and have a system that works much better. 
By better, I presume you mean smoother motion.  I agree that the motion would be smoother.  This is with the trade off that Mach now has no idea where Z is.

The concept of a PID loop is to alter the feedrate based on the rate of change of the process variable. 
Yes, however, how does the isolated AVR system establish the rate of change.  As far as I can tell, it only knows that the height changed, it can't actually know at what rate the height is changing since it doesn't know the horizontal velocity it's moving at.  For example, if Mach is moving the axis and the height changed 0.25", we'd really need to know whether the axis is moving at 40ipm or 140ipm to establish the velocity/speed required for the Z movement.  Where I can see the PID loop being used with an external THC is to tune the mechanics.  This is static, since once the mechanics are fixed the tuning is related to the velocity and inertia of the axis.  Also, if they are using DC servos, there's a PID loop for the servos to the shaft encoders.  But, this has nothing to do with the height sensor.   Could it be that the commercial THC works better due to better drive components (ie DC Servo/Encoder instead of Steppers)?

By using Mach's THC function, you're still using on/off control at a fixed feedrate.  A high end THC uses a PID loop to control the Z drive directly.  That allows high speeds with no over-shoot.
So, given the On/Off at a fixed feed rate how can we lessen over shoot.  Since we know the feedrate, the duration we turn the THC  on will provide a set amount of travel and inertia.  If we tune the system, we should be able to turn off the signal early enough to avoid over shoot/deceleration.  Theoretically, I could put a shaft encoder on my Z and feed it to the AVR to close the loop for even more control.  And, Mach still keeps control of the Z axis.  When I think about the stepper drivers, they only receive step & dir, this is similar to what were doing with the Up/Down.  Mach sends pulses at a given frequency, we turn off/on for a given duration.  Granted, this in no way will give us the same control, but will it be good enough...  I guess I'll find out.

With starting/acceleration, the only option I see is accelerating at the maximum the axis can move.  If we don't, we stand to undershoot the slope of the height change as we lack the horizontal acceleration info.  Better to overshoot than undershoot in my opinion.

I believe this is what TP was getting at as a possible solution.

I appreciate your guys' input.  It provides new information and also helps me work out my own thinking.

Brett
« Last Edit: September 26, 2011, 12:05:04 PM by planetarymechanic »
Re: THC Settings in Mach
« Reply #17 on: September 26, 2011, 12:25:29 PM »
The rate of change is established by looking at where the axis was during the last scan compared to where it is during the current scan.  A wider gap between the two would indicate a greater rate of change.  With a cutting table, Mach provides no Z axis feedrate moves.  Feedrate moves are done entirely by the THC.


"When I think about the stepper drivers, they only receive step & dir, this is similar to what were doing with the Up/Down. "

No, it's not.  When Mach sends a command "G1 X20" for instance, it knows where it is stopping and plans for it by decelerating and stopping at exactly X=20.  When you tell it to stop via a THC command, it can not plan for that, which is why you always get overshoot.  If you can pulse the THC inputs as fast as you can pulse a step pin on a stepper drive, you might have something.  Not sure they are designed to work like that though.

Offline BR549

*
  •  6,871 6,871
    • View Profile
Re: THC Settings in Mach
« Reply #18 on: September 26, 2011, 02:05:00 PM »
IF I rememeber correctly the thcfunction runs at kernal speed just like the axis do.The reason they did NOT use the accel curve was because it slowed the move process down to much. They wanted it as fast as possible.

TomC over at CandCNC worked with Art to develope the function.You may want to hop over there and ASK him directly > Tom probably knows more about the function than anyone other than Art.

(;-) TP
Re: THC Settings in Mach
« Reply #19 on: September 26, 2011, 04:22:57 PM »
The rate of change is established by looking at where the axis was during the last scan compared to where it is during the current scan.  A wider gap between the two would indicate a greater rate of change.  With a cutting table, Mach provides no Z axis feedrate moves.  Feedrate moves are done entirely by the THC.
This same information is available to my AVR; time between samples = rate of change.  However, how useful is this information?  We have past height and current height but can we make good use of it to predict future height. Past samples and the current sample could be rising, but the next sample could falling.  As far as I can tell, we're discussing two different PID loops.  One which controls the motor position in relation to a shaft encoder.  This ensures that the commanded motion is accurate with little overshoot.  The other loop would potentially control motion in relation to sensor height over time.  I don't see how this could be implement, in any system, in any useful way.  So, it may be that I might need to change my existing Z axis over to servo/encoder in order to make the mechanics more responsive if they can't travel rapidly enough, however, this could still work with the THC Up/Down commands.

"When I think about the stepper drivers, they only receive step & dir, this is similar to what were doing with the Up/Down. "

No, it's not.  When Mach sends a command "G1 X20" for instance, it knows where it is stopping and plans for it by decelerating and stopping at exactly X=20.  When you tell it to stop via a THC command, it can not plan for that, which is why you always get overshoot.  If you can pulse the THC inputs as fast as you can pulse a step pin on a stepper drive, you might have something.  Not sure they are designed to work like that though.
Well yes, actually it is similar.  We can plan for the overshoot by stopping the signal in advance of our target.  This is exactly what the purpose of a PID control is with a server/encoder drive.  We on the other hand are trying to compensate for the overshoot/latency between our THC up/down and mach stopping motor.  Any other form of over shoot would be the result of lost steps.  And this would be no different with a servo, if the drive can't deliver the result is oscillation and instability.  And yes, as you stated, this can only work based on any potential latency in Mach surrounding the THC Inputs.

Quote from: BR549
IF I rememeber correctly the thcfunction runs at kernal speed just like the axis do.The reason they did NOT use the accel curve was because it slowed the move process down to much. They wanted it as fast as possible.
So, theoretically there should be very little latency between the THC up/down commands and the resulting motion mach commands to the drives.

Quote from: BR549
TomC over at CandCNC worked with Art to develope the function.You may want to hop over there and ASK him directly > Tom probably knows more about the function than anyone other than Art.
I knew Tom was the THC guru.  Didn't know he participated in the Mach side of things.  Makes sense though.  I'll have to send him a link to this topic to see if he has some input he wants to contribute.

Brett