________________________________
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.
>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
>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.
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 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
