Converting a Boxford 250B

I just got the old USC card running with LinuxCNC.
I had to update the install to 2.6.
Now it does not crash anymore.

I installed resistors where the relay coils would be on the USC.
Then LED8 lights up when I turn machine on. I take that as a good sign.

The config I downloaded is for a mill.
Which is OK for the old USC as I want to use that on my mill.
So installing on another PC is still on. But before preparing a PC for the mill I will have the lathe running.

Reconfiguring it for lathe should be mostly removing stuff from the mill files I suppose?

And there are some things that needs to be done so it will run the 2.6 instead of the old one.

Things looks a lot brighter today.

Been away for some time on this. But did some the last few days, and hope to be able to hook it up to the hardware soon.
I was Haunted by following errors, but now it's up to the same speed as the original Controller, but it will throw a following error if I try to accelerate as quickly as the original. I have to fiddle about With that.

The stepper Controller manual specifies a low time of between 5us and 25us. That means that at rest the signal should be high. So I have to invert the step signals from the USC card.

Note to self: this may be useful when I shall Interface the spindle Encoder: www.linuxcnc.org/index.php/english/forum...-encoder-on-pico-usc
Is Encoder 3 a good Choice for this? It seems Encoder 1 is free since I have no Y axis.
I may need another "axis" for the tool changer if I don't run that from a microcontroller Board.

Please look at this video: Y axis jogging.

1. It sounds like it's stuttering. I thought the Universal Stepper Controller would not do that. Also this PC have quite good latency numbers.

The axis also stalls out at quite a bit lower speed than the old Boxford controller. I assume this is caused by the stuttering.
How do I fix this?

2. At the end of each move it sounds like a chicken. I played around with the PID settings and is above 100 for the I term! From previous experiences this is extremely high! But it seems to help kill the "chicken" somewhat earlier. It could go on for a minute before. What are sensible numbers for this.

One problem I have is simply understanding the concept of a stepper being a servo and needing a PID. Since the ecoder readback is just a copy of the step generator there should always be no error. But it seems this is not the case.

I got some very prompt support from Jon Elson at Pico Systems, and now the stuttering and chicken is gone!

Now X and Z is behaving well as far as I can judge. Have to tune speed and accel though.
I will share the configuration and document connections when all (or most) things are level here, in case someone else come across one of these fine lathes.

Next one up is to connect up the VFD inputs to get the spindle running. The VFD did spread copious amounts of HF noise, so I routed more GND through the machine using thick fine stranded wire.

Status now is it moves in Z and X. It does not have a steady note while stepping, but it seems not to loose steps. I'll hook up the logic analyzer to the step inputs later to check this. It could be mechanical.

Also the spindle reacts to speed commands, although running the opposite direction. I'll have to look for how to invert motion.spindle-reverse. Probably just swapping 2 phase leads to the motor is the easiest way.

I started trying to control the tool changer using the Boxford Lathe ATC toolchanger component. But it causes a following error. I connected it's output to a PID input and it seems the PID does not like a step input. I tried to pipe the output through limit3, but could not see any difference. Maybe just not understanding how to set the max values in limit3.
If I just run it as A axis I can G1 A<number> or jog and it moves as commanded.

I started trying to control the tool changer using the Boxford Lathe ATC toolchanger component. But it causes a following error. I connected it's output to a PID input and it seems the PID does not like a step input. I tried to pipe the output through limit3, but could not see any difference. Maybe just not understanding how to set the max values in limit3.
If I just run it as A axis I can G1 A<number> or jog and it moves as commanded.

Are you are using the component I wrote as per below?
wiki.linuxcnc.org/cgi-bin/wiki.pl?Contri...oolchanger_component

If so, what output are you connecting to a PID, and why?

It is designed to take over the stepgen for the ATC and output commands directly via a similar link to this
net apos-cmd toolchanger.0.position-cmd => stepgen.3.position-cmd

The hal line
net apos-fb stepgen.3.position-fb => axis.3.motor-pos-fb
has to be commented out or you will get following errors.
Because axis.3.motor-pos-cmd is not connected to anything it will be 0. Therefore it will see any value other than 0 in axis.3.motor-pos-fb as an error

A specimen set of hal connections are in the header of the comp file

regards

Yes, that's what I'm using. And I connect it to a PID. sjaavik.no/linuxcnc-dev/univstep/BoxfordHAL.pdf
The connection marked with question marks is connected so it replaces axis.3.motor-pos-cmd.

This is the connections when I gave up yesterday: sjaavik.no/linuxcnc-dev/univstep/halshow.txt

Since I'm using the USC my understanding is it has to go through a PID.

