Am 19.07.2016 um 02:34 schrieb Chris Morley: > > > ________________________________ > From: John Kasunich <[email protected]> > Sent: July 18, 2016 8:19 PM > To: [email protected] > Subject: Re: [Emc-developers] JA - Why does motion mode change from world to > teleop, when I change to manual mode > > > > On Mon, Jul 18, 2016, at 03:28 PM, Chris Morley wrote: >> I think the whole mode thing needs to be looked at.Needing to switch to mdi >> to do manual things like touch off and tool changes is annoying when >> building a gui. >> Why do we need separate modes? That is left over from legacy NC machines. >> It is restrictive and error prone. >> I think as much as possible the gui builder should be able to decide what is >> available and what is not. >> I think the MACHINE builder needs to decide what is >> available and what is not. > Well I believe the MACHINE builder chooses the GUI or UI > so I might be missing the point here. > Also at the moment the builder doesn't get to choose > anything about modes, yet the UI must deal with checking modes. > Yes, and sometimes it is anoying to check for modes before doing a command eithin the GUI. If the mode is modified from external, i.E. Halui commands, it is getting worse, because the Gui must react to that change too and is not able to disable that possibility. A lot of code is needed to handle such situations.
>> On a gantry, moving one of the two motors independently >> is bad. UNLESS you are carefully and intentionally doing >> it to align the gantry prior to setting your encoder index >> positions or homing offsets or whatever it is that will allow >> the machine to home to a properly squared position. > agreed See my previos post > >> I can't see how you can eliminate modes. Jogging joints >> and jogging cartesean axes are two completely different >> and incompatible things. Imagine a hexapod - every axis >> jog will move all six motors. >> I don't think the problem is modes - we just have the >> wrong modes. > It seems to me the problem is - before homes and after homed. > and even that is only on non-trivial machines. > Obviously restricting coordinated movement of non-trivial machines > before homing (by motion) makes sense. Till here I agree, could we agree, that mode will not change if all joints are homed? Who can add that code to task? > After the machine is homed the distinction of modes is driven > by the UI so I think as much as possible the UI should control > this. I am saying often linuxcnc's modes are too restrictive and > now the GUI must work around them with kludgy mode switches. > > I think all that linuxcnc needs to decide is if it is busy doing some > command such as MDI or auto, then it won't process another command. > it just takes the mode switches out of the picture. > why must motion switch modes to jog after MDI? > Is there a actual reason? > > Then the UI builder can decide if he will allow jogging right after an MDI > command > finishes or if the user must switch "modes". > Zeroing an axis wouldn't require a mode switch to MDI and another one back to > manual. > > Basically I am thinking Motion should be as accommodating as it can. > And that the UI would set the restrictions and concept of 'mode'. Chris, all you mention is completely correct, but we shoul try to solve one problem before getting to the next one. I support 100 % that the linuxcnc restrictions are sometime annoying and not understandable. > Chris M > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
