Machsupport Forum

Mach Discussion => General Mach Discussion => Topic started by: planetarymechanic on September 23, 2011, 12:13:27 PM

Title: THC Settings in Mach
Post by: planetarymechanic on September 23, 2011, 12:13:27 PM
Hi;

I'm about to build a height controller for my router.  I'll be routing plastic that is irregular and need to be able to follow the contour.  In reading a number of posts, the only way this is likely viable, at an acceptable feedrate, is by using the THC Up/Down inputs to Mach.

I'll be using a shoe that slides on the surface that causes a linear resister to change value (I'll be using a HotPot from Spectra).  This will be processed by an Atmel AVR that is then interfaced to mach.

I'm trying to find detailed info on the process flow that mach uses for the THC.  There appear to be a number of settings and inputs/outputs that relate to the THC control, but I can't seem to find any in depth explanations.  An explanation of the settings and how they interact would be truly appreciated along with any thoughts from the more experienced Mach gurus.

Of course, I want to implement an easy to use system that utilizes Mach to its best advantage.  I'm open to any thoughts, suggestions, pitfalls or wild ideas :).

Thanks in advance.
Brett






 
Title: Re: THC Settings in Mach
Post by: BR549 on September 23, 2011, 04:06:27 PM
Look in the early mach2mill_6.11  Manual SECTION 6.2.13 . It gives a decent explanation of the THC process in general.

You job will be to create a controller that takes the encoder value and then set up a simple servo type loop to feed the THC UP/Down inputs back into MACH3.  It has to read the value then ACT on the value, Sending an up or down signal to Mach3. Mach3 will then COMP the Z up or down. At the same time your controller has to be watching the encoder values and STOP MACH3 when the value gets to the setpoint value. Not an easy task to do correctly to prevent oscilations of Zaxis

This means your controller has to be able to also establish the SETPOINT value based on the starting Z height and the encoder value at that point.

Easy as pie clear as mudd ?? , (;-)TP

Title: Re: THC Settings in Mach
Post by: BR549 on September 23, 2011, 04:33:19 PM
OOOPS mistake it does NOT use an encoder but  resistance values. Same thing only different(;-).

HUM I wonder IF you could use an encoder and a small servo drive to feed the up/down signal to mach3 .. ?????

Set up a simple linear encoder to feed the drive then use the drive outputs to feed the MACH3 thc inputs Up/down. You would have to put a dummy load on the drive and maybe use the DIR change of the motor signal to trigger up down????

(;-) TP
Title: Re: THC Settings in Mach
Post by: planetarymechanic on September 24, 2011, 01:08:21 AM
Thanks TP.  I wouldn't have even thought to look in the Mach2 Manual.  

The HotPot resistor should provide a simple mechanical interface and more than adequate resolution.  Plus, I want to see how these things actually perform.  I can see a number of areas I can use these in the future if they work well.

There appears to be 3 inputs and 1 output relating to the THC.  THC Up & THC Down are clear, but THC On I'm a little uncertain about.  Does this merely signal that the TCH is enabled, or does it signal that the that the Arc is Good and can continue motion?

The option Set OUTPUT5 when in THC.  I get the idea that this just turns a THC unit off and on.  Is this the case?

I'm hoping to implement these features

The ability to touch off a new router bit to a touch plate.  This would be sent to the AVR and the AVR would send this to Mach.  Mach would then stop motion and the AVR would record the position of the height sensor as zero.   Now, to touch off on plastic, the AVR could trigger the Probe input when the sensor reaches the previous zero height.

When cutting, it would be great if I could have Mach output a signal to the AVR that it has finished its Z plunge.  This way, the AVR could record this position and use it as the zero reference for sending Up/Down commands.

I'm hoping to avoid the need to implement the ability to specify an offset within the AVR and having to implement the display and keyboard that would be required.  I would prefer to see all these things set within Mach.

Any thoughts are always appreciated.

