Slaving the second gantry motor (7i92)

I included the .ini and .hal files a bit earlier, I've tinkered a bit but didn't touch the PID parameters, I don't even understand them.

andypugh wrote: It may be that the PID is maxing out. What are the PID limits set to?

Running a step/dir drive in velocity mode with a PID can have some significant advantages, but it does mean that you need PID tuning, just like any other pid-controlled system.

Well, I really really wish I wasn't trying to deal with the extra complexity of a PID. It's super-unfortunate that it's there, but I literally had no other options for figuring out a 7i92 config. I mean, I don't know enough yet to remove it and it's not otherwise working so hard to tell if you're breaking something. Trying to hack it out now would only make the task more complex. Once the system's working fine, well, I wouldn't be so concerned about the PID code being there, even though that would be a better point to try to remove it.

hm2_stepper is quite likely to "just work" with 3 motors, but it isn't set up for a gantry.

git.linuxcnc.org/gitweb?p=linuxcnc.git;a...ca2d40bb1de299885a9f

Alternatively you can bypass the PID in the your existing HAL file, set the stepgens to "p" not "v", connect stepgen,N.position-command to axis.N.motor-position-cmd and so on.

You probably need to learn to understand HAL files at some point anyway.

Or.. Tune the PID.

So you've given a .HAL file there. The .INI file contains a lot of PID-specific stuff. Is the .INI PID stuff totally ignored if the .HAL doesn't use it?

dannym wrote: The .INI file contains a lot of PID-specific stuff. Is the .INI PID stuff totally ignored if the .HAL doesn't use it?

Yes, the HAL file looks for things in the INI file, things it doesn't look for don't get found, but do no harm.

OK, good to know.

Your file used trivkins, not gantrykins. In truth all I need is this to act as a gantry and support independent homing of each side to ensure it will run squared. Is trivkins sufficient?

dannym wrote: Your file used trivkins, not gantrykins.

Yes, I did say that it was for a three-motor system rather than a gantry. But it isn't much to change to make it into a gantry.

andypugh wrote: One thing to be aware of is that LinuxCNC doesn't wait for the second axis to finish homing, so you need to configure so that the final rapid to home is as short as possible or you can have one axis doing a rapid one way while the other is doing a slow search in the other.

This is, admittedly, not ideal.

In this post:

Dual axis homing

Charles Steinkuehler appears to have gotten it working with Trivikins.

also be aware the changes from Charles involve a beaglebone and Machinekit , not Linuxcnc

cncbasher wrote: also be aware the changes from Charles involve a beaglebone and Machinekit , not Linuxcnc

Yes important. I've been trying to wrap my head around gantrykins and join_axis configurations and then I noticed Charles did not use either. In his video, it clearly works as one would hope, both home and the early side/axis waits on the late side/slaved axis.

"... LinuxCNC doesn't wait for the second axis..."

if I understand Andy's comment, this approach appears to solve it with existing well established kinematics.

The Machinekit element may make the configuration files nonportable but to my untrained eye they are still share much of the linuxcnc config syntax so I suspect they could be merged into the linuxcnc world by a kindhearted config expert. The cnc machines are just getting bigger and this approach appears to be going in the right direction - ie no new kinematics code needed.