Jeeze... Let me re-word my previous email... That is our machine... We just call the next tool after the previous tool change.. (too easy?) So the tool is ready before the next op.. (as long as the operation isn't too short - then it has to wait a bit depending on tool location in the chain...)
https://www.youtube.com/watch?v=39q6kvrSBSk&t=2s On Mon, Jan 7, 2019 at 10:59 AM Sam Sokolik <samco...@gmail.com> wrote: > That is our machine... The we just call the next tool after the previous > tool change.. (too easy?) So the tool is ready before the next op.. (as > long as the operation isn't too long..) > > https://www.youtube.com/watch?v=39q6kvrSBSk&t=2s > > sam > > On Mon, Jan 7, 2019 at 10:49 AM Jon Elson <el...@pico-systems.com> wrote: > >> On 01/06/2019 11:29 PM, John Dammeyer wrote: >> > Excuse my ignorance. The G Code selects a tool by #. The operator has >> placed the tools into the numbered positions for the tool changer. >> > >> > Now here I guess it gets interesting. Most efficient would be if the >> G-Code Parser read ahead and signaled the tool changer object that it will >> need tool # Y next. The tool changer moves and loads the tool into the >> other side of the swing arm. The carousel then moves back to the position >> X which is the tool currently in use. >> > >> > >> > Am I missing something? >> > >> Yes, the G-code definition is that the PROGRAMMER calls for >> the next tool to be prepped by placing a T## command where >> he decides it should be. The problem with read ahead is, >> how FAR do you read ahead looking for the T## command? It >> might be a LONG way down the file. >> LinuxCNC just conforms to the way a bunch of other systems >> define it. >> >> Jon >> >> >> _______________________________________________ >> Emc-users mailing list >> Emc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-users >> > _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
