Joint mode command for homing without errors

Hi,

When i do multiple homing command's i get error : Must be in joint mode.

So i was looking to solve this. This error is only for latest update linux users.
It's very difficult to solve.

Here a code example of a homing all axis button :

Do someone know to solve this?

Hi Andy,

I have tried this several way's including the python code's but no succes. Examples i had where from Gmoccapy and Gscreen etc.
I know i saw something over my head, but next week i am so far to look at this issue again i think.
I will go with the latest buildbot version and go with this for coming time without update's.

My current linux version is now ubuntu, installed a cheap and powerfull touch screen. Cost's 2 dayś for get the touch screen working.
But i don't complain. It's my choise to go this way.
Builing the linux with synapic package manager is the way to get all things working in one time, like glade with extra linux developper programming option's it spares much of time.

I have made progress in writing powerfull linuxcnc issue's, after learning and fealing for long time. Again and again faling. But never give up. Just like the Titanic movie. Linux will not end like Titanic i think. It will go on in the galaxy for another 10.000 years.
When the sun is melded down and the Earth is burned into the sun. Linux is already on another place in the galaxy.

I think the last master update's on linux are not so good checked. Someone has done this too fast without good checking.
But that is my opinion. If i do this, i get lot of work to get things solved. I don't want to work that way.
Better make time to set thing's up hufter proof like experienced with axis !!!

Your problem could be related to a regression in the latest source code for master branch I identified on the weekend. Previoulsy attempting to jog before homing on a machine with a joint axis raised an error message


Currently, this test is ignored so attempting to jog before homing is badly buggy.

Because of the regression, before homing, Joints are mapped to axes as follows X=0, Y=1, Z=2 and to hell with any other joints which are just ignored.
In my case with a YYXZ, the gantry is racked as only one side is moved.
Clicking on home all solves the problem. The machine homes correctly and axes with multiple joint then jog in unison.

This is restricted to the Axis GUI and Gmocappy works fine, probably becasue I identified this bug over 12 months ago and Norbert fixed it.

In my view, the real problem with the merge Andy refers to is that few people in the dev team have grasped the significance of the changes this brings and I believe part of this stems to the poor choice of names. Can we please cease referring to Joint axes and refer to independent joints. The LinuxCNC core has it right but the authors of various GUI's, Stepconf and PNCCONF are still trapped in the dark ages. They think there is nothing they need to do but they do as the core code has changed so they can make no assumptions about any direct mapping of axes to joints!

Grotius as you are writing your own GUI, you could also be falling into the GUI trap. the simplest solution is to only allow home all as there are no features in master branch to home individual joints on a gantry machine. Why fight the master paradigm? You choose LinuxCNC, you just do what it expects, not something that you want to do. However if you must persist, look at how Gmocappy works around it in its Python source code. There is an old thread I raised in the Gmoccapy section that deals with solving this homing bug and the code causing it.

In the meantime, I am hoping working with cmorely on PNCCONF so I hope I can tick one more off the list with him. I don't know who the axis developer is, but the regression shows he/they have not grasped the significance of the independent joint functionality either.

Found it
forum.linuxcnc.org/gmoccapy/32227-solved...-master?limitstart=0

You will note that it was hard work convincing Norbert that there was a bug in his GUI code back then and at the time Axis was correct and now broken....

@Hi Rod,

Norbert is a good guy. I think he will be very busy next coming years with software writing. I hope he will get the financial support or benefitś someday.

Thank you for your input. I am now so far to put a powdercoated box together with a touch screen and a pc with possibilities
for custom pid coocking project or other bandsaw related project to ship the custom product worldwide.

I will go back to the most stable version of linuxcnc and will use this for the coming 10 years without updateś.
I need to merge my current code a little bit, but no problem. After monts of testing in python i know the way a little bit.
I know it soundś crazy, but it is now the only way for me to build something i can use and otherś hufter proof.

A example i order a Thermal Dynamics machine controller for 12000 euroś. It talks to the High defenition ultracut plasma source.
I am able to make the same set up in linuxcnc but the cam solution integratrion is for me work to do. I can use hypertherm prones for 1400 euro. But is not working on linux. Sheetcam integration is also a possibility but i have to contact newell then how he thinks about that option.

So work to do. Finally i am very far in the setting up process i think. Thanks to other great tutorials and examples around the internet.

For me itś good to understand the python reading and writing of dxf files. The way of making inner and outher contour.
If i know that. It will be good !!!

Grotius as you are writing your own GUI, you could also be falling into the GUI trap. the simplest solution is to only allow home all as there are no features in master branch to home individual joints on a gantry machine

This you can do one time. Second time you get error. Soon i will get the solution. I will write a home sequence myself.

I've been back into the configs and recompiled different Linuxcnc branches a couple of times today and have been unable to replicate the homing error I referred to. I can only assume it has been resolved or never existed (which would mean I'm an idiot which could well be the case). Please disregard my post.

In addition, we reviewed some of the latest commits with one of the LCNC developers and concluded no recent changes should affect homing behaviour.

Here are a couple of links that might be worth reading

linuxcnc.org/docs/master/html/getting-st..._axes_specifications

linuxcnc.org/docs/master/html/getting-st...dating-linuxcnc.html

I don't think its true to say that the changes in master have been rushed. It is true that its quite different to what has gone before (in 2.7) in how it deals with joints and axes as the links above will show.
There have been some decisions made to hide some of the new complexity from the user but some of us don't agree with this approach. However LCNC has been around for a long time and supports many complex machines without changing the core code. Whether you agree with how it works or not, if you do choose to use LinuxCNC then its best to accept the programming paradigm used otherwise you will be forever fighting against its view of the world. To partition it off into your own branch is not the right approach in my view as you miss out on the collective wisdom and journey of continual improvement by some very clever people.Personally I would want to have their collective wisdom on my side.