Messages

1

General Mach Discussion / Re: THC Settings in Mach

« 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

2

General Mach Discussion / Re: THC Settings in Mach

« 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

3

General Mach Discussion / Re: THC Settings in Mach

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

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.

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

4

General Mach Discussion / Re: THC Settings in Mach

« 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

5

General Mach Discussion / Re: THC Settings in Mach

« on: September 26, 2011, 01:03:16 AM »

BR549:

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:

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

6

General Mach Discussion / Re: THC Settings in Mach

« 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

7

General Mach Discussion / Re: THC Settings in Mach

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

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

8

General Mach Discussion / Re: THC Settings in Mach

« 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

9

General Mach Discussion / THC Settings in Mach

« 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






 

10

General Mach Discussion / Re: Finally, Mach turn profile roughing, finishing cycle!

« on: October 14, 2010, 01:07:58 PM »

Thanks Guys

I'll most definitely report back my results after I check out the code and give them a try.

Have a great day.

Brett