Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: HimyKabibble on November 29, 2009, 08:51:05 PM
-
Today I ran into a new problem.... I started using ramping to start cuts - this typically means a 3-axis helical move. But, on some of them, my Z axis servo is faulting! If I run the offending lines in isolation, they NEVER fault, even when run repeatedly. Also, if I reduce the X/Y acceleration to what the Z axis is set to, the problem also goes away. I've been using this machine for over a year, and NEVER had a servo fault, except when I accidentally ran an axis into a hard stop. I've also verified the supply voltage is holding well, never dropping more than about 1.5V from its nominal value. I'm suspecting perhaps Mach3 or the SS is not respecting the MUCH lower acceleration setting for the Z axis when entering the 3-axis moves, as the fault occurs almost instantly, before the Z axis has moved hardly at all.
How do I find and fix the cause of this so I can get back to work??
Regards,
Ray L.
-
Hi, Ray
Post the G code your having problems with for a start.
Chip
-
Hi, Ray
Post the G code your having problems with for a start.
Chip
Chip,
Here's one example. The faults occur *only* on the 3-axis helical moves, yet I can take those lines, and run them over and over with no problems at all. It's only when run *with* the preceding moves that the fault occurs.
(Filename: Mount Plate Ramped.tng)
(Post processor: My Mach2 Post 090819.scpost)
(Date: 11/29/2009)
G20 (Units: Inches)
G40 G90
F10
(Part: Fixture Plate)
()
(Process: Spiral pocket, Lower Support Shaft Bore, T145: 1/2 Carbide, uncoated, 3-Flute, Aluminum Cutter, 1XSlotting [145], 0.52 in Deep)
G00 Z1.5000
(1/2 Carbide, uncoated, 3-Flute, Aluminum Cutter, 1XSlotting [145])
M06 T1 G43 H1 (1/2 Carbide, uncoated, 3-Flute, Aluminum Cutter, 1XSlotting [145])
G00 Z1.5000
M00 ( Pulley: 4 Motor: H )
M966 P8
M03 S6120 (Spindle CW 6120 RPM)
M07 (Mist coolant on)
G00 X27.6000 Y9.1579
G00 Z0.0197
G01 Z0.0000 F4.896 S6120
G03 X27.8421 Y9.3947 Z-0.3750 I0.0000 J0.2421
G03 X27.6000 Y9.1579 I-0.2421 J0.0053 F29.376
G03 X27.7365 Y9.2000 Z-0.5200 I0.0000 J0.2421 F4.896
G03 X27.7365 Y9.2000 I-0.1365 J0.2000 F29.376
G00 Z1.5000
()
(Process: Spiral pocket, Lower Retainer Shaft Bore, T145: 1/2 Carbide, uncoated, 3-Flute, Aluminum Cutter, 1XSlotting [145], 0.52 in Deep)
G00 X27.8000 Y5.4579
G00 Z0.0197
G01 Z0.0000 F4.896
G03 X28.0421 Y5.6947 Z-0.3750 I0.0000 J0.2421
G03 X27.8000 Y5.4579 I-0.2421 J0.0053 F29.376
G03 X27.9365 Y5.5000 Z-0.5200 I0.0000 J0.2421 F4.896
G03 X27.9365 Y5.5000 I-0.1365 J0.2000 F29.376
G00 Z1.5000
()
Regards,
Ray L.
-
Hi, Ray
Try this.
(Filename: Mount Plate Ramped.tng)
(Post processor: My Mach2 Post 090819.scpost)
(Date: 11/29/2009)
G20 (Units: Inches)
G40 G90
F10 ;------------------------------- F10 Set
(Part: Fixture Plate)
()
(Process: Spiral pocket, Lower Support Shaft Bore, T145: 1/2 Carbide, uncoated, 3-Flute, Aluminum Cutter, 1XSlotting [145], 0.52 in Deep)
G00 Z1.5000
(1/2 Carbide, uncoated, 3-Flute, Aluminum Cutter, 1XSlotting [145])
M06 T1 G43 H1 (1/2 Carbide, uncoated, 3-Flute, Aluminum Cutter, 1XSlotting [145])
G00 Z1.5000
M00 ( Pulley: 4 Motor: H )
M966 P8
M03 S6120 (Spindle CW 6120 RPM)
M07 (Mist coolant on)
G00 X27.6000 Y9.1579
G00 Z0.0197
G01 Z0.0000 F4.896 S6120
G03 X27.8421 Y9.3947 Z-0.3750 I0.0000 J0.2421
G03 X27.6000 Y9.1579 I-0.2421 J0.0053 F29.376
G03 X27.7365 Y9.2000 Z-0.5200 I0.0000 J0.2421 F4.896
G03 X27.7365 Y9.2000 I-0.1365 J0.2000 F29.376 ;--------------F29 Set Hear
F10 ; Try this Hear -----------------------------------------F10 Hear may be hear
G00 Z1.5000
()
F10 ; Try this Hear -----------------------------------------F10
(Process: Spiral pocket, Lower Retainer Shaft Bore, T145: 1/2 Carbide, uncoated, 3-Flute, Aluminum Cutter, 1XSlotting [145], 0.52 in Deep)
G00 X27.8000 Y5.4579
G00 Z0.0197
G01 Z0.0000 F4.896
G03 X28.0421 Y5.6947 Z-0.3750 I0.0000 J0.2421
G03 X27.8000 Y5.4579 I-0.2421 J0.0053 F29.376
G03 X27.9365 Y5.5000 Z-0.5200 I0.0000 J0.2421 F4.896
G03 X27.9365 Y5.5000 I-0.1365 J0.2000 F29.376
G00 Z1.5000
()
M30
%
Chip
-
Chip,
I don't understand what that changes. The knee will rapid all day long at 50 IPM with no problems. and the fault is occurring on the first and third G03 moves of each set, never on a single axis move. X and Y rapid at 200 IPM, and also have never lost position. What would those F10s accomplish?
Regards,
Ray L.
-
Hi, Ray
It was just a Quick Thought, Guess I Missed part of your Issue.
Chip
-
Looks like this IS a Mach3 bug. Brian has just sent me a test version that will hopefully fix it.
Regards,
Ray L.
-
OK, Brian has just confirmed this *is* a bug in the Mach3 CV code, and he's working on a fix. As for my situation, if I go to exact stop mode, the problem goes away. Since I'm not doing 3D profiling, this shouldn't cause me any significant grief, so I'm off to make some chips.
Regards,
Ray L.
-
Brian,
Could you please give us some details about what this bug is and in what verison it appears. I do alot of 3D machining and I have recently been chasing what appears what shows up as lost steps on Z. I've been assuming it was hardware related but maybe not. - Thanks - Tery
-
Well, the plot thickens..... I *thought* exact stop mode would get me going, but it's not 100% reliable, so I'm still dead in the water. I re-wired my controller so the Z axis is on a completely separate power suppply, breakout board, etc., to make sure there is no interference when all three axes are running. This made no difference.
I'm quite convinced at this point it is a Mach3 bug. I can do slow helical interpolations between two points, and get it to fault a LOT. I can do linear interpolations between the same two points all day long with no problems. In fact, I can even do rapids between the same two points, with the Z axis acceleration set to 3X the normal value, and it never faults. So, Mach3 seems to be violating the Z axis acceleration limit when doing circular interpolations.
Back to waiting for Brian to come up with a fix....
Regards,
Ray L.
-
Brian,
Could you please give us some details about what this bug is and in what verison it appears. I do alot of 3D machining and I have recently been chasing what appears what shows up as lost steps on Z. I've been assuming it was hardware related but maybe not. - Thanks - Tery
Tery,
My understanding is this problem has been in there for a long time, but will only be a serious problem on machines with widely different accelerations on the various axes. In my case, X and Y accelerations are 25X the Z axis acceleration. This is why *most* people have no problem, but guys with goofy machines like mine will see it. It is not respecting the acceleration setting for the "slow" axis.
Regards,
Ray L.
-
Thanks!!!
-
Hi,
I have seen the same problem when machining parts with retainer "tabs"
The X & Y accellerations are very different to the Z, as the Z is a driven knee.
If I am feeding x and y at say 300mm per min, the knee tries to do the same if the tabs ramp at 45degs. (Max Z is 250mm/min)
So I have to limit the angle of the tabs so that the Z axis does not "overspeed".
I don't see this as a Mach fault as when the Z moves Mach would need to limit the X & Y feeds to match the maximum acc / vel of the knee.
So I either speed up the knee or fit a Z on the quill....or buy a VMC ;D
ATB
Deker
-
Hi,
I have seen the same problem when machining parts with retainer "tabs"
The X & Y accellerations are very different to the Z, as the Z is a driven knee.
If I am feeding x and y at say 300mm per min, the knee tries to do the same if the tabs ramp at 45degs. (Max Z is 250mm/min)
So I have to limit the angle of the tabs so that the Z axis does not "overspeed".
I don't see this as a Mach fault as when the Z moves Mach would need to limit the X & Y feeds to match the maximum acc / vel of the knee.
So I either speed up the knee or fit a Z on the quill....or buy a VMC ;D
ATB
Deker
It *is* a Mach fault. What it is *supposed* to do is always respect the settings (both acceleration and velocity) of *all* axes, and keep the move within the limits of all axes at all times. That means if X and Y are fast and Z is slow, then X and Y are slowed down so Z does not exceed it's capabilities. Obviously this is far easier to achieve if all axes have the same capabilities, but that's not the way the real world works. The operator should not have to worry about keeping within the capabilities of individual axes on complex moves.
In your example, the correct thing for Mach3 to do is to run X and Y at 300 mm/min, until they get close to the tab. X and Y should then decelerate so that when they reach the start of the tab, they are down to a speed that allows the Z axis to be moved without it needing to accelerate faster than it's maximum acceleration, or having to exceed it's maximum velocity. Once past the tab, and the Z axis is again stopped, X and Y should then accelerate back up to 300 mm/min.
Regards,
Ray L.
-
Well , now, then.
Seems to me a while back I put a post in this forum about not driving the Knee for the Z axis. Maybe , just maybe , this is one of the reasons, along with a few more. ;D
Ed
-
Well , now, then.
Seems to me a while back I put a post in this forum about not driving the Knee for the Z axis. Maybe , just maybe , this is one of the reasons, along with a few more. ;D
Ed
Ed,
Look at the bright side - Using the knee as the Z axis has highlighted a bug in Mach, that will now get fixed. So, using the knee is a good thing! There are several people piping up who have had this same problem, so I'm far from the only one getting bit.
What's funny about this is, what I'm making right now is my quill drive. If I'd finished this one project without running into this bug, I NEVER would've seen it, as my quill drive will be at least fast as my X/Y axes!
Regards,
Ray L.
-
Ray ,
Yes , the quill drive will be the quickest and most profitable way to go. Keep the knee servo for tool length offsets.
Ed
-
It's NOT a CV bug!
I just did an interesting test - I wrote a simple test program that does:
Short, 2-axis linear move to initial position at 100 IPM
Short, 3-axis linear move to second position at 5 IPM
Repeat the above two moves in reverse, ending up back at the start position
This is run in a loop, and works perfectly every time.
I then replaced the two 3-axis linear moves with a helical move between the same two points, at the same feedrate
This faults the Z servo every time.
I then set the Z acceleration as low as Mach would allow (~0.2), and put an oscilloscope on the Z axis STEP line. Running the first test, I see a nice acceleration over the first ~0.5 second of the Z move. Running the second test, the step rate goes instantly from 0 to 10kHz - NO acceleration ramp at all! But it does appear to do a proper deceleration at the end of the move!
Note that the behavior is exactly the same, whether I run in CV or ExactStop mode, so it's NOT a CV problem.
Regards,
Ray L.
-
This sounds eerily familiar
If someone is working on this problem, they should also consider that this behavior is present on, or is triggered by the A axis.
Under certain conditions, if the A axis and the X axis (for example) start moving together, MACH ignores acceleration and just slams the X axis from zero to feedrate. I don't recall off hand the circumstances, but I posted some details on this quite some time ago.
Sounds like this may be a symptom of the same bug, so I thought it worth mentioning.
-
This sounds eerily familiar
If someone is working on this problem, they should also consider that this behavior is present on, or is triggered by the A axis.
Under certain conditions, if the A axis and the X axis (for example) start moving together, MACH ignores acceleration and just slams the X axis from zero to feedrate. I don't recall off hand the circumstances, but I posted some details on this quite some time ago.
Sounds like this may be a symptom of the same bug, so I thought it worth mentioning.
Simpson,
Yes, Brian mentioned that when I spoke to him yesterday. I believe that problem will also be fixed when he's done.
Regards,
Ray L.
-
This sounds eerily familiar
If someone is working on this problem, they should also consider that this behavior is present on, or is triggered by the A axis.
Under certain conditions, if the A axis and the X axis (for example) start moving together, MACH ignores acceleration and just slams the X axis from zero to feedrate. I don't recall off hand the circumstances, but I posted some details on this quite some time ago.
Sounds like this may be a symptom of the same bug, so I thought it worth mentioning.
I've had issues with the A stalling in a similar fashion, rates were WELL below anything that would cause the axis to stall. Interestingly enough I found that reducing the rates themselves in the program did nothing to stop the stalling behavior, but when I backed down the FRO even just a tiny bit, it would no longer stall.
-
This sounds eerily familiar
If someone is working on this problem, they should also consider that this behavior is present on, or is triggered by the A axis.
Under certain conditions, if the A axis and the X axis (for example) start moving together, MACH ignores acceleration and just slams the X axis from zero to feedrate. I don't recall off hand the circumstances, but I posted some details on this quite some time ago.
Sounds like this may be a symptom of the same bug, so I thought it worth mentioning.
I've had issues with the A stalling in a similar fashion, rates were WELL below anything that would cause the axis to stall. Interestingly enough I found that reducing the rates themselves in the program did nothing to stop the stalling behavior, but when I backed down the FRO even just a tiny bit, it would no longer stall.
The problem, as I understand it, affects "secondary" axes, and helical moves. If you have one or more axes in motion at a reasonable speed, then do a helical move that brings in a "secondary" axis, Z in my case, the CV code does not correctly account for the acceleration capability of the secondary axis, resulting in the primary axes entering the helical move too fast, thus requiring the secondary axis to accelerate essentially instantaneously. Apparently, it's not that the correction is not being done correctly, but rather that it's not being done at all! The code simply wasn't there. The same problem apparently existed until fairly recently on linear moves as well. Brian fixed that a while ago, but never got around to making the changes to the helical move code. He know exactly what to do, and how, so he should have a fix very soon. I'm actually surprised this hasn't been a much bigger problem for more people. I suspect once the new code is out, a number of problems will vanish, and many of us may be able to kick up our velocity and acceleration settings closer to the limits.
Regards,
Ray L.
-
Just to comment a bit further, I've been noodling over why the problem went away for me, and what I assume is that I probably still have the problem with the A axis, but since I went to servo motors and then better servo drives, the issue has not been able to manifest because the motors get a little behind during the 'instant' accell, but catch up within a tiny amount of movement, and most likely before the cutting tool touches the workpiece, so there is no practical effect.
If I recall correctly, I read somewhere that you are using Gecko drives. They have only a tiny error allowance and not much power (for a big motor), so they are unable to tolerate the error created by the slammed motor.
Be nice to have it fixed in any case . . . .
While I have your attention, Ray, let me repeat my appreciation for the great manual you have produced. Only used it a couple times, but even then it has saved me a lot of time and hassle.
-
While I have your attention, Ray, let me repeat my appreciation for the great manual you have produced. Only used it a couple times, but even then it has saved me a lot of time and hassle.
Thanks! If you like that, just wait until you see what's coming in v4.... :-)
Regards,
Ray L.
-
What manual are we talking about?
-
What manual are we talking about?
http://www.machsupport.com/forum/index.php/topic,12730.0.html
-
I've also verified the supply voltage is holding well, never dropping more than about 1.5V from its nominal value.
If all 3 axis have a fast excelleration time, the power supply could be the issue. Did you use a scope to see the supply voltage or DVM? A DVM will filter out the surge/voltage drop. You might try a second supply just on the Z.
JH
-
As I kicked up the speed and accell higher and higher I got into an area where simultaneous slamming of all the motors at once started to cause occasional faults.
After clearing it with the drive maker, I installed big caps directly across the power terminals on each drive.
Not a single problem since.
-
Aaaargh!
I just ran into this bug!
Mach is losing steps in Z when doing a ramping helical interpolation in certain scenarios. It actually appears to handle arc center at X,Y of 0,0 just fine, but certain values of x & y causes it to lose steps... and it loses it exactly the same way and place every time.
I've attached a code segment that performs a finishing cleanup on a parabola which triggers the problem for me. Just to make sure I was sane, I put a digital counter on the z step pin and mach is simply not sending enough steps but it displays that it's in the correct position.
If I had to put money on it, whatever algorithm that was used to calculate the number/timing of Z step pulses during the ramping helical interpolation is running into either a casting or flooring issue.
-
Aaaargh!
I just ran into this bug!
Mach is losing steps in Z when doing a ramping helical interpolation in certain scenarios. It actually appears to handle arc center at X,Y of 0,0 just fine, but certain values of x & y causes it to lose steps... and it loses it exactly the same way and place every time.
I've attached a code segment that performs a finishing cleanup on a parabola which triggers the problem for me. Just to make sure I was sane, I put a digital counter on the z step pin and mach is simply not sending enough steps but it displays that it's in the correct position.
If I had to put money on it, whatever algorithm that was used to calculate the number/timing of Z step pulses during the ramping helical interpolation is running into either a casting or flooring issue.
Any time you run CV mode, and have a move in X/Y followed immediately by a helical move in X/Y/Z, you have the potential for the Z acceleration limit to be exceeded. If X/Y/X all have the same acceleration capability, there should not be a problem, but if Z is less than X/Y, then its acceleration limit WILL be exceeeded, and it will probably lose steps as a result. This has *always* been a bug in Mach3, and has not yet been fixed. The work-around is to run in exact stop mode.
Regards,
Ray L.
-
Hmm... thanks for the suggestion but that's really too bad :'(
The problem with exact stop is that it will definitely introduce a perceptible point of entry during the finish pass of the reflector. I absolutely needed to have it to have a consistant surface finish and so I even have the software compute the arc length during the ramp to change feedrate and spindle speed to create a consistent surface and also maintain an effective z plunge feedrate and the entry point.
As an added bonus, After I changed to code from a "plunge then pocket" per iteration to the helical ramp to pocket with a helical return to center turned a 45 minute job into 15 minutes.
The only thing I discovered was that as long as I keep at least one of the axises (axii?) of I/J at zero from out outset everything works peachy.
Any other workarounds or alternatives anyone can think of would be highly welcome.
-
My apologies for posting on a dormant topic. I started to write a separate one but it just seems more appropriate here.
Has there been any word on the fix for this? I am experiencing a problem that seems similar if not the same. My problem happens on rapid moves however. If I only move one axis at a time, I have no problems. But if I move more than one axis, it seems like the secondary axis (not the one with the major portion of movement) will miss steps and stop (even though I can hear the unmistakable sound of step commands with no steps).
It seems like it is busting the Accel/Velocity capabilities of secondary axis. I tried lowering both the accel and velocities in motor tuning, but the thing that made it go away was moving only one axis at a time.
Something interesting also, if I change from G0 to G1 but set the feedrate the same as the maximum in the motor tuning, all is well.
So, has HimyKabibble's bug been fixed? If so, what version of Mach3 did it get fixed? Could my problem be the same?
Thanks!
-
Nope... I've waited for months for a fix or workaround but at this point I've given up on Mach and am using EMC for now. Its a shame since I ended up buying a couple licenses for Mach before I found out that my parts were coming out
wonky. :( I'm just crossing my fingers and hoping that they'll fix it sometime in the next few years.
I've run into it during thread milling, Running the 4th and 5th axis, etc... The same bug affects other obnoxious places and everyone always says "It's not a bug its a feature OR just use exact stop" Neither of which are reasonable suggestions. It was while I was doing internal thread milling that I just said screw it and built an EMC box.
I've only seen very few mills that would optimally use the same acceleration for all axises. I have a Bridgeport CNC with the Elrod quill drive and ballscrews on all axises, and the X&Y can support a much greater acceleration than the quill.
AND the bug still exists if you set the acceleration the same, my system is running 0.0001 glass scales and I can still see the problem, it's just not catastrophically major if you don't care about a thousandth loss here or there.
Before people say it's my machine, Mach works great for everything else and EMC has no problems running the same code with no problems.
-
Brian started working on a fix for this when I first found the problem, about a year ago, IIRC. But, after a few days, he got off on something else. AFAIK, he's never come back to it. And I know it was NOT a simple thing to fix either. Last I heard from him - probably close to six months now - he was spending all his time trying to get v4 done. I haven't heard anything about his progress on that for a long time either.
Meanwhile, the only solution for this problem is exact stop mode - not a very nice way to work. Or, avoid starting a third axis while two others are already moving.
Regards,
Ray L.
-
Thanks HimyKabibble, I looked into it myself looking for a workaround and the problem seems to be, from what I can tell from purely external testing, is that mach chops the less significant decimal points that don't fit in the DRO and works off that "massaged" value. This probably helps at the end of a move so you don't have weird ceiling/floor reversals as a response to commanded values, but for "advanced" moves such as a helical interpolation with Z component with differing acceleration, it has a tendency to accumulate errors. Basically rounding off the floating point numbers while within the iteration.
Personally, I could very easily deal with an "out of band" g-code command that says "Set acceleration to the slowest value for all axises" and another one that restores standard values. Or any workaround of that nature. Exact-stop by its very nature defeats the entire purpose of any operation that requires a helical ramp.
Here's to hoping for v4.
-
No, the problem is a "blended" move, when you're moving in two axes, then bring in a third, the acceleration of that third axis is not handled correctly, so the axis acceleration limit is not respected. IIRC, it only occurs when the third axis is started up *during* a circular move in one or both of the other axes. If they're all straight-line moves, it works correctly. It always happened to me when doing a rapid into a 3-axis helical move. The instant the third axis (Z) started up, the third axis servo would fault, as it was being asked to accelerate at some horrendous rate. It has nothing to do with the precision of the math. The algorithim being used simply does not handle that case correctly, and it expects the third axis to essentially accelerate instantly to what rate is required.
Regards,
Ray L.
-
Hmm, that makes sense, but if the only problem was acceleration, then it should put out the correct number of pulses, just very fast and it isn't. I put a nice counter on the Z axis step line and did a helical ramp and the count value was consistent but wrong. I would also think that in the case of an acceleration bug, it would "skip" steps only during the initial acceleration and I see consistent skips throughout the entire path, for example during thread milling.
During normal linear movements the counter indicates that mach is dead nuts accurate, during a helical ramp with all acceleration set to very safe and identical values, it is off by a thousandths or two, with acceleration of the ramp set to a different value, it has massive problems... surprisingly, if the arc center is (0,0) it behaves itself which is why I never caught the problem before starting a production run.
-
That's very odd.... Perhaps yet another bug.
On the plus side, I did hear from Brian today, and sounds like v4 is coming along, and may finally be out soon-ish.
Regards,
Ray L.
-
Any update on this issue being solved??
-
Any update on this issue being solved??
AFAIK, it hasn't been touched.
-
Hi Ray,
Brian is pretty busy these days, but if you send him a reminder email about it every now and then I will also throw reminders his way.
-
Well.... It no longer affects me. At the time I was using the knee on my mill as the Z axis. I've since built a quill drive (and the knee is used only for tool length compensation), so X, Y, and Z now all run with the same velocity and acceleration, so I no longer see this problem.
Regards,
Ray L.
-
I have a stepper system and I've been dealing with this problem for around 3 years. Never found a solution. The only workaround I have found is reducing feedrate to the point where it doesn't lose steps. In my case, I have all accelerations set equally but the problem is still there.
Would be nice to finally find a solution. Every other code runs absolutely flawlessly except the cases refered in this topic.
-
From reading the topic it seems the best work around is Exact Stop.
However, if you email support@machsupport.com so my counter parts and myself see the email I'll see what can be done to get this moving.
-
Thanks, but exact stop mode is not a practical option for the kind of work required; both in work time and finish. I'll email.
-
Checking back in to harass ya guys that exact stop is not a solution :)
In fact helical ramp is critical to speed! I haven't been able to recommend mach to folks because of it.
Basically it kills thread milling, advanced troichiodal milling, cutting out reflectors, etc.
Please fix it as I'm forced to use software that has subpar user interfaces because of it.
-
Just a note this is fixed in the Dev version..
-
Wow... Does that mean the one thats currently out? Mach3 R3.043.058?
If so, you guys are moving to my new happy list.
-
Yes.. There was some work done to CV.. If the code I worked on didn't fix it please feel free to contact me off list and we will see what we can do to make it right
-
[quote ]In fact helical ramp is critical to speed! I haven't been able to recommend mach to folks because of it.
Basically it kills thread milling, advanced troichiodal milling, cutting out reflectors, etc.[/quote]
Odd. I have been using helical cutting and thread milling with CV for ages with the lock-down version. No problems at all.
Cheers
-
Brian,
Will you elaborate on the changes made to CV in .058? I don't recall seeing this discussed anywhere, but may have missed it. I ask because I'm using .058 and M10/M11 commands with my small laser diode machine and noticing some problems with incomplete lines and circles in some cases, but haven't yet been able to fully diagnose a cause
Thanks,
John Champlain
www.picengrave.com
-
Test it out on a sample code and it worked! Here's to crossing my fingers that the problems gone forever!
Odd. I have been using helical cutting and thread milling with CV for ages with the lock-down version. No problems at all.
Cheers
That would depend on your definition of ages! Also, you might not have noticed! The errors accumulated slowly. I only noticed when I was doing a very precise cut on a reflector mold!
Last time I tried it was 5 or 6 months ago and it still didn't work. If you look at when I posted, and the rest of the thread you'll see that the bugs always been around!