THC2

Rod

My machine is configured XYZY, I know this isn't the recommended order but is a legacy from the old gantry comp. I'll post my .hal and .ini files when I get on the linux machine, use caution as I have been "playing"" around with then the last couple of days.

John

Rod

Attached you will find my main .hal and .ini files used with the eoffset_pid.comp for the Z axis. Some of the signals will appear to have no sources because they originate in other .hal files.

John

John, thanks I will study and crosscheck this against my config tonight. On a quick glance, I can't see that there is anything significantly different with the eoffset_pid config between you and me.

I am beginning to think it might be that LinuxCNC does not like my XXYZ geometry as I know it caused some grief in Gmoccapy resulting in Norbert making some changes which was followed by some similar activity on Master. This led me to believe that the merge of Joint Axis into master may not be bug free. I might modify the pre-eoffset version to be XYZX and try again.

Hmm,

I ticked off Johns config against mine and I can't see anything different except he had set k=1000 and I had set k=10000. I changed it to 1000, but nothing changed.

I'm certain that my problems are related to bugs in Joint Axis as I've encountered some before. See
forum.linuxcnc.org/gmoccapy/32227-solved...joint-mode-in-master

John has XYZY geometry, I have XXYZ geometry

This works for John

KINEMATICS = trivkins coordinates=XYZY kinstype=BOTH

and it does not work for me. I have to use

KINEMATICS = trivkins coordinates=XXYZ

as kinstype=both won't let me home anything other than joints 1 at a time and I can't see I can change back to XYZ homing even if I go back to an earlier config that does not include any eoffset or THC stuff.

So I think now I will convert my machine's ini and hal files to be XYZY and my partner will have to get used to the home position being in a different corner. It might take a couple of nights and I'll report back.

Well I got 75% of the way through remapping axes and I noticed that the problem was now on a different axes (that I had moved to Joint 3). That told me it had nothing to do with the Z axis offsets.. Then I found a line commented out in my HAL file.

So Tommy was on the money! It was a missing feedback signal but not in the eoffset_pid code, just on a joint config that got broken when I removed the THC code!

So sorry for clogging up all of this thread with my problems. .I'm back in business! And thanks all for patiently helping me see the wood from the trees (or was that the # from the signal?)

So I guess the good news is that 2 of us have now confirmed that the external offset PID stuff will install on real hardware.