Am 01.05.2012 um 23:22 schrieb Viesturs Lācis: > 2012/5/2 Michael Haberler <mai...@mah.priv.at>: >> >> The background was the following: we discussed changes which would permit >> changing tool offset and cutter radius during a pause operation. >> >> Under the current scheme, this would mean: >> >> - the handling of parameters 5400-5413 needs to be changed in the >> interpreter; something which wasnt considered a 'queuebuster' so far since >> it wasnt possible anyway suddenly looks like a queuebuster. >> >> - changing a tool and its parameters during pause has no corresponding >> underlying g-code operation, so I dont see any clean way to do this in the >> current scheme since this is keyed to an *operation* > > Thank You! > > I _think_ that executing appropriate toolchange command in MDI would > tell interpreter, which entry from tooltable should be used further > on. Does it answer Your question of a clean way to do it?
Viesturs, you're charging on a real fast horse.. We discussed TLO, and tool diameter change during pause. Note I didnt say 'MDI during pause'. > Speaking of MDI, I somehow feel that executing MDI commands during > pause might be a way to adjust some modal conditions without > interrupting execution of code (unless they are reapplied in the code > later on). Unfortunately I cannot think of an useful example :) > > How does this proposal affects ability to run MDI commands, when paused? Not at all, because that would need to be handled with a completely different mechanism. -- But since you asked, this is how I think MDI-during-pause could work (which is a 'simple matter of programming' ;): First, motion needs to be able to switch between inputs. Currently it takes commands only from a single task+interpreter instance (the usrmotintf.cc code). Assuing that existed: when you hit 'Pause' and 'switch to MDI', the following things need to happen: - The currently executing trajectory planner queue in motion is put to rest, as is the executing task+interpreter instance (note I explored some of this motion queue switching with the jog-while-paused code I recently posted, so it seems doable) - a second instance of task+interpreter is cloned from the frozen task+interpreter with all settings, parameters etc, and switched to MDI. - motion now takes instructions from this second instance. you can now 'MDI around'. - when you hit 'Resume' a return move might be needed, and some copying back any parameters which are possibly subject to change while paused. - when done, switch back to primary task+interpreter combination, reactivate the primary tp queue, and continue that's all ;) - Michael > > Viesturs > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
