Home sequence problem soon solved in running program, how to example....

Frequently user's complain about the home sequence. It's also a compilcated item for new user's to customize the home sequence configuration. Information and lecture is limited. Home sequence = -1 or -2??? Or is it both axis? I think home sequence is written in a hurry up time when linuxcnc moved to the joint configuration. Many thing's have changed sinds that time.

About the home sequence :

The machine can not be moved when a mill is drowned into a workpiece
accidently, even after you restart Linuxcnc, homing looks impossible with mill drowned into workpiece.
A temponary solution is to multiply startup icon's on your desktop. One for homing, and one for no homing.
But i don't like this solution. There must be a better way to perfectionize the home sequence anyway.

So to solve this, i am thinking about a solution.

This week i will write a new home_sequence component based on the external offset branche.
It homes all joint's separate and joint's can be coupled together for XXYZ or XYYZ machine setup's.

The output is a home sequence that can be done by clicking a button, whenever user want to, machine can be homed and moved all time. Also it get's the limit switches into the component. When hitting a limit switch, machine can be moved back.

The main feature of the component is :

1. If you startup linuxcnc, machine can alway's be moved directly without homing first.
2. If you want to home the machine you click the button, and homing procedure starts.
3. Homing sequence is saved in a configuration text file, this file has the setup, home speed's, offset's, sensor input's etc. everything.

Hmmm, i like this idea....

I can move my machine without homing and i am able also to home each axis indivudally!
That is standard!

I do not understand why you need a separate homing comp.

Norbert

Hi Norbert,

Thanks for your reply. If you have this homing settings, you can not move the machine without homing first :

I hope you know the solution?
If you have the solution already, that would be perfect !!

In my gui i can trigger the homing sequence in glade or in the python gui code. So far i see it is with homing or without homing in the ini file. Maybee i see something over my head somewhere?

The external offset branche can not do offset's at the joint layer. So far i tried. I work only for an axis.
And if the X axis is put together with J0 and J1 i have problem to home on external offset basis.
Today i was thinking to move further on into the source code to solve my problem. It's not the most important case, but i like to
get it fixed.

But i hope you can give me a quick solution.

Norbert, i was wondering how are you doing? Are you still busy with linuxcnc development? And maybe i ask to much, but do you have a second goal for linuxcnc after you published gmoccapy?

As long as your machine do have a trivial kinematics ( one joint= one axis) there are no problems, as you can move the machine with the axis jogging button.

Gmoccapy from master does recognize if you have a trivial machine ore not and will show joints jogging button instead of axis jogging button, so you yare able to move the machine! That do work with robots and also 5 axis machines with non trivial kinematics.

But in case of a gantry you will not be able to move the gantry axis with the joints button, asit will go out of square. Imho it must be possible to couple the joints to be able to move them simultanious, but because i do not have a gantry i can not present a finished solution.

Yes, i am working on a 9 axis gmoccapy release and a robot gui. But nothing with hurry, just playing arround.

Norbert

Maybe its becasue I've only ever used the Joint Axis features on my gantry machine.

Personally, I don't think the need to home all before using a machine is a limitation. Why should users be allowed to move what is usually a large machine in an unknown state until it is homed? Isn't that dangerous?

Some people are lazy and don't want to properly wire in the limit and home switches or don't use hardware that has enough inputs to save costs. All of my joints have a full complement of home and limit switches (min limit, max limit and home) except the Z axis where I used a shared home/limit switch due to space considerations. I found this axis was the most difficult to configure.

Yes, I had some issues when I first started as there were not many joint axes machines out there when I started. I found a few bugs in homing in both Axis and Gmoccappy GUI's as it was all new and the GUI's were out of step with the way the new core software worked. Norbert to his credit was very responsive with fixes in this area.

Its been a while but I'm pretty sure that Gmoccappy allows you to home a Joint axis without homing the other axes but Axis doesn't do this and forces use of Home All (which is how the core homing is written.) You can however jog and home non-joint axes individually in Axis.

The odd thing to me is that the joints are in play until the machine is homed. Personally, I think Linuxcnc should know enough to not present joints for homing or jogging at all and just present the axes (XYZ) in a normal gantry machine and allow them to be jogged before homing with joint axes moving in unison. I do remember discussing this with Dewey Garrett at one stage and he made me aware of the size of the project to implement the joint axes code without breaking all of the other non-trivial kinematics models (robots, hexapods etc) that LinuxCNC supports. That was before my time. There is no doubt its safer to be jogging a homed machine so I can live with it.

I think that we should adopt the end result and embrace the simplicity the Joint Axis code brings to a gantry machine manufacturer. Our users should just be told this is how it works. To make changes to core functionality becasue we don't like the way things are done are likely to cause us grief as developers down the track. One day I'd like to play with hardware with index signals becasue I think this should be able to eliminate the need to seek the home switches for joint axes homing as the way I see it, the gantry should be able to be squared after the first index mark on each side is found. There could be a case for a custom component to handle this.

Hi linux users,

I think i found the solution without braking the source code.
Linux can be up to 16 axis, i have read somewhere.

So i start not with a slave config like ABC (mach3 config), but we start at UVW.
Then the 3d tool's can be used for ABC axis what releases a nice and simple perspective.

The simplest solution is ad a slave axis for X, named U.
X = joint 0 and U = joint 1.

For other type of gantry's with double Y axis, use :
Y = joint 1 and V = joint 2.

A small home.comp file can do the trick of homing.
Postprocessors can be modified. This is usual stuff.
For example : Tube cutter's also react with multi axis config's to hold the tube in place in front and end position's with different chuck's. So related to more complicated machinery, i think this would be a nice and simple solution.

Let's try this.

@Norbert,

I like robot's too. More then 10 years ago i was kuka expert programmer, made some nice and risky application's with multible robot's
working together. (like automotive welding) i can tell you linuxcnc is much more complicated than the Kuka hmi or program language.

If you look at today's knowledge of army (protection), information technology (AI), etc. I think we as linuxcnc programmer's are in the core of future sience. We have a real time platform, installed within one hour, with no restriction's.

When i recieved my first beckhoff ethercat module. I recieved it with a paper. I may not use it in nuclear facilities or in aircraft's.
Why not? Maybe the German's will not be get responsible for nuclear fall outs? Haha. Let's look at the Amiricano's.
They have influed hardware like Beckhoff (with stuxnet virus) for destroying Iran nuclear facilities with a virus that reacted to the frequentie drives of the facility.

As far as i know, LinuxCNC can handle 9 axis!
Where did you get the information about 16 axis?
I do not know the joints amount limit.

I do not understand your solution, as it would result in the same!
Joint 0 = x axis
Joint 6 = u axis

So if you move joint 0 your gantry will get out of square!

So where is the difference to the actual way?

Norbert

@Norbert,

Excuse me. It's 9 axis for linuxcnc.

What i was thinking is when we move joint 0 and slave joint 6 together, we have no problem.

@Rodw,

You should try Ethercat and Thermal Dynamics. About Thermal Dynamics i have new's related to Hypertherm services.

You can also slave joint 1 to joint 0, beeing joint 1 X1 and joint0 is X0

So where is the advantage of using non existing axis letters?

Norbert

@Norbert,

That would be no problem at all.
Keep up the good work !!