search

LinuxCNC / linuxcnc

LinuxCNC controls CNC machines. It can drive milling machines, lathes, 3d printers, laser cutters, plasma cutters, robot arms, hexapods, and more.
http://linuxcnc.org/
GNU General Public License v2.0
1.79k stars 1.15k forks source link

Jogging unavalable joint unrecoverable #625

Closed c-morley closed 5 years ago

c-morley commented 5 years ago

In 2.8+ using Gmoccapy lathe config (must be a config where joints vrs axis numbering is not equivalent and joint jogging is allowed) before homing if you jog the z axis linuxcnc becomes unresponsive and in the terminal you see: USRMOT: ERROR: command timeout

There are two problems here. Gmoccapy is probably trying to jog joint 2, which isn't in a lathe config. linuxcnc or the linuxcnc python module should check for available joints before trying.

For the Gmoccapy problem, this is do to the joints/axis changes. Joints reference numbers change depending on the machine. For a lathe x joint:0, z joint:1 Axes reference numbers always use x:0, y:1, z:2 etc

So you can see here to jog z joint - reference number is 1 to jog z axis -reference number is 2 This is obviously error prone. Keeping in mind with user configurable GUIs like Gscreen and Qtvcp, users will find this problem too.

One possible fix is to use joint numbers for both types of jogging. This would require teaching the linuxcnc python module to convert the joint number to the axis number - which would be less error prone for the user.

another might be to use letters for axis jogging which would cause an error immediately.

dngarrett commented 5 years ago

One possible fix is to use joint numbers for both types This would require teaching the linuxcnc python module to convert the joint number to the axis number - which would be less error prone for the user.

In general, one can only derive an axis coordinate identifier for identity kinematics (like trivkins). For other non-identity kinematics types, there is no fixed rule or relationship to convert joint numbers to Cartesian coordinate identifiers. This task is done by supplied kinematicsForward() functions for implemented kins and is done automatically in the motion module (motmod) for both teleop jogging and coordinated motion (gcode,mdi).

see also: commmit fe62e95 commit ebfdd58

dngarrett commented 5 years ago

accidentally closed, reopened:

With respect to the python interface, suggest adding alternatives instead of altering current jog interface since user out-of-tree applications may rely on the longstanding behavior of existing interfaces

c-morley commented 5 years ago

Could you give me an example of a machine that could not use joint numbers as axis numbers? I should explain better too I guess. for a gantry machine that use joint 1 and 2 for the X axis for instance. you could use either joint number to designate the axis, because in axis mode that are locked together.

I disagree - Now is the time to change the longstanding behavior, if required. Joint vrs axis has never been released yet

c-morley commented 5 years ago

reference your commit - thanks that covers the unrecoverable jog problem.

dngarrett commented 5 years ago

example of a machine that could not use joint numbers as axis numbers?

intree kinematics modules:

5axiskins.c corexykins.c genhexkins.c genserkins.c lineardeltakins.c maxkins.c pumakins.c rosekins.c rotarydeltakins.c scarakins.c scorbot-kins.c tripodkins.c xyzac-trt-kins.c xyzbc-trt-kins.c

c-morley commented 5 years ago

I was hoping for an explanation of the problem

c-morley commented 5 years ago

I can see the problem now - for instance 3 leg machine use all thre legs to move any equivalent axis

dngarrett commented 5 years ago

Suggest experimenting with a non-identity kinematics example like configs/sim/axis/ldelta_demo.ini Which joint number would correspond to which axis coordinate?

dngarrett commented 5 years ago

In the current design, the axis index needed for teleop jogging is readily derived from the indexing rule that is applicable to any kinematics implementation: s="XYZABCUVW" index=s.find("Z") # for example

c-morley commented 5 years ago

Yes I realize that. I am trying to mitigate a foreseeable problem for users building guis. Selecting a joint/axis to jog is a pain/easy to get wrong because of the two very similar but different numbering systems. I obviously had not thought the problem far enough though - thanks.

c-morley commented 5 years ago

Anyways closing the issue as you have fixed the critical problem - thank you for the discussion.

gmoccapy commented 5 years ago

What even you do, it must be possible to jog joints and axis, depending of the jogging mode. Everyone building a GUI should take care of the machine configs he want to allow to be used.

Next release of gmoccapy will take care of all cases of machines, nevertheless how the joints axis relation is done in the config. So do not take any affort to check gmoccapy code, as it is already old.

If someone touches the jogging part, then please take also the change to be able to jog joints from gcode, just think on a handling system feeding parts to a 5 axis mill...

Norbert

Am 21.07.19 um 19:48 schrieb c-morley:

Yes I realize that. I am trying to mitigate a foreseeable problem for users building guis. Selecting a joint/axis to jog is a pain/easy to get wrong because of the two very similar but different numbering systems. I obviously had not thought the problem far enough though - thanks.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LinuxCNC/linuxcnc/issues/625?email_source=notifications&email_token=ABUAJ6MWQNKGA3KS5XEXIDTQASONZA5CNFSM4IFS6FU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2OIJTQ#issuecomment-513574094, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUAJ6PKLYVZLCFQE2FDCTLQASONZANCNFSM4IFS6FUQ.