Am 27.09.2013 um 06:37 schrieb Chris Morley <chrisinnana...@hotmail.com>:
> > >> From: mai...@mah.priv.at >> Date: Fri, 27 Sep 2013 02:16:56 +0200 >> To: st...@pilotltd.net; emc-users@lists.sourceforge.net >> Subject: Re: [Emc-users] JogWhilePaused Proposal >> >> >> Am 27.09.2013 um 00:57 schrieb Steve Blackmore <st...@pilotltd.net>: >> >>> On Thu, 26 Sep 2013 23:20:43 +0200, you wrote: >>> >>>> >>>> - changing offsets or tool diameter will NOT be part of the release >>>> targeted work - this is just too many moving parts to be realistic to >>>> expect. >>>> - changing all UI's to use the new feature may not be realistic to expect >>>> either - only few UI's might be adapted until release time. >>> >>> Changing offsets is available with Les Newell's patch for toolchange. >>> Has that been integrated yet? > > Is this something we can include in the release as well? > IIRC i'ts just a modified tool change component that is stand alone. I dont see a reason why not; actually I have used the trick in a custom gladevcp panel, so it isnt limited to a separate process however I would like to see an example config, and a minimum manpage or readme with a big fat explanation what it can deal with, and what not - just so expectations dont go overboard - AFAICT that means: only linear programs without control structures, input reads, and probe operations >> >> There's quite a large span between things which are desirable and things >> which are doable in the current framework - also note we are addressing a >> short-term goal and a a starting point here which was requested by users. >> >>> Fix that and the broken CV and the numbers of users might increase >>> some... >> >> I am rather sure this kind of problem isnt amenable to what you call a 'fix'. >> > > But AIUI this is being considered in a longer term goal? well I dont like arbitrary limitations, in particular the 'this cannot be done at all' variety, so yes ;) > I have been looking at the TP as I am curious if I could mange work here, > but wow it is a deep hole to jump in without a map :) here's the 'fix' outline (minimum list, my perception): coord mode jogging during pause can be done with rather minimal impact; what is missing is integration with current jog commands (wheel/hal and UI); what it gives is a staring point in the use of multiple switchable motion queues in a limited-impact setting to make offset changes during pause work, the follow structural changes are needed : - currently offsets are applied in the canon layer (i.e. right 'below' the interpreter), and the canon queue carries all absolute positions from there on - this has to move to the component which can change offsets, i.e. motion - meaning changes to canon, the canon queue carrying offset-relative positions, new NML commands, making task do the trick, funnel these commands down to motion, making motion react properly, move limit violation detection to the very place where offsets are applied - note now limit violations cannot be detected at interpreter run time anymore, they _have_ to be done at motion command time as offsets arent known yet - likely this scheme requires some restrictions on the language proper, namely certain values being frozen at program start (see cradek's G92 example from the chat) to make MDI during pause work, add to the shopping list: - multiple interpreter instances (cannot be done in a single process thanks to the design of the current interpreter) plus means to activate/suspend/resume/sync interpreters as needed - read as: either a massive refactor of the interpreter data structure, or multiple interpreter processes including associated interprocess communication commands - multiple motion queues selectable by task - tricking task into supporting the above to make tool dia change work during pause, add: - recalculation of the offset shape (I think this means offset curve generation has to move towards motion too; meaning more changes to canon and motion command part, plus task as intermediary) - lots of testing of the reentry move I think the limit and offset curve calculations will be rather rough to do in a realtime environment, suggesting it be easier to split motion into a userland thread (command) and an RT thread (control) first, giving more freedom what can be done at the command level; a bit similar like halsampler and halstreamer. -- That is all I can think of for now, anybody still listening ;-? there are several useful angles of work, all which would contribute to the above goals, and none of which will result in an immediate 'feature', for instance: - refactor motion into a userland and an RT part - move offset application to motion - move offset curve generation to motion - think through the language restrictions the previous two changes require, and at flag or fail any violations - refactor interpreter static data so multiple independent instances in a single address space become possible (thread-safe, please) - make canon output regression-testable (I mean the canon stuff which drives the machine, not the canon output which is generated by rs274, which isnt the same) for some reason, such projects seem to be less than popular -- I think that also clears up while we only considered jog-while-paused for 2.6 . > Big changes in 2.6! actually the jog-while-paused feature has rather limited breakage potential (famous last words) -m ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
