Messages

911

General Mach Discussion / Re: Problems threading on the lathe

« on: September 29, 2009, 03:23:37 PM »

Rich:

  Excellent testing!!

    I agree with your comments. Though I suspect a nut would screw on even to the end of the thread.

 Interesting that it happens at certain passes, that seems to indicate the sensor blipped a bit late or early in the trigger.
After triggering the thread, if the sensor did blip late a bit it probably wouldnt matter as it self corects during the pass, so
I suspect what we're seeing is that the sensor sometimes delays a bit ( or the computer does somehow ), and the problem
occurs when iut does it during the initial trigger of the thread.

  I have to note that of all tests on threading performed to date, yours are the most scientific, and the best documented.

Interesting that 20 passes were good, then the problem occured and toggled about between various pass points. It does seem as if
our collective problem is the timing of the initial start at times, not so much the correction during the pass. Of course you likely have very little
slowdown if any so the nice passes reflect a steady output from initial start point.

Ill dwell on it a bit..

Art

912

General Mach Discussion / Re: Problems threading on the lathe

« on: September 29, 2009, 01:23:04 PM »

Rich:

  Each pass is its own entity, there is no difference from pass to pass. Correction occurs only during a pass, all knowledge is lost after the pass,
so if it cuts deeper overall, then it has to be the X depth or its fooling you because its cutting inot a crest making you think its deeper than it should be.
But there is only correction during a pass, and it knows nothing of previous passes..

Art

913

Tempest Trajectory Planner / Re: Tempest Planning - Preliminary information and testing

« on: September 29, 2009, 10:03:23 AM »

Mike:

  Youd think it would.. and Ive run many tests but I dont see huge differences. I wouldnt bother going above 50 or so, since Tempest is really queued on the blend speed calculations, the added lookahead seems to have diminishing returns after about 50 lines even in small segement code. It REALLY beats quantum in that small segment code will go almost as fast as Mach3 in many instances.

Art

914

General Mach Discussion / Re: Problems threading on the lathe

« on: September 28, 2009, 10:20:08 PM »

Rich:

 I suspect your on to it. The problem in my mind may be that if a sensor varies.. its variance is pretty much set, lets say its a uSecond early on one pass, maybe 1us late on another.If the rpm is lower, that constant variance will be less as a % of the total time used. Your example was a 4 time differential between the two periods.. At 115rpm the 1us variance may be 5% of the total, but at 405 it may now reflect 20% of the total timing.. accuracy would fall as the constant lagging or leading variance would slowly make it go out of known position.

   Now it may not be the sensor.. it may be the printer port interrupting a bit late at times.. same effect..

I do know that if I feed a signal in my printer port from a frequency generator, its dead on and very repeatable, but when my spindle sensor is measured, its floating about 3us either way at times..
(I think its 3us.. its been a few weeks.)

Art

915

Tempest Trajectory Planner / Re: Tempest Planning - Preliminary information and testing

« on: September 28, 2009, 07:35:19 PM »

Mike:

 Yes, the planner IS a module, BUT the current planner in Mach3 is a very speciallly modified planner module that is hooked in many spots in special ways to allow for things such as partial motions due to feedhold, and reverse run and such. It is not planned to make those same connections but to make the new planner mathmatically pure, that is to say it will follow a real-world physics engine of calculations based on accelerations, velocities and tangental acceleration calculations. This means it will likely never appear as Mach3's standard planner, though if it does work as well as I hope, it may be offered as an upgrade module for those that need or want it. Its in early days, but my vision is one that woudl allow for graphically identfying the configuration of a system and allow the kinematics to
control the 9 axis to produce in the end a 3D coordinate from all 9 axis. It woudl allow for proper robotic control, or perhaps hexapod type running from normal 3d GCode.

  Its a very long way from here to there, but the first most important step is to get the accuracy and jerk reduction under control. After running the nose cone Id say Im happy with both at this point.
Ill watch further testing and move on to proper math pure and jerk free feedhold code, then it will be on to kinematics matrix configurations. Youll likely have test versions available for awhile till it is at least a match for all spec'ed capability. We'll see where testing takes us. . Each error last week fixed up important sections to the point that other than feedhold im pretty happy ( very happy actually)
with the run time performance, while it is slower then Mach3 dependant on jerk limitation set ( as one woudl expect) , it offers higher accuracy at high speeds through most types of code.

Art

916

General Mach Discussion / Re: Problems threading on the lathe

« on: September 28, 2009, 06:04:41 PM »

Simpson:

   I do believe the oscillations of the vfd autocorrections have an effect. But its all more accurate than youd think. Firstly, I keep a rather large
64 bit counter of the actual times involved and keep track of remainders.. While errors can be created by entering the material offset from the actual index pulse, those errors
self correct from rotation to rotation. The way the math works it keeps in in as good a track as possible, but the vfd can negate some of the safety there. I suspect its better
not to have a correcting vfd personally.

  Consider a 5 rotation thread, with some fake numbers..

We have planned the motion and filled the output buffer with 1mm ( 2000 steps) per rotation. We start with the trigger.

Unit triggers on index, motion begins...Counters are zero'ed.. static measurement of one spindle rotation of say 26000000 nanoseconds per rotation is now locked in as base. This
is being measured all the time as the unit waits for the index trigger prior to threading..

So motion begins and we wait for next index.
Index hits.



When index pulse hits, we look to the number of nanoseconds passed. Say its 28000000 nanoseconds.

