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

DaBit
Offline
Platinum Member

18 Apr 2014 05:34 #46054 by DaBit

Replied by DaBit on topic Homing a dual-motor-for-one-axis gantry machine.

At least something has changed in JA4:

- Axis doesn't display 0,1,2 but XYZ, even when it is in 'free mode'.
- When in teleop mode, both joints move together, and do so according to coordinates=XYZY. So at least it mimics gantrykins.

But either I am doing something wrong (very likely), or it has little benefit over master/gantrykins.

Please Log in or Create an account to join the conversation.

andypugh
Offline
Moderator

18 Apr 2014 05:47 #46058 by andypugh

Replied by andypugh on topic Homing a dual-motor-for-one-axis gantry machine.

DaBit wrote:
Axis doesn't display 0,1,2 but XYZ, even when it is in 'free mode'.

As far as I can tell there shouldn't _be_ a free mode with a trivial kinematics.

But either I am doing something wrong (very likely), or it has little benefit over master/gantrykins.

No, it just looks like the advantages that ja4 is meant to have are not really there.

Please Log in or Create an account to join the conversation.

DaBit
Offline
Platinum Member

18 Apr 2014 14:18 #46066 by DaBit

Replied by DaBit on topic Homing a dual-motor-for-one-axis gantry machine.

andypugh wrote:

DaBit wrote:
Axis doesn't display 0,1,2 but XYZ, even when it is in 'free mode'.
As far as I can tell there shouldn't _be_ a free mode with a trivial kinematics.

Underwater there should be one, otherwise things like homing cannot work.
But it should be kept under water. JA4 only succeeds partially in that.

No, it just looks like the advantages that ja4 is meant to have are not really there.

Bummer

I don't think that using JA4 makes much sense then. Easier to just use the circular blending TP branch; that saves me the trouble of integrating circular blending in JA4.

How about a setup like this?

- master/gantrykins, XYYZ with joint 0 being the X, 1&2 being the Y, 3 being Z.
- Use a multiplexer in HAL to feed both the joint 1&2 PID's the motor-pos-cmd of joint 1 when homing for joints 1&2 has not been completed yet and no homing is in progress. That would make the joints move together initially, also when jogging in joint mode.
- Use a synchronised homing sequence to home and square the gantry. The synchronisation should make it a safe operation.
- Add a 'comp' that compares the motor-pos-feedback's of joint 1 and 2. If they ever deviate more than 2xFERROR, throw a servo fault or estop
- Use the .axisrc or the halui.mode.teleop pin to automagically switch to teleop mode once homed.

Not beautiful and clean, but it sounds useable and safe to me.

Now, I also read something about gantrykins/teleop mode not obeying soft limits. Is that true? If so, what's the story behind that?

Please Log in or Create an account to join the conversation.

andypugh
Offline
Moderator

18 Apr 2014 16:51 #46071 by andypugh

Replied by andypugh on topic Homing a dual-motor-for-one-axis gantry machine.

DaBit wrote:
Underwater there should be one, otherwise things like homing cannot work.
But it should be kept under water. JA4 only succeeds partially in that.

What puzzles me is that I don't know how the system (and especially axis) can tell the difference between gentrivkins and trivkins.
Are things equally broken in JA4/trivkins, but you simply don't notice because free mode looks just like teleop mode?

- master/gantrykins, XYYZ with joint 0 being the X, 1&2 being the Y, 3 being Z.
- Use a multiplexer in HAL to feed both the joint 1&2 PID's the motor-pos-cmd of joint 1 when homing for joints 1&2 has not been completed yet and no homing is in progress. That would make the joints move together initially, also when jogging in joint mode.

That sounds to be duplicating part of the function of gntrykins, which might cause problems if they ever disagree.
If you have a synchronised homing sequence set up then gantrykins ought to be enough.
I wonder if an INI entry could configure an automatic switch to teleop mode as a last stage of the homing process?

Please Log in or Create an account to join the conversation.

DaBit
Offline
Platinum Member

