Lloyd,
thanks,
No CAM can know what a particular controller needs in terms of table movement to do a toolchange. It is the job of the post-processor to hang onto those values, and re-assert the correct XY after the change.
To that end, you can very simply force the machine back to the correct XY by altering your post-processor.
No, of course not. Even more tool change procedure does not only differ from controler to controler but basicly from machine to machine (and their configuration settings).
That's why I think, it would be a good idea that the CAM software makes sure the spindle actually is where it is supposed to be, when it regains control over it. It can't query the controller directly, but it could easily say "Now that You're back, I'd like You to be 'there'".
It's doing that anyway, but assuming that the spindle has not been moved which in this particular situation is not the case.
I have designed my toolchange procedure so, that the controller brings back the spindle to the position where it picked it up when it got the toolchange command. The way back to the stock may be dangerous and I want the tool to be safe, when the controller returns control to the CAM (i.e. GCode).
You're right, CamBam does not know the way through the morass and it should be my (machine's) duty to deliver the package at a position where it can be safely taken over. However I think CamBam should do at least a minimum effort to make sure this happened.
We do the same, don't we? If You ask a colleague or friend to do something for You. Unless he reports by himself, You will ask him "did You that, did it work?..."
For instance, the 'missing' Y in your example can be asserted simply by changing the post so that X and Y are non-modal. Then, for _any_ move, both axes will be issued in the G-code.
yes, I could but that would unnecessarily bloat the code.
Normally, once You pressed
start, the CAM / GCode has control over the machine, line by line going through the code. Unless something unusual happens modal operations are fine.
At a tool change however control is given to the hands of the machinist. Whatever happens there is beyond the CAM's responsibility. It's giving the spindle into a black box and taking a nap until someone tips on its shoulder and whispers "You may continue". CamBam, still half asleep, rubs one eye and automatically replies "ah, eh, yes. X123.45!" without knowing where that thing actually is.
You can also force the axes to your desired toolchange position without doing it manually, by adding that code to the toolchange macro in the post. Then finish the toolchange macro with a G0 to the $mop.first.... coordinates, as laid out in the docs, and here:
$mop.first.x
$mop.first.y
$mop.first.z
[New! 0.9.8N]
Insert the X, Y or Z coordinate of the first toolpath point of the current machining operation.
This macro may be useful after a tool change command, to move to the next machining X, Y coordinate at the tool change height, before plunging to the clearance plane.\
Guess I'll have to do something like that. As mentioned above, my tool already is at the same position it was before the tool change (with a miniumum of Z add for safety), but in that particular situation my controller refused to load the file.
Maybe I just move X and Y by a fraction of a mm in the post....
Anyway, this way each and everyone has to modify the post to be on the safe side and I don't think that would be necessary.
Thanks for Your quick reply.
Frank
