Machsupport Forum
Third party software and hardware support forums. => dspMC/IP Motion Controller => Topic started by: piv on January 13, 2010, 06:02:02 PM
-
Does anyone know or has anyone done tests to determine the effective maximum block processing speed when using CV, Mach3 and DSPMC for contouring 3D 5 axis toolpaths? Does Mach just output points to DSPMC at 1kHZ regardless of the G code point spacing?
-
I don't know but if you had some code you were worried about I would be willing to try it out/ simulate it. I currently only have 3 axis running but I am working on getting 4 5 and 6 working in the future.
Is there a specific worry that you had in mind?
Mie
-
Ive got a DSPMC on order to upgrade some 5 axis machines that do mould making work but it wont be here for another week and then Ive got to install and test. If it works then it saves having to go to an expensive controller plus the Mach3 interface is one of the best around. The problem is that CAM programs put out lots of points closely spaced so actual run speed often depends on block processing rate rather than the programmed speed. It is possible to get some CAM systems to output decent code and I have built machines with higher end (expensive!) controls that can take spline input and trust me sorting that out is a pain. The easiest way is the sledgehammer approach and blame it on the machine control and just make it faster. 1000 blocks /sec should be good, 10 000 would be fantastic (not many can do that and i doubt mach3 will), 250 blocks/sec just acceptable.
I will get some code snippets together tomorrow, run them on my Mach3 (no hardware connected, no DSPMC yet) and then post for you to test. Thanks for the offer. I will post results of my testing in a few weeks.
-
Let me know how it works out.
While Art was testing the new Tempest trajectory planner, I ran some very segmented code and it ran fine even ~100 ipm.
I think that you will be thrilled at how well Mach3 and the DSPMC work together.
With the DSPMC handling all of the heavy lifting, all Mach3 has to do is send the trajectory information to the DSPMC.
Did you ask Rufi or Art or Brian this question directly? They should have some sort of answer.
Mike
-
Thanks, I asked Rufi and he was going to ask Brian, but Ive not heard back yet (only a day or two). Im new to Mach3 so I dont know who Brian is. Can you put me in touch please.
-
Brian Barker is the man who now owns Mach3. He took over from Art who created Mach3.IIRC
If you ask the question in the general mach section you might get a better response. Otherwise you can ask on the Mach3 yahoo group. If you haven't joined it yet I could ask for you. Mike
-
Here is some code out of ProE to test. One file at 0.01mm tolerance and another at 0.001mm tolerance, but only first part of the file to stay in 600k limit.
Ive not made a Mach3 post yet, im using a hacked up Fanuc post but it seems to be OK.
See if you increase the feedrate to 60m/min what happens?
Thanks
Piv
-
Hi piv,
Are you sure you need 60meters per minute??????? I think that is in excess of 2000ipm.
My machine in its current state of tune will run at a max of 6.3 meters per minute if my math was correct. ~250ipm.
I tried your code as is but had to add a g21 because your code is metric and mine machine is english.
The code ran OK but I normally don't run the mill that fast. I had the feed set sky high but as I said my machine tops out at about 7 meters per minute. The dspmc had no problem running the code, but since my machine is not properly leveled it rocks when running something like the code you sent me.
I will try to run it using the tempest planner that Art has been trying out. It should run much smoother.
-
Hi Totally RC,
Thanks so much for doing that test. It looks like it will all work. Yes we do plan on cutting at up to 60m/min. Its a big machine (2.8m x 1.4m with 0.8m of Z travel) and it often cuts foam. Its been cutting wood patterns for castings up to 16 hours a day for the last 5 or six years at about 15m/min feedrate. Ive made other flat bed routers that can cut MDF at 40m/min, but that is usually cabinet work with straight lines so the motion and code is not so demanding.
Your machine did well to go over that program at 6m/min, well done, thats part of a program that I run on a mill at about 1m/min normally!
Ive attached some simple code that is lots of segments on a straight line that you could try at 6m/min, at 0.1mm segment length that gives 1000 blocks per second and at 0.01mm segment length it gives 10 000 blocks per sec. Its not how I would recommend programming it but its typical of the rubbish that a lot of cam programs make, especially when the operator is in a rush. Its go no header or end code, hope you dont mind.
-
I will try them out today or tomorrow. My machine was designed to go 7.5 m/min but the new servo motors(SEM) that I got real cheap($25) are higher voltage than the old ones.
??? A new power supply is on the list of things to do but the list is quite long. ???
If I can find a way to simulate running without the motors connected I will, just to see how fast Mach3 can run the code.
Mike
-
Thanks Mike,
Hopefully my DSPMC will be here in about a week.
-
Ive got my DSPMC hooked up to a linear motor and Mach3. It all looks pretty good. Ive run a few tests and it looks like Mach3 will process about 170 blocks per sec in CV mode with 50 to 200 lines of look ahead on my 3 year old single core 1.6GHz laptop. The good thing is it doesnt get "data starvation", it just slows the feedrate down so it feeds smoothly at whatever speed it can read the file at. Some other controllers just feed fast and then come to a dead stop when they run out of data and then go jerky jerky as they then read the code one line at a time (even if it is at 250 or 1000 blocks per sec), until they get to a slow part of the program and the look ahead can catch up again. So yes it is OK if the CAM output is good, but its not real good for working with bad CAM files at high speed.
Heres my 2c worth on how it might be made better for a servo system. Basically simplify the trajectroy planner so it does less work and can process every block faster. Dont worry too much about the acceleration or jerk and corner blending, the servo tuning will look after that to a certain extent. Use the corner angle to decide if it should go to exact stop or stay in continuous feed. Only do linear interpolation on the segments with no corner blending. Check the accelerations (average acceleration as dumb as (Vfinal-Vstart)/period over a period (of say 10ms) and alter the feed rate if the average acceleration is above a certain value. Of course this method would be useless for stepper systems. But what I am talking about here is fast servo systems. Most servos have a time constant of at least 1 to 10ms so there is no point in getting too fussed about things in a shorter time frame. The problem is that its real hard with CAM systems to get them to put out sensible code and the easiest way is to process the blocks fast.
In the ideal world Mach3 would feed the required axis accelerations into the DSPMC and then the DSPMC could use that as feed forward in its control. If it did this, it would be truly first class. But I guess I am dreaming.
I havent tried Tempest yet as I think the issues are related to the complexity of the trajectory planning slowing things down.
-
Rufi from Vital Systems and I are going to put something together for testing.