Homing a dual-motor-for-one-axis gantry machine.

Yes, this topic once again. I have not found a satisfactory method yet by searching this forum.

The mechanical construction of the new mill is progressing well, and the job of hooking up the servos to the 7i77 is near. 2 weeks, maybe three. I already set up the PC with 7i77, handcrafted a basic ini/hal file with AXIS as the UI, only FF1 (1.0) and P (50) coefficients for the PIDs, and verified that the voltages that appear on the analog outputs of the 7i77 match my expectations.

The machine itself is a Cartesian machine with dual Y motors, just like most gantry mills. Since I use two Y-axis motors I used gantrykins and toyed around a little using sim_encoders. So far I am quite unhappy with gantrykins. Having to switch between joint and world mode (can be done automatically, I know), no incremental jogging except for executing MDI through HALUI, and the worst of all: homing the gantry. Using the two Y joints with the same homing number only relieves part of the pain since the homing state machines for both joints execute independently.

If the gantry is not very stiff and can withstand some racking this would not be such a disaster. In my case the gantry is very stiff (780x400x200mm block of synthetic concrete), and the servos can develop terrifying forces through the belt reduction and ballscrew mechanical advantage. If one joint is moving away from the homing switch while the other is still moving towards the homing switch the gantry<->linear guide interface is subjected to an even more terrifying twisting force. And the joint has to decelerate after hitting the home switch, those switches have some hysteresis, so there is always a few millimeters of travel involved, even when the home and home_offset locations are equal. Same trouble with a user error causing one joint in position lock and the other moving.

Maybe reality is not that bad, but for now I see this as a disaster waiting to happen. I did add a comparator that throws an amplifier fault when the Y-axis joints feedback positions deviate more than +/- 0,5mm, which adds a little safety. But I think the homing state machine should at least run synchronised (only allow the machine to advance to the 'move away from switch and latch' state when both joints are in 'have hit the homing switch' state, for example)

I should have connected both leadscrews mechanically with a mechanism that provides a little slack, but I didn't, and it is too late now.

I searched the forum for better solutions, and ran against the JA4 branch a couple of times. Where do I find it and it's documentation? Does this branch provide synchronised homing, or does it only solve the joints vs axes issues?

Besides JA3/JA4 I did not find a good solution.

Other options:
- Customize the homing state machines. Is that hard?

- Configure the machine as a regular 3-axis mill, slave the two Y joints in HAL and provide some external method for squaring. We do have a probe cycle and a method of passing float numbers to HAL from G-code, so it seems possible. Anyone did something like this before?

- Configure as 3-axis mill with slaved joints, use hard mechanical stops as the reference. Might be the best option since it is also the most accurate method. I do have inputs on the servo drives to reduce maximum torque. Reduce torque as long as we are not homed yet, move towards the limit switch, once hit continue moving with low speed, and wait until both Y-axis joints produce a following error (axis.N.f-errored). How would one implement this, and especially the part where LinuxCNC must temporarily ignore the following error and some signal from HAL must tell LinuxCNC that the joints are referenced (setup homing with search and latch velocities in the same direction and connect the ferror to the index signal?)?

- ?

andypugh wrote:

I agree that this is probably part of the solution. There was some debate on the subject.
www.mail-archive.com/emc-developers@list...ge.net/msg09777.html goes into some detail of possible problem scenarios (you would need to scan the whole thread).

if you want my opinion (probably not, as it is very easy to say how things should be done while standing on the sideline): there are several obscure corner cases discussed such as unaligned servo indexes. Personally I don't like building 5-legged sheep that shave themselves. Cover 80-90% of the most frequent cases, cover them well, and make sure that there is a plan B possible for the remaining 10-20%. That tremendously reduces devleopment and testing effort.
In this case a plan B might be adding inductive and/or microswitches (as suggested in the thread too). They do not cost much, are easily implemented and adjusted, measure directly what you actually want to know, and the cheap Chinese inductive ones I use at my current mill are repeatable within 0,03mm. If a corner case is not supported and it can be solved this way, I would be happy.

But of course, the same reasoning is true for linking the two Y-axes together mechanically. Although that is often a lot harder to implement than adding two switches, brackets and cables.

When I thought about it some time ago I concluded that if all axes that shared a homing sequence were to wait for each other before changing state then things might work better.

My idea exactly.
A fairly quick method to vastly improve gantry homing would be to introduce a HOME_SYNCHRONISE parameter that when set to true synchronises the homing moves (more precise: joints must exit the HOME_xxx_WAIT states in the code simultaneously) between joints with the same HOME_SEQUENCE number.
Or even better: joints with the same HOME_SYNCHRONISE number would be synchronised. That still allows simultaneous homing of X and Y, for example.

The state machine is coded here, it has many more states than you might guess:
However, unlike much of the LinuxCNC code, it is quite well commented.

Of course it does contain many more states. But if you exclude the 'housekeeping' states there are not many states for each use case. The code is clean and readable indeed. I suppose I could hack in synchronisation between both Y joints. If I go that way I keep on patching for every update, that's a disadvantage.

Adding an INI parameter and processing it: would that be hard?

andypugh wrote:

As far as I can see the homing state machine can only home one group of axes at a time.
I think it might be difficult to have a sub-set of the group synching together and others doing their own thing.

Just as hard as just synching I think:

The state machine runs separately for each joint, and all joints with the same sequence number are started simultaneously.

If we just say: 'joints with the same sequence number will have their moves synchronised' then addition of a single flag that indicates that one or more joints are in HOME_xxx_WAIT state probably already does the trick, although adding a few 'synchronisation' states to the statemachine (such as e.g. HOME_INITIAL_SEARCH_SYNCH) would be nicer and cleaner.

If extra states are added, stepping up to checking which joints must be synchronised is not that hard; 'joints' and 'num_joints' seem to be global so the content can be checked?

Adding a synced-homing parameter seems easy too (from the helicoper view I'm currently in at least), although it involves modification of multiple files (taskintf.cc->emcAxisSetHomingParams, command.c, emcmot_joint_t struct).

There is actually no penalty (that I can see) in the X waiting for the dual Y axes.

That is only true when the length of the various moves in seconds are structurally longer for joint N than N+1.
If N has a longer 'find switch' move and N+1 has a longer 'move to home position' move the entire process is slowed down.

On the other hand: this is one of those theoretical corner cases and I doubt someone encountering this case would really care that his homing procedure takes a few seconds longer.
I would choose the simpler no-parameters-always sync solution over the more flexible 'manually-pair-joints-to-be-synched' solution. Less room for error both in coding, and in configuration of a system.

Yes, I think that is exactly what I am going to do.
I need to do something; off the shelf gantrykins/trivkins doesn't cut it for me. Running against hard mechanical stops still seems the most simple and accurate solution, but that is not easy to implement either.

Now, how do I get that JA4 branch with gentrivkins, and can I integrate rellenbergs circular-blend TP in it?

OK, figured that out before you posted. Sorry for asking-before-thinking.
Compiled it, and it says 'LINUXCNC - 2.6.0~pre joints_axes'. I also found this Wiki page and when trying to start linuxcnc it gives me the option to reconfigure by script.

Remaining questions:

- If I also want the improvements made in the circular-blend-arc-rc3 branch, how do I do that? git merge <something> I suppose. More a git question than LinuxCNC related.
- How to use gentrivkins? Same as gantrykins? None of the sample configurations use it...

Sorry for asking dumb questions now and then. I'm an hardware engineer, and although I am quite comfortable with C/C++, I am not comfortable at all with RCS/CVS/GIT/general PC programming/etc.