Am 18.07.2016 um 23:41 schrieb Sebastian Kuzminsky: > On 07/18/2016 02:19 PM, John Kasunich wrote: >> I agree with Niemand that LinuxCNC should not switch to >> joint mode without an explicit operator request. All of the >> use cases I can think of for individual joint movement >> need care on the part of the operator. Dropping him into >> joint mode unexpectedly and treating the next axis jog >> as a joint jog is not good. > I can think of one situation where the controller should drop to Joint > mode un-asked (for some definition of "un-asked"): when a VOLATILE_HOME > joint loses power (for example due to an E-stop). (Maybe marking a > joint as VOLATILE_HOME *is* a kind of asking for this.)
I agree, an Estop with volatile Home_is a reason to switch back to joints mode, but... Linuxcnc will emit a signal "not_all_homed" and the GUI will decide what to do. IMHO that is a GUI decision. I am trying to add as much "on_hal_status..." signals as possible to gmoccapy, so I do know what is happening outside my small word. This way I am able to react to hal pin, halui pin and hardware stuff, just with one signal and one function. Also in this case this way works, as gmoccapy does change to Joints mode getting back to manual. I could check within the GUI if this is necessary and switch back to the desired mode, but IMHO the signal should not be emmited. IMHO all the mode discusion lead to a long discusion without solving the actual isue. By the way the last one before I can merge my branch with master to publish the next generation of gmoccapy. > > >> Today, we don't make a distinction between those two >> types of jogs, because in three-axis space you don't care. > Yesterday we didn't, but today we do. > > The master branch now includes the Joints/Axes branch, which has > separate interfaces for jogging Joints and Axes: the EMC_JOG_* commands > from the UIs to Task and the EMCMOT_JOG_* commands from Task to Motion > now specify if we're jogging joints or axes. Upon receipt of a JOG > command, Motion verifies that it's in the correct Free/Teleop mode for > the kind of jog requested (Free for joint jogs, Teleop for axis jogs). > Mismatch here results in abort. > > Possibly Motion could try to switch its mode to match the requested jog, > and only abort if the mode-switch fails (for example, if an axis jog is > requested on an un-homed non-id-kins machine). > > >> This train of thought leads me to think that the the >> existing manual mode needs to be split into joint-manual >> (FREE) and axis-manual (TELEOP). > That might work... > > I think the distinction between Motion's Free and Teleop modes, when > Task is in Manual, is whether the machine is homed or not. If it's > homed, it should default to Teleop, otherwise it should default to Free. > (And the user should be able to override "by hand" whenever possible, > even if it's dangerous.) > > So I think I just talked myself into another change to > Norbert's/Niemand's suggestion: > > Switching Task to Manual should cause Task to switch Motion to Teleop if > the machine is all homed, and to Free if is is not all homed. > This would be a very good solution. The signal of mode switch will not be emitted and the user is still free to change between Joints and Teleop. Norbert ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
