On 07/18/2016 03:19 PM, John Kasunich wrote: > > > 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.
I agree - which is why I think that linuxcnc should have an option where the machine is never in a joint jogging mode - and not leave that up to a GUI. <snip some good stuff> > 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 think what Chris is talking about (he can correct me if I'm wrong) is mostly the manual vs auto vs mdi distinction. If I understand him correctly I think I would agree with him. Right now the GUI has to make sure that it is in manual mode before it can jog, or mdi mode before it can execute some code. It would seem that the GUI could simply check if linuxcnc is running a gcode program, and if not then allow jogging or run an mdi command. Linuxcnc would have checks as well so that it would just reject a command to jog or run mdi commands if it was running a program. The whole mode switching seems a bit clunky and unnecessary. Perhaps linuxcnc can internally still have modes, but would switch modes automatically depending on the command given instead of the GUI having to take care of that? > 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 > > ------------------------------------------------------------------------------ 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