18 Apr 2014 18:23 #46073 by DaBit

Replied by DaBit on topic Homing a dual-motor-for-one-axis gantry machine.

andypugh wrote:
What puzzles me is that I don't know how the system (and especially axis) can tell the difference between gentrivkins and trivkins.
Are things equally broken in JA4/trivkins, but you simply don't notice because free mode looks just like teleop mode?

I don't know. I'll check the sources, see if I can understand what's going on.

That sounds to be duplicating part of the function of gntrykins, which might cause problems if they ever disagree.

Yes and no.
Yes, it duplicates gantrykins functionality.
And no it doesn't, because gantrykins works only in teleop mode, and the HAL-joint-duplication works only when not in teleop mode and not homing. So the only situation left where the two joints are allowed to move independant is when homing.

If you have a synchronised homing sequence set up then gantrykins ought to be enough.

No, because there are multiple occasions where the joints can move independantly.

I wonder if an INI entry could configure an automatic switch to teleop mode as a last stage of the homing process?

I didn't find one in the documentation.

Please Log in or Create an account to join the conversation.

andypugh
Offline
Moderator

18 Apr 2014 18:35 #46076 by andypugh

Replied by andypugh on topic Homing a dual-motor-for-one-axis gantry machine.

DaBit wrote:

andypugh wrote:
]I wonder if an INI entry could configure an automatic switch to teleop mode as a last stage of the homing process?
I didn't find one in the documentation.

It isn't there now, I was wondering if it would make sense to add it if you are re-working the homing code.

Please Log in or Create an account to join the conversation.

DaBit
Offline
Platinum Member

18 Apr 2014 21:44 #46085 by DaBit

Replied by DaBit on topic Homing a dual-motor-for-one-axis gantry machine.

It hurts nobody when it is added. If automatic switching to teleop mode is not what you want, just don't mention it in the INI.
We'll see; first A (synchronised homing), then B (nice to haves). I will start putting servo drives and wiring on the machine tonight. If I restrict the drives to 20% of their rated torque or so I have a safe real hardware testbench to test the code on. Quick to say, but in the end it will take some time to get the electronics assembled, wired and functional so don't expect a modified homing.c next week.

But the real issue is still that LinuxCNC doesn't cover synchronised joints (or more generic: constrained joints) at all.
It does cover Cartesian machines with one joint per axis. And it does cover machines that must manipulate multiple joints to move in Cartesian space but where each joint is free to move unconstrained. But not joints that have more complex rules than max/min linear or angular distance and velocity/acceleration limits.

Implementing such a system would not only help the gantry-guys, but also the hexapod/scara/multiple milling head/etc. people to prevent unwanted combinations of joint positions.

Please Log in or Create an account to join the conversation.

DaBit
Offline
Platinum Member

26 Apr 2014 14:31 - 26 Apr 2014 14:34 #46331 by DaBit

Replied by DaBit on topic Homing a dual-motor-for-one-axis gantry machine.

OK, I have modified homing.c

Wiring is coming along nicely too:

Not done yet (switches, cable chains, much more wiring..), but I can test synchronous homing on my proven BF20 before moving on to unknown territory.

How do I debug this? I would like to see how the code behaves since testing all states in homing.c is not easy. Can I 'printf()/fwrite()' a lot of data to some place?

Last edit: 26 Apr 2014 14:34 by DaBit.

Please Log in or Create an account to join the conversation.

andypugh
Offline
Moderator

26 Apr 2014 17:20 #46333 by andypugh

Replied by andypugh on topic Homing a dual-motor-for-one-axis gantry machine.

DaBit wrote:
How do I debug this? I would like to see how the code behaves since testing all states in homing.c is not easy. Can I 'printf()/fwrite()' a lot of data to some place?

I think you probably want to create some HAL pins to watch the homing state in Halscope:
There are some pins here you can re-define for the purpose:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...96c50febf1617d#l1822
Just change one to watch emcmotStatus->homingSequenceState