Brett
Title: Re: THC Settings in Mach
Post by: rrc1962 on September 24, 2011, 08:32:24 AM
The THC inputs in Mach3 won't give you an acceptable feedrate for routing.  Read the encoder with the AVR and send step and direction pulses directly to the Z drive.  In the AVR, you can program an acceleration ramp or even a PID loop.  Using the Mach inputs, you couldn't do either one.  An output from Mach into the AVR can enable or disable the THC.

The THC On input is Arc OK.  Mach will not move unless this is active.  You could either activate the input from the AVR or just change the the Mill setting so THC functions work without being in THC mode.
Title: Re: THC Settings in Mach
Post by: BR549 on September 24, 2011, 11:24:58 AM
You can set the MAX feedrate of the thc control via MACH  but that move does not follow the accel curve. It is just a slap in that direction up/down.

SO you have some control over the Zfeedrate.  IF you used a linear encoder then all the data is inside mach and you could use brains to run the simple loop.BRAINS are very fast. OR you could do a plugin and run at kernel speed.

You would also have direct access to the AXIS's positional data to do the set control point of the follower as an auto function.

The real question is "IS IT Practical"  Using normal cutters moves it would gouge the surface if it made a DOWN move and leave an edge mark on UP.  

We had tested something similar in the past and the finish QUALITY was NOT pretty.

WITH plasma the Z is only a means to hold up the torch and maintain the arc height. It has no effect on a surface finish such as a ROUTER would have.

RULE of Clever Inventors #1, IF it is a great idea then you will PROBALY see remnants of the idea scattered about OR will see commercial use of the idea. There is very little or next to no UNINVENTED ideas left.  AND IF it is not commercial then there is PROBABLY a good reason that it is NOT.(;-)

About the same with music. There are only so many possible QUALITY combinations mathematically possible.  

NOT SAYING don't do it, GO FOR THE GOLD


I really can't see much practical value to the process (;-) BUT I could be wrong.
(;-) TP
Title: Re: THC Settings in Mach
Post by: planetarymechanic on September 25, 2011, 10:59:19 AM
Thanks for the replies and info.

BR549:
You've provided quite a bit of info that gave me more areas to review.

Quote
You can set the MAX feedrate of the thc control via MACH  but that move does not follow the accel curve. It is just a slap in that direction up/down.
I now understand where the problem lies.  Since there is no acceleration curve applied to the motion, I'm left with either too slow of a response (low THC Speed percentage) or potentially stalling my axis (high THC percentage).

Quote
SO you have some control over the Zfeedrate.  IF you used a linear encoder then all the data is inside mach and you could use brains to run the simple loop.BRAINS are very fast. OR you could do a plugin and run at kernel speed.

You would also have direct access to the AXIS's positional data to do the set control point of the follower as an auto function.
I may change to an encoder, but I may attempt to use the HotPot and just generate an encoder output for Mach.  The mechanical interface will be a lot simpler with the HotPot.  Either way, I see the need to have a more controlled motion.  On that note, from what I understand, Brains run at 10hz and as far as I can tell, plugins run at a Max of 40hz.  My guess is that, if I provide encoder input to Mach, Mach will keep track of the encoder input at kernel speed (25kHz), and I can process the changes at at a lower speed by adjusting the Z axis accordingly.  Mach would then move the Z at kernel speed using the defined acceleration curves.  Does this sound about right?  I'm trying to wrap my head around how the whole motion controller works.

Quote
The real question is "IS IT Practical"  Using normal cutters moves it would gouge the surface if it made a DOWN move and leave an edge mark on UP. 
We had tested something similar in the past and the finish QUALITY was NOT pretty.
I understand the practical value issue.  If I was dealing with a simple router table, I would just machine it flat and skip this whole process.  However, I'm working on a rotary item that can't be pre-machined.  When you said you tested this, was that using the THC Up/Down inputs, encoder with plugin processing, encoder with brain processing or all 3.  I ask, because one test is worth a thousand theories and I can eliminate any that are already been proven failures.  :)

