controlling an Allen Bradley ultra 3000 (Pico USC)

Hi,

I am looking at replacing my spindle with an AB servo motor powered by an allen bradley 3000 drive. It's a small mill and I've already got the drive and the motor is on the way which will be way more power than I will be able to handle.

Now I need to figure out how I want to interface it to linuxcnc. First off it's a SERCOS drive but it seems that I will able to disable that function through their ultraware software and revert it to a basic drive and/or it seems if I pull off the sercos board it reverts to a basic drive. Still to be confirmed when I have the motor but alternatively will be to buy a basic drive. The basic drive has step/dir input and also analog +-10V

I have a Pico-systems USC and I'm not sure the direction I should take to hook it up.

Option 1, connect it to an axis with step/direction and use the drive's unbuffered encoder outputs as feedback to the USC. So the drive closes the inner loop and linuxcnc forms another loop. Not sure if this is a good idea - I did this with my treadmill motor and never got a stable PID tuning. Another issue is that the drive seems to have step+ step- dir+ dir- for inputs. not sure how to interface the pico to that. Another major question is if the update rate will be quick enough. It has a 2000 PPR encoder and max 4500 RPM which I calculate as 600K steps per second to reach max speed with the USC being able to do 300K I believe. Wouldn't want to push it.

Option 2, use the +-10V for control. This would mean there is no feedback I guess? I think the Pico DAC board replaces an axis? not sure about that. One big problem with this is that my USC is very old and lacks the header for the DAC board. I don't know if that's just a header (which I could add - the holes are there) or if there are components missing. I do have recent firmware on it and was able to test coordinated moves between spindle/axis so firmware wise I think I'm ok.

positioning - since this is for a spindle I would run it in velocity mode I guess? (any recommendations?). I do want to be able to position the spindle for tool changes. I think that I can use the home function in the drive to bring it to a home position which may be enough for my needs although I'm not sure if in velocity mode it would hold that position (no brake on the motor).

If the drive can home to a position for tool changes I think the +- 10V velocity solution seems the most logical. I would probably want to have some feedback since the drive can output the encoder although I wouldn't set up a PID loop to control it.


Any help/suggestions appreciated. Thanks,
John

johntrevick wrote:

Hi,

I am looking at replacing my spindle with an AB servo motor powered by an allen bradley 3000 drive. It's a small mill and I've already got the drive and the motor is on the way which will be way more power than I will be able to handle.

Now I need to figure out how I want to interface it to linuxcnc. First off it's a SERCOS drive but it seems that I will able to disable that function through their ultraware software and revert it to a basic drive and/or it seems if I pull off the sercos board it reverts to a basic drive. Still to be confirmed when I have the motor but alternatively will be to buy a basic drive. The basic drive has step/dir input and also analog +-10V

I have a Pico-systems USC and I'm not sure the direction I should take to hook it up.

Option 1, connect it to an axis with step/direction and use the drive's unbuffered encoder outputs as feedback to the USC. So the drive closes the inner loop and linuxcnc forms another loop. Not sure if this is a good idea - I did this with my treadmill motor and never got a stable PID tuning. Another issue is that the drive seems to have step+ step- dir+ dir- for inputs. not sure how to interface the pico to that. Another major question is if the update rate will be quick enough. It has a 2000 PPR encoder and max 4500 RPM which I calculate as 600K steps per second to reach max speed with the USC being able to do 300K I believe. Wouldn't want to push it.

Option 2, use the +-10V for control. This would mean there is no feedback I guess? I think the Pico DAC board replaces an axis? not sure about that.

No, the spindle DAC add-on board adds an additional output, it does NOT replace any of the four standard axes.

One big problem with this is that my USC is very old and lacks the header for the DAC board. I don't know if that's just a header (which I could add - the holes are there) or if there are components missing. I do have recent firmware on it and was able to test coordinated moves between spindle/axis so firmware wise I think I'm ok.

If the holes are there, then most of the function should work. However, you may need to add two wires on the board to connect SSR1 and SSR2 to the DAC header (P8) if the board is from a certain vintage. Give me the serial # and the board rev # and I will check this.
This applies only to some VERY early versions of the USC board.

positioning - since this is for a spindle I would run it in velocity mode I guess? (any recommendations?). I do want to be able to position the spindle for tool changes. I think that I can use the home function in the drive to bring it to a home position which may be enough for my needs although I'm not sure if in velocity mode it would hold that position (no brake on the motor).

I haven't done spindle positioning, but if you can be happy with it being a bit slow, you could just command the spindle to a crawl speed and then command stop when at the correct position. That will still be done at the 1 KHz servo rate, so you should be able to get accurate positioning from something like 100 RPM, assuming the drive can stop on a dime.

If the drive can home to a position for tool changes I think the +- 10V velocity solution seems the most logical. I would probably want to have some feedback since the drive can output the encoder although I wouldn't set up a PID loop to control it.

This should work.

Jon

The board is Rev 2 s/n #18.

No problem adding the header and some wires from the scr's so that's good news if that's all it will take. (plus the dac board)

If I want to try to position the drive by going at a crawl speed (which would be fine) I would still need to provide feedback to linuxcnc so I would still use one of the encoder inputs for feedback. If that is the case I could just use the axis step/dir output but I don't think it could handle the step rate. I think the drive also supports step up/step down for velocity control so maybe I wouldn't need a high step rate.

velocity control seems to be the way to go for a spindle from what I gather.

I will get the motor in a couple weeks and do some experiments.

johntrevick wrote:

The board is Rev 2 s/n #18.

No problem adding the header and some wires from the scr's so that's good news if that's all it will take. (plus the dac board)

Oh, wow, that is really old. What I'd do first is add
extradac=0x00
to the line
loadrt ppmc_hal

and see if LinuxCNC starts up. if it doesn't you can check the diagnostics to see if it spits out the message :
PPMC: ERROR: board firmware doesn't support 'extra' port\n")

That will tell you if the FPGA firmware supports the feature. If not, I ought to be able to dig up the correct firmware for you.
if it does accept the board's firmware level and export the pins ppmc.0.DAC8.00.value and ppmc.0.DAC8.00.scale, then you will need to add two wires from SSR1 and SSR2 to the DAC header. These were left out of the first run of boards.

Jon

yup, works! value and scale are present

The univstep diagnostics "bus" command shows the board as ver 3. I got an updated firmware from you a while ago.

So that's good news.

Now I just need to figure out if the drive will work and if I want to drive it this way.

Just following up on this in case someone comes across this post in the future and is wondering if it works.

I got the DAC board and wired it up to the ultra 3000 drive and it does work and will control the speed of the motor in either direction. I haven't done anything more than a basic test at this point.

hope this helps someone.