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

Not much success using JA4/gentrivkins. Somehow the second/'slave' Y-axis joint motor-pos-cmd stays at 0.

I also still have to define 4 axes?


Here are the config files: dl.dropboxusercontent.com/u/2762301/SnS_configs_16042014.tar.gz.
The original config is XYYZ. I modified the JA4 config to XYZY to see if it makes a difference (it didn't) so they are not 1:1 comparable.
Also: don't mind the very large FERROR, etc.; these allow me to play with MESA hardware, but without without motors connected. This config has not been used on any hardware anyway.

andypugh wrote:

I don't think you should need to, but you do need 4 joints.
I believe it should be [TRAJ]AXES = 3, [TRAJ]COORDINATES = XYZ, [KINS] JOINTS=4.

That works. Somewhere in the process I put AXES to 3, and got an error that there was no joint.3. Must have made a mistake elsewhere.

Try KINEMATICS = gentrivkins coordinates="XYZY"

That doesn't work either. joint.1.motor-pos-cmd is changing, joint.3.motor-pos-cmd stays at 0.

Right now I am retrofitting a water jet cutter that also have 2 servos in the X axis.
After a bit of reading, planning, and considering all options we decided to create a mechanical system that connects both ballscrews to a single motor, instead of having the current two motors.

In this case the decision is probably easy than in your case as the cutting tip does not touch the material to be processed and therefor the motor does not have to make a lot of torque.

The strong points in our decision was:
1 less servo drive
Simple linuxcnc configuration
No homing complication (nightmare)
No possible twisting of gantry (nightmare)

The bad points:
We have to change a bit of the machine mechanics
We will have to use longer timing belts (the original system already use them, but shorter)

micges wrote:

try also not using [KINS] section while loading kinematics.
Use 'loadrt gentrivkins coordinates="XYZY" '

I did that, and also 'loadrt gentrivkins coordinates=XYZY'. No difference; joint.3.motor-pos-cmd stays 0

Ok I've got solution.
1. create file .axisrc in your home directory.

And again: no difference.
motion.teleop-mode is FALSE by the way, and I cannot change it using '$'. I think that the entire teleop/free mode thing is not appropriate anymore when using JA4/gentrivkins?

One more thing: I currently have homing set to 'immediate' (HOME_SEARCH_VEL=0.0) since no hardware is connected yet. Would that make a difference?

emcPT wrote:

Right now I am retrofitting a water jet cutter that also have 2 servos in the X axis.
After a bit of reading, planning, and considering all options we decided to create a mechanical system that connects both ballscrews to a single motor, instead of having the current two motors.

In this case the decision is probably easy than in your case as the cutting tip does not touch the material to be processed and therefor the motor does not have to make a lot of torque.

It depends. In my case most of the torque produced by the servos is used to accelerate/decelerate the rotating and moving mass. Only a very small portion is used for actual cutting.
This is because I am using a highspeed spindle which doesn't produce much torque below 6000rpm and is hardly useable under 3000rpm. So I am limited in choosing endmill size anyway. That doesn't mean low MRR btw: keep the cutter engagement angle low by taking shallow but deep bites and one can increase cutting speed/rpm and feed. Take an AlTiN coated 8mm (3/8") 4-flute endmill for example: 1mm wide/15mm deep cuts at 10000rpm and 2500mm/min (100ipm) feed works pretty well in regular construction steel.

To take full advantage of these 'HSM' toolpaths it does require a somewhat speedy machine though, so a lot of servo torque is used in acceleration/deceleration. And now you also know why I am so happy with rellenbergs improved TP. Makes a huge difference.
Now, I am a shade tree machinist only, but I think this situation is very comparable to your waterjet cutter. Except maybe for the accuracy requirements; I consider the gantry being 0,1mm out of square as 'too much'. And that is pushing the accuracy that can be reached with long timing belts and practical sized pulleys.

No homing complication (nightmare)
No possible twisting of gantry (nightmare)

Yes, and it shouldn't be such a nightmare.
A synchronised homing sequence and a check that the feedback positions of both sides are equal enough should relieve a lot of the pain.

andypugh wrote:

It shouldn't be. I think that micges hinted that Axis had its own opinions on the matter.
Can you set tele-op mode using halui?
(halcmd setp halui.mode.teleop 1)

Yes, I can. And it works; I see joint 1 and 3 moving simultaneously.

But I figured out one thing: the script given by micges does work. I only didn't press 'home all' since I have no homing configured at the moment (hardware isn't there yet). Once I press 'home all', axis switches to teleop mode and all is fine.
If I do not press 'home all', only joint 1 is moving when jogging the Y axis while joint 3 stays at 0.

When switching to teleop mode by setting halui.mode.teleop to true I cannot home anymore because 'must be in joint mode to home'.

Is this expected behaviour? I suspect it is. And if this is expected behaviour, in what respect is JA4/gentrivkins better than master/gantrykins? It is still outright dangerous that the two Y axis joints can be moved independantly. Let's see: 5,5Nm on a 10mm pitch ballscrew translates to a linear force of ~3kN. With an arm of ~750mm that translates to a twisting torque of 2250Nm. In reality it will be less, but it is still a lot of violence....

It might be instructive to try a different user-interface.

I intend to switch to gmoccapy once things are up and running and I have installed a touch screen. Until then I prefer to stay with axis unless there is a good reason not to....