Avon 3000 Mill retrofit

I do like your thinking!
I have been toying with putting an encoder on the spindle. (I have some spindle encoders that was salvaged off Mori-Seiki lathes in a box somewhere) Using the index marker on those should give an accurate rev counter for the MESA and HAL implementation. I would also have a solid encoder for the spindle, should I want to venture into rigid tapping...:thinking

For the record, don't repeat the mistake I made a while back. I mounted the encoder inside the belt drive housing to some shaft driven by gearbelt. If I remember right I used a hal mux switch to select encoder scale according to backgear position. It all worked pretty good, but foiled all attempts at tapping because the encoder was not at a 1:1 ratio to the spindle. I think the big problem was index changed with each spindle revolution.

I figure it would have worked better to drive the encoder at a 1:1 ratio with the actual spindle.

Valuable advice NWE, I will keep this in mind going forward.

I made some progress today. Hooked up all limit switches and the "E-stop out" output.It functions, but I have trouble measuring the output using a multimeter and I suspect it need to be pulled up (using the 7i77D with sinking outputs.
I did manage to run the Default LinuxCNC logo engraving Gcode without the belts connected, and it was good to see the motors doing their thing at LinuxCNC;s command.
Another observation: If I actuate a limit (+vector or -vector, not the overtravel), the control trips the estop circuit, instead of just holding feed in that direction. is this correct?
I am trying to get as far as possible using PNCConf as HAL is still foreign to me.
Next would be to get the rest of the E-stop (including overtravel) circuit connected and tested before I hook up the belts.
Homing on this machine used to involve looking for the -vector switches (could be +Vector on Z) and reversing direction off the limit until the index marker is found. Can this be set up using PNCConf as well?

zoeper wrote:

Another observation: If I actuate a limit (+vector or -vector, not the overtravel), the control trips the estop circuit, instead of just holding feed in that direction. is this correct?
 

 Good question. I have little to no experience with limit switches in LinuxCNC. Hopefully someone else who knows more about this can enlighten us. As I recall, most machines with oem controllers I've worked on generally e-stop when a limit gets bumped. I did find this:
forum.linuxcnc.org/9-installing-linuxcnc...tch-behavior?start=0

I see on your schematic, the machine has overtravel switches wired direct to the master e-stop. How did the original controller act when you ran into a vector limit? I wonder if those were being used as "soft limits"? LinuxCNC has that in software , can be set right in your Pncconf, the top 3 or 4 values for each axis config page. I expect the best way to handle it would be to enter your axis measurements in Pncconf such that LinuxCNC's soft limit stops the axis reliably a bit short of activating the vector switches. With shared homing it will be ok to bump the vector switch for homing.

zoeper wrote:

I am trying to get as far as possible using PNCConf as HAL is still foreign to me.
Next would be to get the rest of the E-stop (including overtravel) circuit connected and tested before I hook up the belts.
Homing on this machine used to involve looking for the -vector switches (could be +Vector on Z) and reversing direction off the limit until the index marker is found. Can this be set up using PNCConf as well?
 

Decide which end of the limit you want to home to, then pick shared home+limit for the associated switch(es). You will also need to specify Home search direction and home latch direction in each axis page. I know LinuxCNC has homing to index, but I don't currently have that bit figured out on my current retrofit project.

I missed the "shared home and limit" option.
Thank you for pointing that out!