We now subtract 26000000 from the counter, leaving 2000000. We now slow the motion by 7.6% over the next
rotation, but its done by a bresenham division algorithm that keeps track of the remainders, so that each rotation can help
correct for overcorrection on a previous rotation. Each rotation is linked that way to the entire thread. Think of it this way..

I--------I--------I--------I-------I

Before the thread is even started, Mach3 knows that a certain number of total pulses should have come out by the time each "I"
in the above line is encountered, ( "I" being an index pulse). By counting the pulses and the position of the index pulses
we can calucate exactly how many steps short we are ( or over ) at each index pulse. The correction therefore is not based on the last rotation, but on the total number of rotations and the total number of pulses that should have gone out. SO while one rotation may
contain an erronous slowdown due to tool entry etc.. the actual correction on the next rotation will take that into account
as a sum total of the entire thread. The numbers will then always be pretty correctable UNLESS the spindle speeds up in its correction
to make it impossible for mach3 to catch up, as it cannot speed up anymore than the planned speed of 1mm per rotation.

  In theory, this is of a high enough order of correction that added corectional steps would have little influence. The trick is
not to look at each rotation time as the correction for the next rotation, but for each rotation time to add to the whole
and be used to correct for position that far into tthe thread it has reached. Keeping track of raminders allows this to be very robust.

   Ill be testing over the next few weeks and will update the dialogs to show expected vs real poition and the correction applied as a result.

Thx
Art

  

917

Tempest Trajectory Planner / Re: Tempest Planning - Preliminary information and testing

« on: September 28, 2009, 05:41:27 PM »

Hi Mike:

  Actually, I just cut the nose cone in a block of spruce, it cut very well, and turned out perfect.

As to the blend radius. Think of it as the worst-case deviation from the path you have set. In reality, it follows a
"Ruile of 1/8th" . That is to say if two lines are joined to gether, the blend will be at most the setting in the dialog,
say..10mm as default, but will always be a maximum of either 1/8th the length of the shortest of the two lines, or the
set amount. SO two 100mm motions will have 10mm raidus by default, a 100mm line entering a 60mm line woudl have
60 * .125 = 7.5mm as its blend. In micro segment code, this means the blends will be very small to make it all very accurate,
if two lines are .1mm each, then the blend between them will be .0125mm radius.

  In this way the accuracy increses as the line segment sizes shrinks. As blends shrink the max speed though them shrinks as well,
but the physical  limits are generally high, so it isnt generally noticable. SO basically, a 10mm or in inch mode perhaps .5" would be good for all
program types as loong as a .5" radius is not too much for you. Set it as low as you like, its only a maximum.

  I was very pleased at the running of the nose-cone, seemed to work well. Vary your jerk setting till you like the smoothness offered, and you should
be able to leave it there, though it can be handy to raise Jerk limits for very tight code to allow for faster motion overall.

Art

918

Tempest Trajectory Planner / Re: Tempest Planning - Preliminary information and testing

« on: September 28, 2009, 01:26:39 PM »

Hi Mike:

 And this is on the 27 version? Ill start tracing for less jerk allowance. That line 6 is the maximum theoretical jerk point as it has to cv a hermitic curve between two full circles.
It does cause a slight aberation, but in my version 27 I got that aberation low enough that it wont trigger any jerk alarm on my system. Ill trace deeper.

Thx
Art

919

General Mach Discussion / Re: Problems threading on the lathe

« on: September 28, 2009, 01:25:01 PM »

Simpson:

  Your right..and your wrong.

  During a period of rotation, there may be as many as say 5000 interrupt periods.. Mach3 is measuring how many interrupt periods occur, or used to. It now measures how many megaclocks occur, at a base rate of about 2Ghz say..

  So for each rotation we measue the megaclocks..this is before we actually cut. Now lets say we get 24,000,000 as a steady rate prior to cut. We simply divide to show the rpm..

 Now we start the movement, since we're in mm/rev mode, we know the mm's of motion were calculated based on 24,000,000 clock cycles per rotation. If the ortation is sensed to be now 2700,000 clocks per rotation, we know the spindle has slowed by 12.5% .. so we now slow the output during the next rotation by 12.5%, and keep track of this rotation.

 SO your right that the correction is always 1 rotation behind in terms of correction, but it can be shown statistically that if one rotation is off, the next rotation will be off the same amount +- a certain %, it may for example keep slowing down.. in which case each rotations motion in the Z axis is further slowed. As a rolling % of correction we begin to approiach the center of the bell curve of probablities of where the spindle is likely at.

  Its a fairly good method of correction, and works well as long as the megaclock is stable ( is always is unlike the number of interrupts per rotation which varied much more ) and the sensor is stable..mine isnt and Ive seen many that werent. At any rate, its pretty good to about 10-15% variance on most systems but other influences can throw off the statistics and make the thread wander higher and higher over time. This is why the wandering thread pitch as you go further out. Mach3 cannot speed up from original speed, but can easily slow and speed back up to normal speed. Testign shows this works but we're simply trying to make it better.

The system knows that after so many rotations, we shoudl be in such and such a position and simply tries to get there bassed on the number of ratoations seen, current position, and speed.

There will always be a limitation based on the fact we arent real-time though.
Art

920

General Mach Discussion / Re: Problems threading on the lathe

« on: September 28, 2009, 10:31:20 AM »

Rich:

  No, variance doesnt carry to the SS, it has a fixed period cycle that wont ( or shouldnt ) vary. Your computer shows a sign of instability with a low reading of 22000 and a 200 variance. What does the drivertest show? A stright line? or is it more of a sawtooth?

   Its my suspicion that the variance can be caused by the cpu being less than perfect in when it triggers the interrupts.

Art