Machsupport Forum
*****VIDEOS***** => *****VIDEOS***** => Topic started by: hanglide on August 31, 2009, 09:21:58 AM
-
http://www.youtube.com/v/rr0DC3R_iNk
-
Looks good. :)
Brett
-
Thanks Brett
Any ideas on how to get the video to embed properly? Never mind- GOT IT!
Thanks
Scott
-
I don't believe that machine is cutting at 300ipm (;-) I have watched a lot of machines run over the years and that is not 300 ipm.
At 300 ipm the machine moves at 5"per SEC
If you look at the first cuts at 100 it takes a five count to cross the block , the 250 it takes a five count, at 300 it takes a five count.
Just because Mach shows 300 does not mean the machine is moving at that rate. I can make th LPT version show the exact same thing.
(;-) TP
-
Terry,
I'm with you on that. When the guy holds the workpiece at the end you can estimate the workpiece length to be about 7". And it takes about 5 seconds to travel that distance, which means a feed of even less than 100ipm. And the feed looks even through whole the process indeed - no difference between 100ipm and 300ipm can be seen.
One other thing I noted in the video is the feed DRO displaying the speed spot on - no fluctuation. Have never seen this in Mach3 neither with PP or SS. Mine always shows slightly lower value that keeps bouncing over.
Daniel
-
Sorry they had to disappoint you Scott, but at least now you know. It's still a great looking mustang, anyhow. Post some more stuff when you get a chance. We would love to see them.
-
It also looks like the Velocity DRO doesn't work in their plugin, which would have told them it wasn't moving that fast. They just have a feedrate of 100ipm with a 300% override.
-
Mea Culpa...
It turns out you're right Terry. I didn't run the Mustang myself (that what I get for letting the pubs guys do it) and I didn't question it because we routinely achieve these published rates running that program.
It turns out that Mach doesn't increase the velocities when they cranked up the overrrides (how they -the operators- didn't notice it wasn't changing the speed is beyond me). We looked into it and it appears that Mach won't increase the velocities of the vectors even when we change the program feedrates? It will increase rates for longer vectors but that particular program is ENTIRELY made up of .01" moves and Mach just won't put out anything higher than about 100"/min with vectors that short.
Thanks for pointing out the feedrate display as well -we will take control of that shortly- it never occured to me that it wasn't reporting the actual feedrate. I assumed it the feedrate was being calculated based on the vectors that were being removed from the buffer... We already are displaying the actual encoder positions so it should be trivial to derive the combined axes velocites from that to display the feedrate.
FWIW I will post another video shortly of the same machine ACTUALLY running at 450-500"/min -straight line but pretty good for a 5tpi pitch. I will also get another Mustang video posted when we can figure out why Mach is limiting the velocities.. I'd understand if it was lookahead related but it seems odd that the commanded velocity curve flattens out well below the max velocity of the axes
FYI All our vectors are brought down as .001 sec (1 milli sec) vectors
-
Basically you will be limited to HOW fast the motors can deliver the movement. Micro segmented code is a real problem on low end machines' they do NOT have the POWER/RIGIDITY to do the extreme accellerations need to do FAST micro segmented code in a 3D enviroment.
Most of the Commercial machines that can do it well are cabable of " extreme" accelleration as well as velocity rates. Slower machines will never be able to operate at high feedrates with micro segmented code, the motors never have enough time to get to speed.
I think a different CV approach would help but we have what we have(;-)
THat looks to be a GOOD 3d TEST program a decent mix of micro and long segment code care to share the Gcode?
NICE mustang by the way(;-) TP
-
http://www.youtube.com/v/vgs7efyjV10
Probably could hit ~750 or so but the machine is on a skid so it rocks a little :-)
-
Now that looks much better :) . Would love to see it cutting that mustang at this speed.
Thanks for showing.
Daniel
-
Straight line speed is LOOKING good BUT that is NOT micro segmented code. (;-) Have it tested with segmented lines of .001-.002" for a total of 10 in and see how it goes(;-)
OR just rerun the Mustang as we already have a reference to that file.
3d micro segmented code is TUFF to do right.
(;-) TP
-
Terry,
Thanks for the input.
FWIW The mustang is not "micro segmented" as you would define it. As I pointed out previously, the mustang is made up ENTIRELY of .01" moves -it is pure point cloud data (XYZ pts) from a digitize run we made on a .01" grid. We're now trying to figure out why Mach is artificially capping the velocities it outputs for vectors... even on a straight line, single axis move of 8" made up of .01 increments...
Any thoughts Brian?
-
yep that is basic segmented code that is generated for 3d profiles by most 3d cams, it is small micro moves. The segment lengths are normal dependant on the complexity of the surface. Can be anywhere from .0001 and up.
I think you will find the velocities are capped because of the time constaint of the motor tuning. The motor has to accel up to speed then deexcellerate for each move. There is Just not enought time to get to full speed given the accelleration values most use. If you noticed in your video the moves start with a slow accelleration up to speed then level off then deexcellerate to a stop then reverse. To get faster you are going to have to UP the excelleration rates of the motors. IF the machine can stand it. It is really hard on screws when it gets TOO fast for the design.
Micro code makes it even worse(;-)
Just some thoughts, (;-) TP
-
I would like my mill to move that fast
can you guys tell how I can go about donin that
-
FYI All our vectors are brought down as .001 sec (1 milli sec) vectors
Is this how position data is sent over ethernet?
I have a job to retro fit a Acramatic 850 that has a sumodrive.
This looks like a nice one stop fix for motion to the analog drive and i/o.
Thanks Drew