soft limits different after power cycle

This is my second machine build, but first using Mesa hardware. The first one is in use by a high school robotics team (7 years now).

Getting things working, but I am having issues with what the machine is doing with soft limits on homing after a power cycle.
Yesterday, I got homing working the way I think it should. messed with the machine a while and shut it down properly.

Today, I start it up, home it, then the fun begins! I homed it, but after it did the touch dance, it moves back to where it was on power up, and sets the soft limit there. So if the machine started in the middle of travel range, I now have half the range.
Tried deleting the.var file, and re-started, no better.
Got my son involved. It has him puzzled as well.
To sum up teh behavior, it adds the distance it moved to find the home/limit switch to the home offset, and moves there, which can cause serious problems. It does this on all three axis.
Current .hal, .ini & .var files attached.
This was a fresh install from the live image, updated all, updated to 2.7.11.

Thank you for your help!

Ray

Its your ini file settings. See 3.12 in the homing configuration docs
linuxcnc.org/docs/2.7/html/config/ini-ho...ml#_immediate_homing

Hi Rod. Thank you for getting back to me.

As I understand that instruction, it is a setting for when you do not have limit/home switches. You move the machine to a position you want to be home (by using witness marks or other), run the home all, the system takes the current position as home, and no move is executed.

The issue I am having is:
The moves to find the limit/home switch are correct, the move to index is correct, the final move (offset to home) is getting the distance of the initial move to the switch added to the home offset. (I verified this by setting offset to home to 0)

The first time I experienced this, I had the X offset to home 12.0", and the table as plus of the center (so first move was more than 12"), then when the final move executed, it went past the plus limit switch and crashed into the end of travel.
As a side note, it seems it is still ignoring limit switches at this point.

Ray

Get your limit switches working before worrying about the soft limits. Check in Halshow that the switches are being triggered and then once you know the pin, connect it to the right signal

Its very easy to swap a wire and what you think is say the min limit is actually something else.

The other thing I've had happen when configuring a machines is that LinuxCNC's saved variables get scrambled. Thy deleting the .var file in your config folder. Usually it will be linuxcnc.var.

I verified those were all correct before I started other testing, but just did it again with my son to be sure they are correct.
Tripping each limit switch while slow jogging stops the machine & disables it. Tripping any limit disables the machine.
When the home sequence is in the jog to home phase, none of the limit switches have any effect!
This seems to me to be a bug!

Not a bug. There is an INi file setting to ignore limits when homing. This is required if you have a shared home/limit switch. Check the homing configuration documentation again.

Did you delte the .VAR file?

Deleted the .var file several times over the last two days.

Yes, I understand the "ignore limit switches". I just feel that once the home/limit switch is found it should re-enable the hard limits before doing a move to home.
This still does not explain why the move to home is the home offset plus the move to find the home switch then setting the limit there.

Ray

UPDATE:
I just built a duplicate config with PNCconf, but without the encoders on X, Y ,and Z.

Homing now works as I expected it to work!

So now I think my task is to find where the encoder count is being added back into the home offset, so I can clear it, so it doesn't put the end of travel where the machine was woken up (where the encoders would have a count of zero).

Any ideas are welcome!

Ray

It looks like the PID loop is not wired correctly for encoder feedback

For closed loop with encoder feedback the PID feedback term (and axis feedback term)
must come from the encoder, not the stepgen (the stepgen feedback is not used with encoder feedback)

Can you point me to any tutorials on wiring up the PID?

Ray