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






 

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

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

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

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.

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

Thanks for the replies and info.

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

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).

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.

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. 

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

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

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.

 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.