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. 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. On a serial kinematics robot it might be vital to move joints independently so that you can get the machine to a pose where it is safe to initiate automatic homing. Again, when operating in joint mode you need to do it carefully and intentionally, thinking about what you are doing. 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'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. On a traditional 3-axis machine, operators can use jogs for two different kinds of tasks. They can jog to touch off tools, or they can jog simply to move an axis for for things more related to the machine than machining. For example, on a lathe you might want to jog the cross-slide out of the way before you home the saddle. Or you might want to jog the table of a mill to allow access to lube points. Today, we don't make a distinction between those two types of jogs, because in three-axis space you don't care. With non-cartesean machines, the distinction matters. Jogging in joint space is rare, but sometimes critical, and is usually for machine maintenance or setup rather than normal work. Jogging in cartesean space is extremely common. 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). John Kasunich > If the gui knows what linuxcnc is doing then it can decide what to allow and > what not to allow. > > Chris M > > ----- Reply message ----- > From: "Moses McKnight" <[email protected]> > To: "EMC developers" <[email protected]> > Subject: [Emc-developers] JA - Why does motion mode change from world to > teleop, when I change to manual mode > Date: Mon, Jul 18, 2016 11:53 AM > > > > On 07/18/2016 01:29 PM, Niemand Sonst wrote: > > Am 18.07.2016 um 20:11 schrieb Sebastian Kuzminsky: > >> On 07/18/2016 11:19 AM, Niemand Sonst wrote: > >>> OK, I think I found the problem, but I will need help to solve this issue! > >>> I do not know C++, sorry: > >>> > >>> Please take a look at emc/task/emctask.cc > >>> around line 223 > >>> > >>> switching to EMC_TASK_MODE_MANUAL sets the trajectory mode to > >>> EMC_TRAJ_MODE_FREE > >>> > >>> IMHO that should not be this way, if we come back from MDI or AUTO, > >>> being in EMC_TRAJ_MODE_COORD > >>> So there should be > >>> > >>> if emcTrajMode == EMC_TRAJ_MODE_COORD: > >>> return > >>> else: > >>> emcTrajSetMode(EMC_TRAJ_MODE_FREE) > >>> > >>> Can anyone fix that bug? > >> In the days before we merged the joints/axes branch, Task's "Manual" > >> mode was associated with Motion's "Free" mode, because that's where > >> jogging worked the best (at least for id-kins machines). > >> > >> The JA branch fixed jogging (for all kins) in Motion's "Teleop" mode, so > >> that's what Task's "Manual" mode should be associated with now. > >> > >> Note that Motion's "Coord" mode is for running G-code programs and MDI, > >> not for jogging. > >> > >> So i agree with Norbert's suggestion, except Task should ask for Teleop > >> instead of Coord. I'm not sure what all the consequences of making that > >> change will be, but i think we should accept them, and fix any breakage > >> that results. > >> > >> > > Thank you for supporting me ;-) > > > > Just to explain more in detail my problem, or the bug (IMHO it is one). > > > > Just imagine a user with a gantry (two motors on Y axis), so after > > switching his machine on, he will be in joint mode, that is OK, and must > > be this way! After homing he will be in COORD / TELEOP mode and being in > > manual mode he will touch off his workpiece, change to MDI , just to > > change the tool. Now he goes back to manual mode to jog to a start > > position, _*but he is now in Joint Mode!!!!*_ That could lead to a non > > aligned Y axis!, specially if he uses hardware button to JOG! > > > > Do you see the problem? > > > > Norbert > > I agree with this except for the idea that the machine must be in joint mode > before homing! It is true that while homing each joint needs to be handled > independently, but IMO the user should NEVER be able to move each joint > independently on most gantry machines. > > I suppose in theory a GUI could ensure that a user could not jog joints > separately on a gantry, but it seems to me that it would be better if there > was > support for that in linuxcnc itself. > > Moses > > ------------------------------------------------------------------------------ > 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 -- John Kasunich [email protected] ------------------------------------------------------------------------------ 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