You can also add rtapi_print statements, the output ends up in dmesg
www.linuxcnc.org/docs/html/man/man3/rtapi_print.3rtapi.html

Having a terminal window runnning tail -f /var/log/kernel.log can be useful.

Please Log in or Create an account to join the conversation.

DaBit
Offline
Platinum Member

28 Apr 2014 23:20 #46434 by DaBit

Replied by DaBit on topic Homing a dual-motor-for-one-axis gantry machine.

rtapi_print was what I was looking for.

Spent another loose half an hour on the code, and it seems the new code does the trick, at least in simulation:

Apr 28 09:07:53 ubuntu kernel: [203534.602097] homing.c: joint 2 started synchronisation for state 3. NrJointsHoming: 1
Apr 28 09:07:53 ubuntu kernel: [203534.602102] homing.c: joint 2 indicated done for state 3
Apr 28 09:07:53 ubuntu kernel: [203534.745906] homing.c: joint 2 started synchronisation for state 7. NrJointsHoming: 1
Apr 28 09:07:53 ubuntu kernel: [203534.745911] homing.c: joint 2 indicated done for state 7
Apr 28 09:07:53 ubuntu kernel: [203534.745913] Joint 2 in HOME_SET_COARSE_POSITION...
Apr 28 09:07:53 ubuntu kernel: [203535.086419] homing.c: joint 2 started synchronisation for state 20. NrJointsHoming: 1
Apr 28 09:07:53 ubuntu kernel: [203535.086424] homing.c: joint 2 indicated done for state 20
Apr 28 09:07:53 ubuntu kernel: [203535.123394] homing.c: joint 0 started synchronisation for state 3. NrJointsHoming: 3
Apr 28 09:07:53 ubuntu kernel: [203535.123399] homing.c: joint 0 indicated done for state 3
Apr 28 09:07:53 ubuntu kernel: [203535.123401] homing.c: joint 1 indicated done for state 3
Apr 28 09:07:53 ubuntu kernel: [203535.123403] homing.c: joint 3 indicated done for state 3
Apr 28 09:07:53 ubuntu kernel: [203535.268210] homing.c: joint 0 started synchronisation for state 7. NrJointsHoming: 3
Apr 28 09:07:53 ubuntu kernel: [203535.268215] homing.c: joint 0 indicated done for state 7
Apr 28 09:07:53 ubuntu kernel: [203535.268218] homing.c: joint 1 indicated done for state 7
Apr 28 09:07:54 ubuntu kernel: [203535.467921] homing.c: joint 3 indicated done for state 7
Apr 28 09:07:54 ubuntu kernel: [203535.467926] Joint 3 in HOME_SET_COARSE_POSITION...
Apr 28 09:07:54 ubuntu kernel: [203535.468927] Joint 0 in HOME_SET_COARSE_POSITION...
Apr 28 09:07:54 ubuntu kernel: [203535.468930] Joint 1 in HOME_SET_COARSE_POSITION...
Apr 28 09:07:54 ubuntu kernel: [203535.764997] homing.c: joint 0 started synchronisation for state 20. NrJointsHoming: 3
Apr 28 09:07:54 ubuntu kernel: [203535.765002] homing.c: joint 0 indicated done for state 20
Apr 28 09:07:54 ubuntu kernel: [203535.765004] homing.c: joint 1 indicated done for state 20
Apr 28 09:07:55 ubuntu kernel: [203536.321267] homing.c: joint 3 indicated done for state 20

I did not need to remap debug HAL pins; it is clearly visible that joint 3 needs more time to reach the home switch (state 7 is HOME_INITIAL_SEARCH_WAIT). And only when the three joints are done finding the switch the state machine continues.

I implemented synchronisation in the entire state machine, except the latch moves (either with or without using an index pulse). These should be short, low velocity moves and normal trajectory planning should keep the joints in sync during this move anyway. Would this somehow be a problem or limit the use of synchronised moves?

Please Log in or Create an account to join the conversation.

Time to create page: 0.176 seconds