Messages

401

General Mach Discussion / Re: Pressing reset sets machine coords to zero

« on: February 11, 2012, 12:03:00 PM »

It's really not clear what you're hoping to accomplish here.  The minute you hit E-Stop, all bets are off as far as machine position, unless the machine is fully stopped.  Whether you're running steppers or servos, open or closed loop, hitting E-Stop, or even Stop, on a machine in motion almost guarantees loss of position.  If you want to NOT lose position, use FeedHold.

Regards,
Ray L.

402

General Mach Discussion / Re: Pressing reset sets machine coords to zero

« on: February 11, 2012, 07:25:43 AM »

Yes, I would typically agree that is a very pertinent piece of information. I was approaching the question from more of a using Mach3 only perspective.
Dennis

Bad idea....  I believe in the KFlop plug-in settings there is a checkbox to enable re-running your Init.c whenever E-Stop is activated.  Un-check that.

Regards,
Ray L.

403

General Mach Discussion / Re: g320x gain dips

« on: February 06, 2012, 02:12:53 PM »

Just read the latest version of the user manual and nowhere does it link the gain dips to the "p" adjustment

Well, you can hardly expect Gecko tech support, or the users manual, to provide every customer with a complete education on how servo controllers work, but the terminology is pretty much universal, and well understood by those who understand servo controllers.  The P adjustment does set the proportional term of the servo loop gain.  You might want to do some Googling on PID controllers, so you have a better understanding of what all the adjustments actually do.  It's difficult to set a G320X up optimally if you don't understand what the adjustments do, and how they interact.

Regards,
Ray L.

404

General Mach Discussion / Re: g320x gain dips

« on: February 06, 2012, 02:05:38 PM »

OK, so if you find your "p" pot is out of range you would alter the dips to get it back in?
cheers
  Tony

Yes, if you find you need to set the P potentiometer to one end of it's range, then change the switches to extend or reduce the range of the potentiometer.

Regards,
Ray L.

405

General Mach Discussion / Re: g320x gain dips

« on: February 06, 2012, 02:25:17 AM »

Are you asking about the switch settings?  They simple change the range of the gain setting.  Gain is the "P" in PID.  Unless you have a reason to change it, leave the switches in the default positions.  There is no "at rest gain".  There is one, and only one gain, adjusted with the Gain potentiometer.  The Torque limit has nothing whatsoever to do with PID setting, it is simply a motor protection feature.  What all these settings do is explained rather well in the G320x user manual, but it sounds to me like you don't have a good understanding of how a PID servo loop operates.  But, if you follow the tuning steps in the user manual, or the G320X FAQ, you should have no trouble getting it working.

Regards,
Ray L.

406

General Mach Discussion / Re: ONE of THOSE days (;-(

« on: February 06, 2012, 01:27:05 AM »

All it requires is that Mach screw up on calculating one arc, and get back on track later in the path. Mis-calculating a single arc segment can do this, and since the end points of each segment are fixed, it is entirely possible for it to go off-course, then recover in time to be on-track at the start of the next segment.

Two problems with that, I think.
* I would think that Mach will be buffering the output data by clock-tick record: something like X,Y,Z,A,B,C,t . I have a problem imagining how that record access could go wrong.
* That error would have to happen randomly over runs, but at a fixed point on the Y axis, and be recoverable. That stretches my imagination.

If I am wrong, so be it. No sweat. But I think we need some experimental data with a pen.

Cheers

No, you're missing the point.  The trajectory planner takes the G-code commands, and creates a trajectory, which is a series of fairly simple, low-level motion commands - like move in a straight line from coordinates x0, y0, z0 to coordinates x1, y1, z1 at velocity v1.  Then make an arc move, at velocity v2, from x1, y1, z1, on an arc whose center is at xc, yc, zc, ending at x2, y2, z2.  A single line of G-code can create several of these commands, as the trajectory planner needs to figure out the necessary acceleration and velocity change points, and break each path into individual segments each having a constant velocity or acceleration. That is the level of command that is passed down to the driver to actually generate the pulses.  The trajectory planner knows nothing about steps, and the driver knows nothing about the overall path, it is simply blindly executing very simple, low-level motion commands.  If the trajectory planner screws up on just one of those path segments, it will tell the driver to create motion along the wrong path.  In this case, it may well break the G2 that defines that circle into several smaller arc segments, and it could well be passing the driver that one segment with correct start and end points, but an incorrect arc center coordinate.  That would exactly explain what Terry is seeing.  There is for sure nothing in his G-code that could conceivably explain the problem.

Regards,
Ray L.

407

General Mach Discussion / Re: ONE of THOSE days (;-(

« on: February 06, 2012, 12:02:38 AM »

Terry,

Obviously, there's zero chance it's an error in the G-code, given that that circle is cut by a single line of completely unambiguous code.  I don't see what this can be other than a Mach3 bug.  Are you using any kind of motion controller, like a SmoothStepper, Galil, etc?  If so, it could also be the culprit, though it's less likely.

Regards,
Ray L.

408

General Mach Discussion / Re: ONE of THOSE days (;-(

« on: February 05, 2012, 11:59:47 PM »

There are LOTS of things that can go wrong in Mach3 that would make the problem occur only randomly.

That would require that Mach emit X data well ahead of Y data by hundreds of position updates, but not lose any Y data and catch up later.
[/quote]

Which is quite easy for it to do, since the trajectory is planned based on high-level commands (e.g. a G2) that can produce thousands of position updates.  All it requires is that Mach screw up on calculating one arc, and get back on track later in the path. Mis-calculating a single arc segment can do this, and since the end points of each segment are fixed, it is entirely possible for it to go off-course, then recover in time to be on-track at the start of the next segment.  This kind of error is going to be created in the high-level trajectory planning, not at the low-level step pulse output stage.

Regards,
Ray L.

409

General Mach Discussion / Re: ONE of THOSE days (;-(

« on: February 05, 2012, 03:41:16 PM »

I'll stick my neck out here and say that it will NOT be the code. If it was, you would get it EVERY time, and you would NOT end up at the right starting point.

Not sure if by "code" you're referring to Mach3, or Terry's G-code.  There is certainly no reason to believe it is NOT being caused by a bug Mach3.  And, in fact, very good reason to believe it IS a bug in Mach3.  A bug in the G-code would manifest first time, every time, IF the controller (Mach3) was executing it in a consistent, repeatable manner.  The chances of a bug in either the G-code or the hardware manifesting in the exact same way, at the exact same position in the work, AND getting back on-track afterwards is exceeding small.  There are LOTS of things that can go wrong in Mach3 that would make the problem occur only randomly.  It can be a race condition in the code, or other timing problems, requiring two or more asynchronous events to occur in just the right order, with just the right timing, in order for the bug to manifest.  And, in fact, this is precisely the kind of bug Mach3 has had more than a few of over the years.  I have been through it many times with Mach3.

Regards,
Ray L.

410

General Mach Discussion / Re: Some guidance on spindles

« on: January 30, 2012, 10:07:51 AM »

Both Dremels and routers are readily available with variable speed controls....