Quote
RULE of Clever Inventors #1, IF it is a great idea then you will PROBALY see remnants of the idea scattered about OR will see commercial use of the idea. There is very little or next to no UNINVENTED ideas left.  AND IF it is not commercial then there is PROBABLY a good reason that it is NOT.(;-)

About the same with music. There are only so many possible QUALITY combinations mathematically possible. 

NOT SAYING don't do it, GO FOR THE GOLD
I agree with you regarding Clever inventions.  But, I'm the bonehead that will travel down these paths to verify whether I'm a visionary genius or a complete moron.  Most times I fall into the moron category, but once in a blue moon, I turn out to be a visionary :).  In any event, I have to find some method to implement this height control or I stand to throw away 4 months building a machine that won't do what I need.  In the end, if I have to, I'll implement a completely separate height controller with its own drive, but I'm hoping that there is some way to implement this reliably through Mach.  Having everything in Mach is a more elegant solution.

rrc1962:
Thanks for clarifying the THC inputs and outputs.  Sadly, I think both you and BR549 are probably right about the fact that the THC Up/Down system isn't going to provide the results I need.


As always, all input is greatly appreciated.

Thanks
Brett
Title: Re: THC Settings in Mach
Post by: BR549 on September 25, 2011, 11:45:53 AM
Yes tested with encoder setup useing the thc up/down function. BUT at the time there was NO brains and I was not smart enought to do a plugin.

THERE is potential to your application. The one main problem is being able to control the Z correction(thc)  You will have to create a simple servo type loop and use the encoder as the feedback. (;-) I threw in that hint a while back. It will ACT just like a normal servo in it gives the motor a command to move and then watches the encoder to see when it gets there and stops. IT just does not have any idea WHEN it will get to location so the monitor side will HAVE to be extremely fast

OR (;-) you will have to create the logic to LOOK ahead and see how far it is to the setpoint and PREPARE to stop at that point. The motor WILL have a known curve to start stop. Nothing is instant. You just have to LEARN what you motors natural inertia curve is and apply it

A lot will depend on the accuracy you can acheive with the basic corretion move and stop.

Note: If I remember right a plugin operates at Kernal speed with all things. If not it could not do motion control functions.

(;-) It may be as simple as taking a small servo drive and using the motor side to drive relays to jog the thc up/down and use the feedback loop to auto correct back to the setpoint???

Just a thought, (;-) TP



Title: Re: THC Settings in Mach
Post by: rrc1962 on September 25, 2011, 11:50:24 AM
If you adjust the THC feedrate so it's very slow, it doesn't eliminate the problem, it just makes it less noticeable.  Because the THC moves have no acceleration applied, you will always get some degree of over-shoot, which is noticeable by the Z axis oscillating up and down.  The higher the THC feedrate, the worse it is.  In most cases, THC feedrate is set at or below 10% of the max velocity.

With plasma you can find a suitable compromise between the amount of over-shoot and the THC speed.  An oscillating Z does effect the cut edge to a degree but nothing like it would on a router.  A small amount of oscillation in plasma is acceptable but as the torch height increases, the kerf width increases, so if there is too much oscillation the cut edge will have a scalloped look.  With a router, ANY amount of Z oscillation would be noticeable.

If this is going to work, the first thing you need to do is forget about using the Mach THC inputs and start looking into external PID controllers.  This type of controller looks at the rate of change between a set variable (set voltage)  and a process variable (actual tip voltage) and applies a feedrate proportional to that rate of change.  When the PID loop is properly tuned, there is no over-shoot and the Z can run as fast as it needs to to keep up with the rate of change.
Title: Re: THC Settings in Mach
Post by: rrc1962 on September 25, 2011, 12:02:56 PM

 It will ACT just like a normal servo in it gives the motor a command to move and then watches the encoder to see when it gets there and stops.