My understanding is that the toolchanger code issue the full move immediately, so the PID sees a step to the target position.
But of course much of my problem is I don't know much about the internals of LinuxCNC. I pretty much have to find that out by observing the pins. The stepgen component will do the accel/run/decel as far as I understand it.

If I connect it as A axis (as the .PDF shows) I can change to next tool position by G1 A<current pos+distance to next tool+fudge> F2000. Then go back <fudge> to engage the pawl using a new G1. So although I don't fully understand the existing code, it should be close if the output can be made to act like the G1 output.

Hi

The toolchanger outputs moves in a manner similar to using a MDI command.
However the axis is defined as linear, because the ATC will only rotate in one direction and if you leave it as rotary, linuxcnc will try to take a shortcut backwards when that is a distance less than 180 degrees.

It monitors the progress of the command and does not do anything until the actual position equals the commanded one.
Linuxcnc will take care of acceleration and deceleration within the settings in the ini file for the axis.

If you have a stepper powered ATC I do not see what having a PID component connected is supposed to do, the toolchanger takes care of all the required movement at the velocity and acceleration set for that axis

regards

Yes the PID have caused me lots of headache! But it's what the USC and ppmc driver requires.

Anyway I just got somewhere! My theory was that this axis is partly disconnected from the guts of LinuxCNC. And by giving feedback through axis.3.motor-pos-fb without honoring the axis.3.motor-pos-cmd there must be an increasing discrepancy inside the motion software. So I disconnected the axis.3.motor-pos-fb too. (As per Your indication) And now at least it does not throw any following errors. A side effect is the A DRO stays at 0. Not a big deal.

Now I need to be able to jog the ATC so I can back it up against a pawl thus homeing it. Or better even to be able to have it home when I click Home All. I have not connected the jog inputs of the toolchanger component to anything. And I don't know what to connect them to. Is there a way to hook the + and - buttons in Axis to the toolchanger without involving the parts of LinuxCNC that deals with A? As it is now I can press them without getting a following error unless I set the jog speed really high. But of course the ATC does not move.

Just updated: sjaavik.no/linuxcnc-dev/univstep/halshow.txt

This ATC have a sensor. I hope this can be used to home the ATC. Similar to a linear axis, og forward past sensor, back up to motor stalling against pawl. I assume I can define internal variables as pins so I can observe them while debugging?

BTW: Is there a better way to put the file resulting from compilation of a comp than manual copy to my user lib Directory?

Einar wrote:

My theory was that this axis is partly disconnected from the guts of LinuxCNC. And by giving feedback through axis.3.motor-pos-fb without honoring the axis.3.motor-pos-cmd there must be an increasing discrepancy inside the motion software.

As I said a couple of posts back.

ArcEye wrote:The hal line
net apos-fb stepgen.3.position-fb => axis.3.motor-pos-fb
has to be commented out or you will get following errors.
Because axis.3.motor-pos-cmd is not connected to anything it will be 0. Therefore it will see any value other than 0 in axis.3.motor-pos-fb as an error

Now I need to be able to jog the ATC so I can back it up against a pawl thus homeing it.

The toolchanger backs against the pawl to lock into position on each toolchange.
You don't need jog for that.

I did write a jogging function whilst I was testing, just to move the axis until I got the move increments correct so that each tool number locked back correctly.
In normal use it is not required, I removed it from my lathe.

You could achieve the same if you had to, by connecting stepgen.3.position-cmd and axis.3.motor-pos-fb through 'switches' which toggle between the toolchanger and the stepgen as the source of the input.

This ATC have a sensor. I hope this can be used to home the ATC.

I don't have a sensor on the ATC, it was fried, along with most of the low voltage stuff, when I got the lathe.
The toolchanger works by waiting for the A axis to home (done automatically without movement in the ini file when the other axes home)
It then sends a message to change tools to the current tool
A MDI M6T1 for example, will set the current tool to T1 without any movement and from there on the toolchanger knows which tool is operating

If you want to implement automatic indexing to the sensor, look at the component I wrote for the Triac in the same section of the wiki.
It is quite simply a question of rotating the ATC until the sensor pulse is detected and then in your case rotating back to lock the pawl.
Then you have to send a toolchange command, which will be ignored because it matches the current tool in the toolchanger data and Axis will be updated to match

BTW: Is there a better way to put the file resulting from compilation of a comp than manual copy to my user lib Directory?

comp --install toolchanger.comp will install the resultant toolchanger.ko in the right lib directory, dependent upon what your system is and what it detects as the right one
(.../rtlib in a 2.6~ RIP and /usr/realtime-xxxxxx/lib/linuxcnc in an installed version of 2.5.x )

regards