(SOLVED) BUG REPORT: Gmocappy Homing buttons in joint mode in Master

@bevins,

Could you give an example for a config, using two joints for one axis, where it make sense to home only one of the joints? I can not imagine such a config with trivial kinematics.

Norbert

newbynobi wrote:

@bevins,

Could you give an example for a config, using two joints for one axis, where it make sense to home only one of the joints? I can not imagine such a config with trivial kinematics.

Norbert

I cant name any either, but as soon as you close that door and lock it, someone will be on the other side knocking wanting to get in.

Whats great about linuxcnc is it's very versatile and you can basically do what you want with it just the way it is. Your removing an option that doesnt have to be removed.

It definately would not benifit me, but others it might.

Bevins,

Just to clarify, if you have KINSTYPE = BOTH in your .INI file, that enables joint homing mode and the ability to switch homing modes. In this case, hiding the axis homing buttons does not happen with my mods to the gmocappy source so people will still be able to get to everything. Subject to Norbert's intention of course....

I think the other possible factor to consider is that in earlier versions if HOME_SEQUENCE is < 0, the axis is excluded from home all. It now means its a joint axis. I have not played with this so I don't know if a negative value on a non joint axis joint is still treated the same in master.

And for Norbert... If you are quick seeing I am building a gantry machine, I might be able to set up a joint axis with each stepper on a separate and independent linear rail for testing (eg. before I fit the gantry beam...) That way nothing is likely to be damaged..

@rodw,

I just pushed gmoccapy 2.2.4
That release does check for double AXIS in [TRAJ] COORDINATES and sets the double mentioned axis homing button unsensitive.

So I implemented your patch (just added the check for every possible axis).

Thanks for helping solving this misbehavior.

@JT,
I will take a look at that branch, as it may solve the problem and the work around in gmoccapy may be removed again.

Norbert

@rodw
@JT

I have played around with Deweys branch and added some minor modifications. It seems to work as expected.
Could one with a real machine please check?

IMHO after checking on a real machine the branch should be merged. If that is done, I can redo the double letter check and all should work as expected

I will introduce a settings option to hide the button to change between world and joint mode, as it would be dangerous on a gantry to jog only one of the synched joints.

Norbert

newbynobi wrote:

@rodw
@JT

I have played around with Deweys branch and added some minor modifications. It seems to work as expected.
Could one with a real machine please check?

IMHO after checking on a real machine the branch should be merged. If that is done, I can redo the double letter check and all should work as expected

I will introduce a settings option to hide the button to change between world and joint mode, as it would be dangerous on a gantry to jog only one of the synched joints.

Norbert

Norbert, thanks for this. I am not sure if I insisted or assisted you with this bug.

newbynobi wrote:

I will introduce a settings option to hide the button to change between world and joint mode, as it would be dangerous on a gantry to jog only one of the synched joints.

Is this actually required? I thought that the kinstype=BOTH is what enabled the ability to change between world and joint mode. If the user enables BOTH on a joint axis gantry, then it is in his hands.. but then dewey's revised homing sequence should fix that anyway.

I'll update master and give it a try. I have to learn now to install and merge branches I can see. It will be a couple of weeks before I can properly test. I have one half of my joint axis moving but its lying on its side for now

Um, need a bit of help here. I pulled the master code from git and had to use sudo to build it for some reason. That casued some permissions issues.

I changed the permissions in the bin and rtlib directories to 755

From the command line, the linuxcnc chooser opens but I get this error and LCNC won't load.

Its still clearly permissions related. How do I fix this?

Rodw,

Are you still running a rip? Have you tired to make clean, reconfigure and build it again without root?

I would just do another rip. Will probably save you time than trying to hunt down file permission issues. Or if you can hunt down where iptables is located and check its permission.

About 10 minutes ago I pulled a fresh git for master and built it no issue. I noticed Norbert made some changes so I wanted to see what it was

Thanks, this is specific to my hardware but I'm still offline. See
forum.linuxcnc.org/27-driver-boards/3236...r-broke-mesa-hm2-eth