7i49 and stored position after shut down

I am having a strange homing problem on a mill with resolvers. The set up is 5i23, 7149. I did bring this up on another thread, but after rereading the resolver section on the hostmot driver, I suspect this could be a bit setting in the mesa firmware.

Problem, when homing x&y ,the axis home to the switch, hit it,zero the dro then return to the position they were when they were last on the previous shut down , then zero the dro again and call that spot home.The reason Im thinking this has something to do with the 7i49 is that a resolver can be used as an absolute position device, the machine returns to it last known position, does the resolver reset pin need to be set when the machine see 's the home switch, so it knows not to go to the last parked spot? The z axis oddly enuff, homes fine. PCW, what do you think?Thanks.

JR

I dont think your issue has anything to do with the absolute nature of resolvers as
the absolute count is only absolute for one turn.

If this startup offset survives quiting and restarting linuxcnc, the offset must be stored
in a a file

Thank you, I tend to agree. But what survives and stores a new position after every start up? If the machine is parked on a limit,that is the new home, if parked 20 inches from the home switch, it hits the home switch, then returns 20 inches and calls that home. Truly weird......

I guess the other possibility is that the motion towards home is saved somehow at startup
(and undone later)

This points to a bug in homing or perhaps a bug in the reset/index logic in the hostmot2 driver

Are you homing to index?

Did you apply Andys latest patch? (He mentioned that there was a bug in resolver index handling)

posting your hal file here might help as well

I am homing to index on all three axis and [axis_2](the z) works as it is supposed to. My hal and ini are attached. I have not applied the patch, mostly 'cause I dont know how!! How do I do it? Do I have to move up to the master? Where can I find some instructions to do that? I assume it will need to be compiled?

I copied the index enable line ( in my hal file) from the z axis to x and y, changed the axis/motor numbers and it now works. I have no idea why. It is not the first time Ive run into wonky things in hal, anyone know why a line just wont work sometimes even if it is right?

JR1050 wrote:

I copied the index enable line ( in my hal file) from the z axis to x and y, changed the axis/motor numbers and it now works. I have no idea why. It is not the first time Ive run into wonky things in hal, anyone know why a line just wont work sometimes even if it is right?

What must have been happening is it was set for home to index, but was
failing to find the index and hitting the end of travel stop, which aborted the
home to index pulse search. It shouldn't have shown the axis as
homed, but I gather it did.

OK, I think I see a mechanism how this could happen. The index enable signal
is a weird one, the pins are bi-directional. It requires one function to
set the pin, and another to clear it. Motion sets it at the beginning of
the home to index pulse move, and the Mesa driver clears it when the
pulse is detected, and the encoder count has been set to zero.
Well, due to not getting the command to find the index, it didn't
set the encoder count to zero. But, somehow, the index enable
signal was being cleared, and motion ASSUMED the count was now
approximately zero. It would then fly off to a position that would
be minus that non-zero value.

There may have been a typo in the line,
and it was connecting the index enable signal to something else, or
to its own signal, differing by the typo (zero instead of one, letter i
instead of numeral 1, etc.). You can do LOTS of things in HAL that
are syntactically correct but not what you want it to do. Syntax
errors would give a message and prevent LinuxCNC from starting.

Jon