No, it won't.  An encoder does not tell mach to stop when the encoder has reached the commanded destination.  Any time you tell Mach to stop through a THC command, there will be overshoot.  It doesn't matter how you tell it to stop.  You might be able guestimate the amount of overshoot, but that probably won't be consistent.

We even tried adjusting THC Feedrate on the fly to a value based on the difference between set volts and tip volts, but it appeared that it could not make the changes fast enough.  For that to work, you would be altering THC Feedrate hundreds of times per second.
Title: Re: THC Settings in Mach
Post by: BR549 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



Title: Re: THC Settings in Mach
Post by: planetarymechanic 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
Title: Re: THC Settings in Mach
Post by: BR549 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
Title: Re: THC Settings in Mach
Post by: rrc1962 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.
Title: Re: THC Settings in Mach
Post by: planetarymechanic 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
Title: Re: THC Settings in Mach
Post by: rrc1962 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.
Title: Re: THC Settings in Mach
Post by: planetarymechanic 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
Title: Re: THC Settings in Mach
Post by: rrc1962 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.
Title: Re: THC Settings in Mach
Post by: BR549 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
Title: Re: THC Settings in Mach
Post by: planetarymechanic 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
Title: Re: THC Settings in Mach
Post by: BR549 on September 26, 2011, 04:52:53 PM
OK here is a thought, Take a Zservo drive setup that allows slaving the servo to an outside encoder as a follower( electronic geared). Then when you need to follow switch over from Mach inputs to slaved inputs and then the z will follow the surface encoder up and down.

I have seen that part work Saved to an encoder and use electronic gearing to drive the servomotor. From Mach you could diasble the Zdrive outputs and enable the Slave drive just before a cutting move .

Just a thought, A weird one but one just the same(;-)TP
Title: Re: THC Settings in Mach
Post by: planetarymechanic on September 26, 2011, 06:51:06 PM
OK here is a thought, Take a Zservo drive setup that allows slaving the servo to an outside encoder as a follower( electronic geared). Then when you need to follow switch over from Mach inputs to slaved inputs and then the z will follow the surface encoder up and down.

I have seen that part work Saved to an encoder and use electronic gearing to drive the servomotor. From Mach you could diasble the Zdrive outputs and enable the Slave drive just before a cutting move .

Just a thought, A weird one but one just the same(;-)TP

Not so weird.  If I can't get satisfactory results from attempting this directly with THC Up/Down, I'll basically attempt to do what you described.  In reality, I believe this works out to being a separate THC since all processing is done in the AVR.  The only difference from a completely separate THC, is that I'll use the same mechanics and driver between both Mach & my controller.  This eliminates any extra hardware since I'll just share the same control signals.

Brett
Title: Re: THC Settings in Mach
Post by: planetarymechanic on September 30, 2011, 11:40:13 AM
So, I've had some time to think about this while I was waiting for a better ADC chip to arrive.  I believe I can do closed loop control with the THC commands and a slaved axis.  Here's what I'm thinking:

Slave Z Axis in Mach to C Axis.  Use C Axis output as input to AVR.  Steps/direction becomes position(encoder) info back to AVR.

Touch Probe for tool height goes through AVR to Mach.  Recorded height sensor touch position can be sent for G28.1 initial height sensing (When it reaches the previous Z touch position it sends the output).

Since Mach waits for Arc Good signal, I should be able to function along these lines:
   1) Mach Probes initial height - we send recorded sensor location as touch output and wait for Z to stop.
   2) Mach moves to pierce height (router depth?), Z Stops
   3) We see Mach Z stop, we record the position, send an ARC Good to Mach and start controlling the height.
   4) Monitor for Mach Z motion.  When Z retracts past initial height, stop height control.

In plasma, the torch touches off and then rises to pierce height.  Can this be reversed in Mach so that, after a touch off, Mach lowers to cutting depth?

I think it could work fairly well.  Does this appear potentially functional?  Am I missing something?

Thanks
Brett