Hello Guest it is April 19, 2024, 12:15:53 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - rrc1962

311
Keling is in a suburb of Chicago.

312
General Mach Discussion / Re: THC Settings in Mach
« 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.

313
General Mach Discussion / Re: THC Settings in Mach
« 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.

314
General Mach Discussion / Re: THC Settings in Mach
« 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.

315
General Mach Discussion / Re: THC Settings in Mach
« 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.

316
General Mach Discussion / Re: THC Settings in Mach
« 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.

317
General Mach Discussion / Re: THC Settings in Mach
« 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.

318
General Mach Discussion / Re: CPU processing speed ???
« on: September 23, 2011, 10:53:26 AM »
I try it every day.  I've been running code in macros for years.

"NOT so smooth as if Mach was running it ONE line at a time and then wait and run another line of code."

I get this issue when running straight G-Code on small segmented arcs such as a lead in or a slot with a long long straight segment then a small arc.  Mach will hesitate at the start and end points of the small arc as if it's in exact stop mode.  If I make the arcs larger, it's smooth as silk. 

319
General Mach Discussion / Re: CPU processing speed ???
« on: September 22, 2011, 10:28:22 PM »
I have an 800mhz that will skip without isMoving() statements.  Also have a 2.8ghz that does the same thing.  The problem is that CB code executes faster than G-Code.  I don't think slowing down the processor so CB executes at the same speed, even if it were possible, is a good solution.  Never had a problem with isMoving statements, other than it makes the code look a bit messy.  I've done tests where I executed a specific G-Code routine using just CB with isMoving Statements and just straight G-Code.  Execution time was the same...Or so close it wasn't perceptible.


320
General Mach Discussion / Re: Computer Problems-Jittery steppers
« on: September 20, 2011, 12:21:41 PM »
The older Dells work great (Full tower GX260).  The full size desktops and small form factor desktops are almost always a no-go.  I've had mixed results with the newer towers.  It works out OK because the old GX260's work like a charm and you can just about get them for nothing.