OK -- I just have to go for a case where it might make sense to actually do something during MDI while paused.
I'm machining a piece and notice a lot of vibration -- the part is not clamped down well because the stock (a cast iron part) is not flat under one of the clamps. I pause the operation, I remove the clamp, I change tools, I use MDI to run a subroutine to machine the small surface, I change back to the original tool, put the clamp back in place, and continue where I left off. I don't think any part of that should be hard to do (even if the example is somewhat contrived). Ken On 5/2/2012 3:31 AM, Michael Haberler wrote: > Am 02.05.2012 um 08:22 schrieb Viesturs Lācis: > >> 2012/5/2 Michael Haberler<mai...@mah.priv.at>: >>> 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 ;) > ... >> About the 3rd point - restoring parameters. IMHO changing parameters >> would be the main goal to run MDI commands. User can already move >> machine during pause, so doing the same with MDI does not seem like a >> big improvement. But changing parameters is. > 'parameters' is a lump term for a lot of state, we need to look very closely > which part of state is. There is some interpreter state which is not a > 'parameter', and hence 'never tainted' in my terminology, so making that > changeable during a motion pause might have some reverberations, see below. > >> Could You, please comment on this [silly] idea from the chambers in my head >> is: >> treat hitting "Resume" as a queuebuster operation, which updates all >> the changes of parameters in interpreter and continues the work with >> new parameters. > First, there is no 'queuebuster operation'; some operations invalidate state, > and a later explicit or implicit reference to that state causes a sync. The > scheme which I outlined assumes that for every operation you need *in > advance* which set of parameters it could taint, and that local state (never > tainted) remains untainted. Interpreter modal state currently is local state > (and it better remain so). > > To give a far-fetched example how this could fail big time: let us assume in > your MDI-while-paused scheme your can change the absolute/relative (G90/G91) > setting during pause (nevermind how whacky that idea is, since it changes the > meaning of the suspended program - this is for the sake of argument only): > > - since now distance mode could change during any motion which can be paused, > we define it as a parameter, and we need to classify it as 'changed by any > motion'. > - this means that any interpreter operation which references distance mode > state needs to sync before any motion, so as to be able to compute the right > endpoint of the next motion. > - assume that worked, consider returning: what does this mean for the > currently suspended motion? is that going to be still in absolute mode, or > changed to relative on the fly? you need to answer the question: is the > distance mode committed at the beginning of a motion, or not? even then, it > is unlikely continuing execution of the suspended program after such a state > change makes any sense at all. > > As for the execution side effects, the interpreter now would have to sync > after *every motion* because distance mode might have changed. That means > that the number of motion commands queued will never exceed one - so for that > feature we just killed motion lookahead, and with it things which depend on > it: blending, naive cam detection, cutting performance. > > A few things make sense and can be done in the paused state - you can move > around, and maybe change a tool offsets or the tool diameter in the scheme > we're discussing on irc. I can even see a probe working, provided its results > are just used for setting tool offset, and do not impact the suspended > interpreter state. > > So, 'changing to MDI, fiddling some parameters and returning to auto with the > new parameter settings' in the general case isnt what you want because of the > side effects. What is probable doable is: use MDI mode as way to move around, > and nothing else, but then thats really just a glorified jog mode. 'Doable' > doesnt really translate well into 'desirable'. > > > - Michael > >> I guess that I will get a lot of arguments for some parameters that >> are mandatory to be restored, so I thought that since different >> categories of parameters are meant to be introduced, I think that >> those parameters, affected by toolchange (and maybe probe) should >> remain - that way user could do emergency toolchange, probably measure >> the tool length on touch-off switch and then continue work. >> >> IMHO it does not make sense to implement such things like >> mdi-during-pause, if _all_ the created changes are reverted. Then only >> moving around stays as the benefit, which already is there. I think >> that if user does not want to change any parameters, then he/she >> should not run corresponding mdi commands in first place. >> >> 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 ------------------------------------------------------------------------------ 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
