2011/4/26 Michael Haberler <[email protected]>: > Does it make any sense to: > - support more than one spindle? > - support more than one tool changer (maybe bound to a spindle)? > > re two heads: I'm running out of imagination; how does one drive a 'dual head > machine' with EMC? any examples?
I am in process of negotiating a 2-spindle machine with a customer. And before I started talking to customer, I had to come up with a plan at least in my head, how to do it. As You already pointed out, currently it is close to impossible to have 2 independent tools execute separate toolpaths simultaneously. I assume that one tool would "have" X, Y and Z, the other - U, V and W. The thing is that each new line of the g-code is executed only when previous line is finished, so there is no way to start a G1 move for one tool in the middle of G2 move for the other. There is a chance to blend the code together with some script or some other external application so that moves for one tool are split in points, where moves for other tool start/stop. But I feel that the problem is that only the tool who has been assigned with X, Y and Z axes can do G2/G3 moves while U, V and W would do only linear moves. If anyone is interested - my special case for 2 independent spindles: 1) each spindle will need to move in 1 plane - they will move along 2 coordinates each 2) both spindles will be mounted on the same gantry, so they will have equal position along 1 coordinate So the intended solution is: 1) the common coordinate is X, the second coordinate for 1 tool is Y, for the other - Z; 2) create paths for each tool - one with X and Y, the other with X and Z coordinates; 3) the key part of the whole thing - create a script which blends both g-codes together: a) split the common coordinate - X - in small (1 mm) increments and calculate corresponding Y and Z value b) write all 3 coordinates in one G1 command 4) run the code in inverse time feedrate mode: it is very very recommended to move X at a constant speed and since the increments of X will be equal for all commands, so completing each move in a equal time would give constant speed along X and make Y and Z move back and forth to complete the path. 5) customer has agreed to several limits regarding the "original" toolpaths to make this solution possible: a) most importantly - max slope of the line in XY or XZ line is 45 degrees - change of Y and/or Z will be smaller than X (otherwise there is a potential risk that running it all in inverse time feedrate mode will require unachievable acceleration along Y or Z) b) it is intended that "original" toolpaths will contain mostly G2/G3 moves, so there were applied some limits on smallest radius >50 mm, which is mainly due to the size of tool, which is expected to have radius of 40-50 mm; c) since G2/G3 moves from original paths are approximated to small G1 moves, it is agreed that max deviance of 0,2 mm is acceptable. Limiting minimal radius to 50 mm helps also here. So getting back to support for multiple spindles in tool changing: I think that currently there is no way to make use of it properly, but I think it would be very nice to have the support for multiple spindles in tool change for future. Viesturs ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
