Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: faby on November 15, 2006, 07:42:46 AM
-
For Brian,
May you explain what these new cv features do exactly and how it works?
I add a picture that shows what I mean.
Thank you
-
This will tell Mach 3 how far back to start the blending from one move to the next... It could be less but will never be more then that.
Is that any help?
-
OK,it seams to
I tryed to change the "stop CV on angle x" but nothing change or so it seems.
-
Sorry for my errors in last reply... I'm working too much :(
-
No problem! I think that I should do a video on CV at some point... that has been a question that I have had many phone calls over ...
-
That would be great Brian!
-
I second that, I have it working pretty well by trial and error but getting the de-facto scoop would help.
Chad
-
I'm sorry, but this CV stuff has come to a head today. :( I've tried to find a setting(s) that would work, but the only thing that makes it cut the part as drawn/toolpathed/intended is to pretty much shut it off on one part of the cut and then turn it back on later. With "Stop CV on Angles <" it would cut a pocket as intended, but then the profile pass is herky jerky. The profile pass has no sharp corners, just straight segments and arcs. It wants to pause at the beginning and end of each arc then. So, ya turn that off and keep CV on, then the pocket gets rounded no matter how much you play with the "Angular Limit". A higher or lower CV feedrate eventually just turns it off or on. Higher or lower acceleration makes little difference. If anything, lower acceleration makes it worse. I would think that if your accelerating/decelerating at a longer distance at a slower speed, that it could make a sharper corner. If you turn up the acceleration, you can start slamming around.
Going into the file and turning it off and on isn't an option, especially on large files.
Granted, woodworking isn't as precise as metalworking, but how do you metalworkers maintain accuracy on your parts. Surely you don't turn off CV and then let your machine jerk along in stop motion.
Sorry, but after having to repair ten parts that need other parts (yet to be cut) to fit into them, I'm a little warm. Maybe I've just got too much wood in my furnace ;)
-
You might try increasing the acceleration distance a bit, this might help blend the decell/ accell and you could then use exact stop.
-
It is the time to accel the axis that is the problem :( With an accel of 15.00 In/Sec^2 it takes .666 sec to get to 600 In/Min.. That is a VERY long time.. Now to blend the moves there is the problem of rounding the corners and so on.. the lowwer the accel the more rounding you are going to get.
What do you have your CV Dist set to?
thanks
Brian
-
Hey Brian,
I was set at 780 velocity, 13 acceleration, and a feed speed of 120 in/min. Because my screen set still had angular limit CV, I was still thinking angular limit CV and tried starting from a high of 180 down to 10 with little change and 0 gave basically a stop mode situation. With CV feedrate on, there wasn't really much of a sweet spot to be found.
I see that CV was changed from angular limit to distance tolerance. I found some info on the Yahoo forum about setting it to 0.10. That's about as low as I can go before it may just as well be set to exact stop mode. I air cut the file that I was having problems with and at 0.1 you could feel that it was on the edge of hesitating between G1's and G2/G3's that needed little or no slow down. A angled YZ from one level of a pocket to the next level was starting to get like this, - - - - - - - (on a downward angle of course). It would get smoother if set at 0.12 or higher, but I couldn't tell if there was corner rounding happening. I'll have to run some more tests.
If you have a pocket that is cut from the inside out with the transition from stepover to stepover happening at the upper left corner at a 45 degree angle (Vcarve Pro pockets in this manner), and the pocket was drawn square cornered as intended and cut with a 0.375" cutter, the upper left corner will alway be a 0.1875" radius while the other three corners will be of a larger radius. If the transition from stepover to stepover is on a side and you choose to not have a final pass, there will be a radiused bump on the pocket wall. I will again have to try this with the CV distance tolerance set around 0.10 - 0.12 now and compare. I've also changed my screen set to reflect the change.
On the subject of changes in the software, could it be that after an install/update, that you could be given a choice of reading a revision history document that would alert you to any changes that may not be evident if you have a custom screen set?
Thanks,
-
There are doc's from time to time that pop-up to show you what we have changed... The best thing to do is if you are haveing a problem is to post on the forum or wait for the doc's. John is a great guy and I have no idea how he gets all the info into the docs!
-
I can see that CV is going to be the bane of my existence. As far as I can see, if you want accurate as drawn parts, turn it off and live with a machine that hesitantly steps along through each line of code, overheating the cutter and leaving dwell marks due to each stop. Or turn it on if you want a smooth running machine (the reason for switching to a different controller) and throw accuracy out the window.
The more you adjust down to get corners better, the more you make consecutive straight line segments turn into stop and go movements as well as flowing G2/G3's.
Is it not possible to make it ramp down as it comes up to corners, make the corner as posted, and then ramp out of the corner getting back up to speed without a hesitation at other straight line segments and flowing arc segments. I don't make this next comparison with any implied "this one's better than that one", but if the makers of my old controller could do it, I know that ArtSoft/Mach3 can do even better!
-
Brian i agree that we could use a lesson in cv. I have started doing 3D contours in earnest and i have been struggling with the cv settings. I have found a "sweet spot" of between 180 and 220 ipm. Anything above or below and i get the hurky jerkys. I have to turn off the cv federate in the settings page or else i get jearkys but then corners are rounded. I realize that this has a lot to do with my accel - 20 but i have a 1400lb gantry and just cant whip the machine any faster than that. Any suggestions?
Chad
-
> Is it not possible to make it ramp down as it comes up to corners, make the corner as posted, and then ramp out of the corner getting back up to speed without a hesitation
I use step-four driving software (www.step-four.at) from about 6 years and it does this, not in a good way however, because in some cases it doesn't ramp down at high speed and it loose steps... oops.
It's why I passed to mach3, because it's better in cv mode, but the rounded corners are a big problem.
I know it's an hard thing to do in terms of code writing, but I think that is good time to invest in.
I don't know how it's working now but I think that a plausible way could be to look ahead about 80/100 lines and analyze the direction vector, so slow the speed down smoothly near the corner over x degrees (as Scott says), as much as the cv algorithm could maintain small round on that corner...
Ehm... I hope you can understand what I want to say, the language differences are a bad things ;D
This is only and idea, maybe it is not a good thing :P
Faby
-
One way to possibly eliminate corner rounding is to use cutter comp, which gives a toolpath with radius corners while still cutting square corners on your parts. Or create your g-code with the corners radiused the same as the tool radius, which will give square corners on your parts. This works better the larger the tool is, and for outside corners only.
-
Brian,
What would a decent acceleration be?
Regards
Fernando
-
I am running 65in/sec^2 with a max feed of 500 IPM :) That is a bit much but I should hope that it is about 30 or so if you are going 500+ ipm
If you are running a slow machine you cen run down to about 8-10 with a max feed of about 100IPM
That is what I have seen work for me :)
-
Hi Guys:
I heard of the activity here and thought Id poke in and read up a bit.
I think we may have several things going on. So lets discuss CV a bit so we're all on
the same page. Its best if we all understand what happens in the various CV modes and a bit about why a cv works at all..
First, why have CV. Well, you know that one. doing 100 small moves in a line woudl be pretty nasty if they didnt join together
into one path. The problem of course is corners. So lets discuss that first, since most problmeatic jobs involve thousands of them.
We're fighting physics here. Plain and simple. If you drive down the street and have to make a corner at the end, there are a few ways to
do it. First, you could floor it all the way, but your likely to have a pretty round corner. Probably into the house on the corner.
Second, we could jam on the brakes at the end of the street, and then turn thw wheel, but we'd skid quite a ways (skidding is losing pulses here.. :) )
Or we can do what we all do, slow down, turn the wheel and quite often, anticpate the turn by turning as we slow. Mach3 kinda does this, but allows for any of the
last two really. But to show that , I need to show it to you visually.. No machine required..
First, makeup a Gcode file with
G1X10
G1Y10
g0x0y0
m30
Load it up and you can see the rigth angle lon the right of the screen. So lets test some things..
First run the file with F100 in he Feedrate box. Note the amount of rounding. Now run it at F600
, more rounding? Lots more? Some of this will depend on your personal accel settings, so you may have
to use different feedrate. Turn off CV tolerance and angular check for this.
So if you experimented with a few runs of this at various speeds, you'll see exactly how Mach3 blends,
as the X starts to slow, the Y starts to accelerate. Mathmatically, this makes the best join at the feedrate
you requested. If you didnt notice an asymetry, then your accel is the same on each axis. Use motor tuning to
slow the Y acceleration down a ways. Try it again, see how the Y is now not symetrical ? Think about the way
as one slows the other speeds up and youll see the math behind the blend. Notice the much less rounding at
various speeds. Pick two, say 100 and 600, and take special note of the difference between them.
Now use general config to set a CV tolerance of 1.
Run the two test again, do they look the same? (They kay or may not depending on your feedrates). But youll notice
only the last 1" is rounded ont he X side, the Y will depend on its accel in the X decel time of its last inch. The CV distance then,
is telling the system not to start blending until we are a set distance from the end of the move. This also translates to a lower
feedrate point at which it will start blneding, hence a lower amount of deceleration time in blend, thus less rounding..
OK, now try config/general to set an angular check of 89 degrees, run the test, no rounding at all , right? Because the
right angle is more than what was set , set the angle to 91 degrees and full rounding will appear because the allowed cv angle is
greater than the 90 degree change at the end of the line. Play wth the accel settings, without changing velocities to see some of the effect.
The thing you should notice is the faster you get in the segment with your F move, the more rounding will result unless corrected by distance tolerance.
Since distance is a function of velcoity and tiime, another way of thinking about distance tolerance, is the speed at which blending will begin. Thats basically
what it affects..
Running a few games with that simple file will allow you to fully visualise whats being done.
I saw above some suggestion of analysing vectors to determine when to slow to get to full speed the fastest, well, thats exaclty whats being done, if you analyse
that to the end, youd find that basically means blending the two moves together in one way or another to smooth the transition of one vectoral velocity into another.
Mathmatically, Mach3 does this very well, as it actually shows the vectorral change as a circle on the corner which is what such a functions waveform SHOULD look like.
All that being said, corner rounding is a problem, very frustrating and annoying. One afflicted with it wonders why more people arent upset with it. Its a function of power.
The more power you have, the less you see it. My Mill would need micrometers to see any rounding, as the acceleration is always maxed out. This problem afflicts those with
heavy gantries, with not enough power to push them. Generally, if it takes a second to get up to speed, thats a second too long from a physics point of view, I mean if acceleration
is infinite, then no blending is necessary, the Y would be up to speed instantly as the X stops instantly, thus no blending is required. Its a sliding scale downwards from ifinite acceleration
,the lower the acceleration, the more blending of velocities is necessary. Its the difference of driving a sports care around the corner , or a mach truck.. one slows more than the other ,
and rounds the corner more..
OK, dont get upset yet, :), I m not picking on your power. I just want to make sure we're all on the same page when it comes to CV and what it does, as well as how it does it. And
why your type of systems represent so much more of a challenge. We need to understand all this because Im getting undercurretns of perhaps other things going on with this type of
problem. Someone mentioned I think that when their motros were going in a certain range, they sounded good, in a lower range, they sound bad. Thats bad. Shouldnt happen. Its
a suspicionof resonance, and if it is resonance, it can really mess things up when your on the edge of performance already. So if its your system thats doing it, you need to run some tests..
G1X10F10
G!X0F20
G1X10F30
etc..
Where is the sweet spot, better high, worse low? better even lower? any particualr speed bad, if so, you need to dampen some vibration, may change the pinion arrangement,somethign to steady
things up a bit, resonance can be a nasty thing that takes away smoothness no matter what you do..
OK, but lets say it isnt resonance. Its just CV , and it drives you nuts. (It has driven me nuts before..never did recover..). Notice form the test we did above, that without changing acceleration, the rounding is
less and less the lower the feedrate the run is made at? Theres a key there thats important. Lets say for example, that we're cutting the roadrunner test file. I command 1000IPM, it runs at 60 or so. The reasonit runs at 60 or
so instea dof 1000 is that there is never an opportunity to get up to 1000. By the time it starts the accelerate, it has to decelerate. So it never reaches 1000. SO we're safe to set th efeedrate at 500 right? I mean its only
going to reach 60 in any event? Not a good idea. What happens, is that it actually reaches higher velocities in the middle of segments so it needs to decelerate sooner than if trying to go slower, so the rounding effect grows
exponentially with the higher demande dfeedrate, even though yourr average feedrate will be the same as a F60 to run the file. I guess hwat Im trying to say, is that not only do you have a feedrate you want to maintain
for a given chip load on your tool, but you have to understand there is a phsysical based feedrate limitation based on your tables accel and vel settings, and that if you exceed that physical limit, the CV will not act very good for you at all.
Thoise with high acceleration in their system can demand whatever they like from a file, they may get it, they may not, the file will limit the speed in the end, a feedrate is only a maximum speed, in most hard files the tools ends up
goiing much slower much of the time. So demanding a file run only to the limits of your systemns ability will sometimes make differences in orders of magnitude of the performance. Now thats for complex files with hundreds or thousands
of segments were talking about there. If you simply cutting squares in wood, then its different. Nope. Even there slowing down the requested feedrate will make big differences in the rounding. Depending on how your settings are,
it can go al ong ways to fixing it. Many play with accel, angualr, CV dist..etc.. and never slow the commanded feedrate int he file down. But feedrate has the greatest contribution to the problem. So slow down. Youll
usually find a speed where it actually seems smooth in the corners with little rounding. Thats the real, true cv limit speed of your gantry or machine base don your velocity and acceleration. CV distance, and angular rejection
can help you command somewhat higher speeds than that, but Id find that natural spot just so you know what it is. If its 5IPM, then you know that when you go over 5ipm, your gonna have to add helpers like cv distance and such,
or add another motor, or get a bigger one for that axis... :)
I am continuously experimenting and trying to makie better CV algorithms, and technology slowly catches up. This is a very complex area though, I wont bore you with the technical detaisl of what CV takes and such, this has been long enough,
but I hope the suggestions help, le tme know if you see any anomolies that my explanaion does seem to jibe with. Im always on the lookout for bugs in this area, but I haven tseen any so far. I hope to be able to make it better as I go,
but I cant say I have any brainstorms at the moment to make this better, other than the suggestions above. Now thats Ive posted on this one, I'll be notified of any additions.. :)
Later,
Art
-
So is this a problem that is isolated to Mach3? or do comercial controlers from big companies like fanuc have to tackle this problem too?
regards
Fernando
-
Fernando:
Its actually worse on some , better on others. For the better ones its typically because a Fanuc machien woudl have 1.5KW axis motors. They have very high acceleration for their weight..
Art
-
Thanks for the information Art! I'll digest this, do some more experimenting, run some more parts, and after I digest some turkey ;D, I'll come back and post my findings.
Thanks again
-
I found this on another site referring to G61, G61.1, and G64....
Path Control Mode
The machining center may be put into any one of three path control modes: (1) exact stop mode, (2) exact path mode, or (3) continuous mode. In exact stop mode, the machine stops briefly at the end of each programmed move. In exact path mode, the machine follows the programmed path as exactly as possible, slowing or stopping if necessary at sharp corners of the path. In continuous mode, sharp corners of the path may be rounded slightly so that the feed rate may be kept up. See Section 3.5.14 and Section 4.3.5.3
The canonical machining functions share with the RS274 language the simplifying assumption that machine dynamics can be almost ignored. That is, in this model, acceleration and deceleration do not occur. Components of the machining center can be told to move at a specific rate, and that rate is imagined as being achieved instantaneously. Stopping is also imagined as instantaneous. This model obviously does not correspond with reality. The control modes provided here provide some compensation for this lack of consideration of dynamics.
What would G61.1 (exact path mode) be in Mach3? Would that be the CV distance tolerance with or without CV feedrate or is that an unsupported G-code?
Thanks
-
Ok, I'm back again, after two very frustrating days of lost production dealing with this issue.
I understand all of what you stated below Art, but I can't seem to come up with that magical combination. I have hundreds of files that I will eventually need to convert from .sbp (ShopBot) over to G-code. These files were drawn as they were intended to be cut with the radius of the bit in mind. The only way they're going to be cut that way is to run them in exact stop mode which simply won't do. There are many short line and arc segments involved in most of them. Many of them get an item placed inside pockets that need to be the right shape or else things won't fit.
CV on, acell up (15, tried 20 and won't again), feed at what I used to cut that at before and I get to much shake/bounce after the stop & go resulting in poor cut quality and some rounding.
CV on, acell down (10 - 13), feed the same, more rounding less shake.
Feed set slower with both the above, not much change in the rounding but now the chipload is in the basement.
CV on, acell the same, CV distance tolerance at 0.1- 0.12, the rounding is better, but small rectangular slots are still rounded rectangular trapezoids (one corner is fair and the other is rounded off more. If the feed is kept up, it runs smoother, but if feed is lower, then it starts hesitating at each segment again (back to what acts like stop mode).
Angular check on with any setting (90 thru 180) makes it hesitate at all segments again. If there's a line segment with a shallow flowing curve and maybe another curve in the other direction that really needs little to no slowing, it hesitates at each segment. Take that same right angle in the example below and instead of going straight back to X0 on an angle, make it a shallow flowing "S" going back to X0. Now, my Cam program makes that out of a couple of arcs and a couple of small straight segments. With CV on and Dist Tol off, it flows along smoothly. With any angular check setting, you get a stop and go situation. With Dist Tol on and angular check off, you can make it hesitate again with too low of a setting.
CV feedrate doesn't really do anything accept cause hesitation (low setting) or is like it's turned off (higher setting), still don't know what to think about that.
I know that the older ShopBot machines have lighter gantries and are prone to some shake across the Y axis which is why I can't run at real high accel settings. If I run with lower feedrates, then the cutters will wear out prematurely (chipload too low).
What we need (ShopBots converted over to Geckos) is an Exact Path Mode with a variable feedrate. Decel into the corners and acell out of the corners over a certain distance at a certain speed with a slight slow down at gentle curves without hesitation at each segment.
I want my cake (Mach3) and to eat it too (Exact Path) don't I :)
In the past I have done some inlay and I'm sure that the time will come again when I want or need to. Is there anyone that has done inlay with Mach? How could you possibly accomplish it? Not with CV on and with it off, you would soon smoke your tooling. Maybe with a high acell and a low feedrate? I'd get the shakes if I tried that.
Maybe I need to buy some kind of a big behemoth cnc router that I can cement right into the floor. NOT :P
Thanks for listening to another rant, sorry.
-
Download the newest version and see if that helps you :) There is a little bug that Art found and I think it may help you.
-
Hi Scott:
>>>What we need (ShopBots converted over to Geckos) is an Exact Path Mode with a variable feedrate. Decel into the corners and acell out of the corners over a certain distance at a certain speed with a slight slow down at gentle curves without hesitation at each segment.
Yup, thats what I get. :), thats what CV does on a system that can stand acceleration.. I do think that that the Bug brian mentions may have been affecting you very badly, try the latest version.. We'll be interested int he result..
Art
-
Scott:
By the way >> (1) exact stop mode, (2) exact path mode, or (3) continuous mode.
Mach implements 1 & 3, #2 was never implemented. Thats a quote from EMC and in EMC, exact path, though documneted, was never written..
Art
-
wow I'm glad that my topics are so ensue... :P
I'll try the latest version too, because I'm so interested in something like "exact path mode".
Faby
-
This new version is better than before, and now the "stop cv on angle *********" function works.
I played with CV distance and max cv angle value and I found a good quality
I think that an hypothetical "exact path mode", cuold bring mach3 in the best choice for all, as me, mill 3D objects for mold industry.
Fabiano
-
Ok, sorry it's taken awhile to get back to this, it's that time of year again. ;)
I'm not real sure if it's better, I've been running some different parts lately and it's harder to tell with these. One thing that I have noticed is that with a CV Distance Tolerance setting of say 0.10 and a feed of 100, a toolpath may execute fine, but as you take the speed up a bit, it will start to hesitate between segments again. If you turn on stop on angle, then it will always hesitate no matter what the setting for the angle. Take for example the right angle talked about earlier and add a "S" shaped path going back to X0Y0 with a couple of line segments at the beginning, middle, and end (Attached sample file). The return path in the file really needs little or no speed adjustment, depending on how fast you're going. If I ran this with CV on and no distance check, it runs fine. With CV and a distance check of 0.12 at 120IPM, it runs ok. Start raising the feed and it starts to hesitate between each line and arc segment on its way back to X0Y0. Throw in a angle check of 89 and it stops CV at the right angle, but also still at each line and arc segment. If CV distance is unchecked and angle is checked, it doesn't matter what you put in for a value (89 -270), it will hesitate again at each line and arc segment.
What I'd like to be able to set for the many varied size and shape pockets that I make for law enforcement badges and guns, is to be able to set a distance tolerance of 0 (exact path), a low accel (no banging in and out of corners) and still have smooth non-hesitant motion between the sections of code (G01 to G02 or G03). Many times I have to have a rectangular pocket within the main pocket and they were intended to have a radius the same as the cutter to allow for clearance for some part to drop into. These are getting cut (with a low distance check) with a larger radius on one side of the end of the rectangle (due to rounding) and a close to normal radius on the other side, making what I can best explain without actually drawing it, a radiused trapezoid rectangle. :(
On another note, correct me if I'm wrong cuz this may just be my dyslexic mind ::), but on the "General Logic" page where it says "Stop CV On Angles <", doesn't that mean less than? So If we have an angle of 90 degrees and a setting of 89, it shouldn't stop, but if it's set at 91, it should.
-
Ok you two, now you're just messin' with my head! :D I see you turned that less than into a greater than for Stop CV On Angles! The operator or less than sign wasn't the problem, it's the way that the numbers are being handled. A 90 degree angle is less than a 91 degree angle so if I have a setting of Stop CV On Angles < (less than) 91, it should stop. If I have a setting of less than 89, it shouldn't. By changing the sign to > (greater than) you're saying to stop on angles greater than say 90 on up to what, 360...? It needs to be the way it was (less than) and the handling of the values should be reversed. ;)
That aside, with my sample file below, with any setting for angle, the machine basically acts as if it's in exact stop mode. Depending on the angle setting, it may or may not stop CV on the 90 degree angle, but it always hesitates at the transition of the G01's and G02/3's. Also, with Stop CV On Angles unchecked and CV Distance Tolerance checked with a value of 0.1, as you raise the feed speed, it starts to hesitate in the same manner. This will happen on files other than just my sample.
Regards,
-
I have been thinking about this problem that you are having and I think I know what it is... It is the acceleration that is your trouble but the more accel that you have the more you don't like the axis starting and stopping... it is not "smooth". If you take the derivative of acceleration it is known as "Jerk"... this is known as jerk because it is the change in the Rate of change... What the heck is that! you say... Well if you look at the graph of mach3's accel it would look like this:
-----------
| |
| |
The vertical walls are telling us that we are getting very high Jerk and will get a shock into the machine when we start and stop a move. The worst would be to Reverse direction!
You would like to see an accel that looks like this:
------------
/ \
/ \
This will make for a move that will not give the sharp shock into the system.
Now for the bad news :( there is nothing that we can do at this time to make this work for you... You need to have Scurve acceleration to get the jerk out of the system OR you need to have more mass to stop the shock (can't be stopped as fast, and is not a good fix). If you were running a Galil we could use the S curve accel in it to smooth out the accels in your table, but that would be about 1200.00 min to get set up :(
Just wanted to tell you where I think you are getting the problem from.
Brian
-
Cant the S curve acceleration be implemented within Mach?
Best regards
Fernando
-
Brian,
I'm not sure that we're on the same page. At least I hope not.
If you take a look at the attached jpg and see the red and blue segments of the toolpath, they each represent one line of code.
Here's the senario;
CV on with Distance Tolerance unchecked (off) and Angle limit unchecked (off), run at 120ipm and 150ipm. Motion is just fine. Albeit with some corner rounding (understood).
Next, CV Distance Tolerance checked and a value of 0.1 applied. 120ipm runs okay and 150 ipm hesitates at each segment (red, blue, red,.....) If you raise the Distance Tolerance value, you can get to the point where it doesn't hesitate, but you have then negated the limit on corner rounding by raising the value.
Next, CV Distance Tolerance checked or unchecked (doesn't make a difference) and Angle limit checked with a value of 89 (again, it doesn't matter what value you put in there except for the 90 degree angle in the toolpath), it will hesitate at each segment again. Feed speed makes no difference here.
Why do we need to stop at each segment? The angle isn't acute by any means and there's little to no need to acel or decel in this situation. Now if I have a lot of small curves and segments back to back, I can definitely see the need for ramping the speed up and down as it goes through them, but not to hesitate at each line ever unless you have chosen to run in Exact Stop mode.
I have also noticed that V-carving is affected by corner rounding and running a v-carve file in exact stop mode is something that is impossible.
I don't know how I can describe the situation any better and I truly hope that we aren't talking about the same thing, just in different words, because if we are, for a great share of my work on my machine, Mach will become unusable. :-[
Regards,
-
yup we are not on the same page but we are looking at the same problem... You need to run a heigher accel to get closer to the path in CV mode BUT your router can't take the "jerk" that is being devloped by the acceleration (makes a gouge form deflection). The CV distance mode woudl work for you if you had a mill type machine that had mass and a good amout of steps per unit. I wish you could see mach 3 run a mill becasue it is SO smooth.
Brian
-
Hi, Scott
Would you post your Steps Per, Vel. and Acceleration values.
I have read some of the posts hear and have had some simillar issues early on.
Your values I read were vel 780 acc. 13.
Try setting your Vel to Max speed just where you start to miss steps then back it off some.
Then set your acc. to as fast as you can from a dead stop to missing steps then back this off some also.
You can set the speed to lower than your Acceleration start speed with your F settings, or over-ride.
I had this problem with a Water-jet cutter being Jerky also this smoothed it out, dual overhead gantry.
Give this a try let us now.
Thanks, Chip
-
Thanks, I'll check into it more tomorrow, but right now I'm pretty sure that my Steps Per are 1834.864039 for XY, Velocity at 817.2 (the top of the scale for 25000) and the Acceleration has been tried at 13 to 15. 15 makes it more crisp, but also gives a aftershock that will leave ripples on any edges that are affected by it.
I have been able to run as high of a velocity as it will go at the 35000 setting, but that seems a bit fast. I have run for quite a while with it at 840, but then out of the blue, it will loose steps big time during a jog with quite a bit of racket as things try to catch up. I'll get everything reset and it will be fine again for another day or two before it happens again. So I just set it back down, but it has happened at the lower setting too. Seems like something all of a sudden causes the loss and then is gone for a while again, making it hard to pin point and find a setting that I can set and forget. :( I'm running a slightly overclocked Athlon XP 2500+ with 512 ram.
Regards,
-
Hi, Scott
I looked at your sample.Tap File, It dosn't have a F value set for your G01, G02, G03, so there running at 100 % speed.
Do your other files have F speeds in them. ?
Could you post an actual file your having problems with and describe your machine in a little more detail, stepper-servo, size, photos.?
Thanks, Chip
-
Hi Chip,
Sorry for the delay here. My machine is a six year old ShopBot PRT96 (48" x 96") with Oriental Motors 3.6:1 steppers. The gantry is relatively light and does flex or wiggle in the Y direction, thus the difficulty with high acceleration. I've done some modifications to stiffen things up, but it needs to have the X car reinforced or redone in order to stiffen that up and probably a second Y motor on the opposite side.
I just stripped the Z moves and F values from the sample file and just manually set the feed rate up and down.
Here's one of a number of gun box files that I have been running lately. This particular one gets the rear site notch rounded out and the muzzle end also get the detail removed while a sharp corner at the front of the grip is just fine. High acceleration makes the the direction changes too harsh. Adding in a CV distance of 0.1 is about as low as I seem to be able to go without Mach stopping at each line of code like it was in exact stop mode and still rounds corners. I don't understand why we have to hesitate between two lines of code that need little to no ramping between them like along the underside of the barrel and the back of the handle (these hesitations just introduce more vibes). A stop CV on angle limit of any value just results in an exact stop condition and an overheating tool.
The attached photo is the same gun, just a different type of box. This one was done with my old controller. I wouldn't even attempt the design on the cover at this moment, in fear of it rounding out every detail, even if it's just a scratch path on the line.
V-carving files seem to need another whole different setting that I haven't found yet. :(
I've come to the point where I don't have time to fart & fiddle with it anymore and just need to get stuff done now. I'll have to do some machine modifications after the holidays and hope for something closer to exact path w/ramping, like I've been used to, in the future. ;)
Regards,
-
Hi, Scott
Thanks for the photos nice work.
As far as the problems go, I didn't mention.
Have you try-ed setting the LookAhead value down in Config. General Logic.
Setting the Step & Dir Pulse up some in Motor Tuning, some stepper cards need this.
Change the Dir & Step Low Active to opposite state in Ports & Pins, Motor Outputs, some stepper cards need this also.
You can Reverse Axis Direction in Home & Limits page (Reverse box), Its really the proper place to do this, well in My opinion.
May-be one of these will Help, Chip
-
I need to UP this post because everything Scott said goes doulble for me. We have run test after test with Exact Stop On, Exact Stop Off, CV values all over the map, Look Ahead set low and high,...everything that Mach codes for. The results are still inaccurate cuttiing. We have the feed rate override (which really should just be called Override, as it also controls the Rapid move (which is not good >:()) set at 100% or less all the time.
Judging by the lack of response when Scott asked about inlays, I suspect that no-one using a CNC router with Mach has had enough accuracy to achieve this (which some would consider basic) application. Anyone?
V-Bit carving and 3D also experience the rounding problem. This is not just a 2D phenomenon.
I feel bad for Scott, and I don't know if it was clear from his last post that the images posted were not made using Mach.
Physics lessons aside, is there any light at the end of the tunnel here?, because we are running out of track!
-
First off... I think the feed rate overide only affects the FEED rate not the rapid in the later versions of mach.
second, rounding is present in all machines, as Art stated, fanuc, mach and other machines capable of constant velocity. the thing is, most machines that do not have this problem use big enough servos to handle scary accelerations which make rounding a lot less. If you do not use constant velocity you SHOULD NOT see rounding.but maybe your machine is too flimsy that when it stops it wiggles a bit and and bad cuts are seen. if you set your acceleration way down, I mean WAY down, and use exact stop, im sure you wont see this, but then again, cutting times will go way up. so it is basically a trade off situation if your machine cant handle this shaking.
As for light at the end of the tunnel, well there´s QUANTUM, which is a whole new approach to things, which in my opinion is the way of the future, and I am sure there are not many controllers taking that approach.
Regards
Fernando
-
Kree,
To get the FRO to not change the rapid rate please check the box that Is in the pic. You need to know that if you are doing long moves the FRO is going to take longer to work...
What are you running for a table?? I have an idea that it is a table like a shopbot and you should try the test version of Quantum and tell me if it makes your machine run a bit better... you will need to put in a value of about 1000 in the Jerk amount under path smoothing. Also you will have to double you accelerations...
BTW I know who you are now and I can tell you that quantum will fix the problem as I used your old test file to check quantum :)
Hope that helps
Brian
-
Thank you Brian,
Quantum is making a signifigant improvement, and I am pleased to finally learn what No FRO on QUE means!
What kind of timeframe are we looking at to get a version of Quantum up with no limit to line numbers. Testing 3d is a bit of a challenge otherwise.
-
Use your Mach3 license and you should be able to run a program as large as you like ;)
-
Brian,
Thanks, the licence worked.
2D files have improved dramatically. Corner rounding is just about eliminated with Quantum. Speeds, and acceleration is way more than twice as fast now.
Funny thing though...
Now 3D files barely reach 5% of feed. Any ideas? With Path Smoothing, does it matter if you are in constant velocity or exact stop? So far testing reveals no major differences.
-
At the risk of dropping completely off the bottom of Art and Brian's Christmas list, I'll step back in here. ;)
Kree, I just pretty much settled on a compromise of rounded corners and poor V-carves and hoped that the customer didn't have a problem with it. I just did the best I could. I got tired of spending a half hour test cutting to only have the same results most times. The larger the V-carve design the better. Smaller ones with sharp corners are worse. So I'm sitting at the end of that track waiting. ;)
Brian, I have found that Quantum is better with mainly longer linear moves and not a mix of shorter G01, G02, and G03's. The type of files that I need to run act as if I have exact stop set. I have run the gamut of the range of settings for "Max Jerk" with the only change being how fast the file runs. I sent two files to Art a while back that exhibit this and I'll attach them here if anyone would care to try them. Are these type of files (short straight and arc segments) to be considered the same as short 3D and V-carving types and therefore not optimized yet?
I'm able to almost double my acceleration settings, but because of the jerk setting not being applied to rapid moves, if I get too high it will loose steps on take off. :o Will this eventually be applied to rapids also?
Regards,
-
Hey Scott been testing your file, there's a couple of things I would like to try if you would send me your dxf for the 150 profile
I don't seem to have the problems your having, just finished some 1" v-carve text and it ran as smooth as ever.
gary
-
Hey Gary,
Here's the dxf. This file was made in Vector by selecting the outside ring of leaves (in consistent direction) and creating a 0.75" offset to the outside. I then keep the outer profile and delete the stray inner parts of the profile. At that point, it's already "Arc Fit".
I find that some v-carve stuff works ok in Quantum, but the next one will run hesitantly and slow or fast depending on the setting.
Thanks for looking.
I should add that this file runs fine in Mach3 (unless you add in too much CV Tol), but not in Quantum. The gun runs fine in Mach3 (albeit with rounding), but won't run smoothly in Quantum.
-
Hi Guys:
Just a note as I run by...
Many will ask why Quantum slows down some 3d files to very slow.. Heres the reason..
In trapezoidal accel, there is a finite time that acceleration takes to get to speed, with Jerk correction,
this time is increased. Though you can tune for faster accel, the accel as a % of total time of move is increased
by up to 200% or more. This doesnt affect longer moves. However, very small line segment 3d files will
never get to get up to speed before having to decelerate. All move, not matter how small must accel, then decel.
Quantum will attempt line concatenationnext to speed up those moves..
Glad to har its working well for many of you, we worked very very very very hard :) on its implementation,
but remember, its alpha code...
Thanks
Art
-
So....
Are there any settings people that need to cut 3D (or V-Bit) files use to get Quantum?
Is there a happy medium between 3D and 2D optimization?
-
Thanks for the inside Art, and of course thanks for all the hard work you guys do to kept us belly acher's happy ;)
Scott, I believe a lot of the problems you are experiencing is due to the way your drawings are created and converted. When I looked at you drawing there was a lot breaks in your vectors which was at every place it paused and acted like it was in exact stop mode.
I corrected your vectors and re toolpathed using the outer vector cutting to the outside with 3/8" mill in 2 passes. There may be a small difference in size from your original as I did not go through offsetting etc.
anyway air cut this file and see if it runs better for you.
Run: CV On and all cv controls on the config off, also make sure you have "no fro on queue" checked.
gary
-
Thanks Gary, I'll give it a whirl, but I think that the breaks must be due to some dxf issue between us because I have no breaks showing in Vector and the path selects continuously into one chain. What I sent you was a recreation of the original Vector .ccd file. If there are breaks in it, Vector won't select it as a continuous chain. If there were and I somehow managed to get it all selected, Vector would've create a safe Z connection between each one of them. As I mentioned below, both files run proper in Mach3.
I think that the small arc segments are causing Quantum to act as Art described below.
Art, thanks for your reply and for puttin' up with this belly acher. ;)
-
Scott you maybe right on the dxf issue between us, so out of curosity I ran it through 3 programs Artcam, Visual Cadd and Vector and got the same results broken vectors on all 3 which is highly unusual, maybe it was in the conversion between us.
Vector would not select as complete chain but did select in larger groups than VCadd which I could then group. Artcam selected grouped as one but would not toolpath until open vectors were closed.
if you load your originally posted tap file in to Mach and zoom in on the tool path you will see the change in color of the tool path these locations pretty much matched the vector breaks flagged in AC and the pauses when the file ran on my machine.
Not sure if that helps you any but lets know it that tap file I post works if not I'll do a bit more playing.
-
Hey Gary,
I tried your file and have the same results as my original, just in different places. I don't know what version of Vector you have, but I'll attach the .ccd just for fun. I'm using XT v10 so if you have an older version, you won't be able to open it.
Those changes in color in Mach's preview window are G02's and G03's (purple on mine) and G01's (blue). So it would appear that Quantum is slowing way down at the short G01's between the G02's and G03's
No need to spend a lot of time on this now as I don't have to make any of these at the moment, I was just using them as a Quantum test.
Thanks
-
No won't be able to open, I bailed on version 9.4 of vector and went to AC.
This must be in a setting difference as I believe we have the same motors etc on our machines.
Do you have the same results with both Quantum and 2.040? I will have another play later when i have more time.
g
-
No, this is only with Quantum. They run fine with 2.040, with the exception of corner rounding on the gun box.
I had to run some more of these gun boxes today and I thought that I had finally found a semi sweet spot as far as settings go back in December, but found that I was mistaken. I've been making these for a few years now, and I had the actual gun in hand when I made the first one and knew that it fit just fine back then. Well, I had the same type of gun in hand today in order to make a little adjustment for a slightly different front sight. Other than that, everything was the same. I made the adjustment and ran the gun pocket as usual. To my dismay, I find out now (after making a pile of these before Christmas) that corner rounding has changed the profile so much that the gun no longer fits properly! Same file as in the past, just a different post processor to generate g-code instead.
Man, this is gettin' old! :(
I'm done whining now.
-
Slow down and you should not round as much... You need better accels :( But I don't think your machine could ever take it!
BTW what are you running for hardware? Machine and control hardware.
-
Pretty sure Scott is running the exact same set up as me PRT/Ascension, same steppers etc.
-
Then what the heck is the problem.... Weld your table Scott ;)
-
I am running the same hardware as Gary is. I'm running that gun file at 100 in/min with an accel of 15 and a CV Tol of 0.10. Velocity is 850.2 X and Y. Any more than 15 on the acell and I get too much (for lack of a better term) after jiggle from the jerk in the Y direction.
The table is solid enough, it's the carriages. I've done what I can for reinforcing them short of welding the whole thing up, but I'd rather build a completely new gantry/carriage than have some local sod buster welder come in and make a mess of it. :D
I can get as high as 23-26 in Quantum (maybe higher if rapids were under the same control as feeds), but files like this one won't run for me in Quantum (apparently due to the small segments/arcs).
-
Do I have to use the gcodes to use CV modes?
The reason I am asking is that I set soem of the parameters in config>general config and din't see any result.
-
Hello Looker.
Yes, you will only see the effects while running G-code. You want see any difference while jogging.
Brett
-
Hello Looker.
Yes, you will only see the effects while running G-code. You want see any difference while jogging
Running CV/or not, in a program.......I have to program G61/G64
I do not expect CV features while jogging
-
If you look on the General Config page I am sure there is a setting there to default to CV mode. Sounds like you are default to ES mode.
Hood
-
I am wondering if the new CV feature is what I am seeing. I recently upgraded from the V1.94 to V2.0.064 and I noticed some differences. When I jog my X axis it takes off then slows down then speeds up again. I can see this when I run programs as well but it is still maintaining accuracy. My set up is a servo set up on a milling machine. I see it mostly on my X axis but it does happen on my Y as well. I haven't seen it in the Z. I was also wondering if mabey I needed to retune. To put the problem in perspective it irritates me mildly however I run the machine daily without issue.
Vince