RB1-CNC Retrofit

Andy,

Thanks for your well wishes on the damage. I am not to confident yet but we will find out in about a week.

The Pico servo drive requires a common ground between servo motor power supply and logic power supply. See the following sample wiring diagram. Jon has also confirmed this to me.

Sample Wiring Diagram

I will be doing some additional testing to make sure there is not something else in the system that will cause another pop if I tie the grounds together again. I am relatively sure the issue was due to me having + and - swapped to the drive.

I may try referencing the 160V negative earth ground instead. The ATX power supply negative is already referenced to earth ground. This will also keep the path of current flow away from the components supplied from the ATX power supply. If this does not provide sufficient common ground for stability of the servo drive then I will tie the negatives together at the distribution block under the servo drives like I did this last time. I just don't want to blow up any more components. It is way to expensive to do so.

I needed a break from the project anyway. Working on my shed/workshop. Got my concrete floor poured this week. The new home for the machine is under progress.

After waiting a week to get my new motherboard and power supply. I installed them last night. Updated the firmware on the motherboard and booted to Debian Wheezy and most everything seems to be working.

It appears that the voltage spike took out a USB hub I had attached in the control panel and the USB interface on my touchscreen monitor as it will not function anymore. The monitor works fine just no touchscreen. Anybody need a used monitor with no touchscreen?

There is also damage to the servo drive that I will need to have Jon repair it or purchase a new one. So far it appears that the encoders are working fine. There is a resistance from +5V to GND of about 14 to 15 ohms per encoder that I am going to investigate further. They are working but I don't want them to quit working when the machine is running causing further damage from a run away. I am not sure if this resistance was present prior to the incident or not.

If anyone has Heidenhain ROD320 encoders and can check resistance from +5V to GND I would appreciate it.

I have yet to test the hall sensors on the servo motors but I will try to do that today.

I contacted Heidenhain and they said the 15 ohm resistance between 5V and ground was normal as it was the resistance of the lamps.

I tested the hall sensors in the servo motors. They seem to still be working so I am ready to try using the X axis again.

This time I have triple checked my wiring and everything is right. I am able to get out of e-stop and supply 160V to the drive, enable the drive, but the Pico servo amplifier is showing a fault continuously. Still no servo motor power.

I am using a 412Kohm resistor for the current limit this should set the current limit to right at the 7.0A shown on the servo motor data plates.

I am not sure why the drive is showing a fault at this time. If anyone has had this issue let me know.

PS: This is not the damaged drive from the previous incident.

Time for a little update.

I have been able to get the machine back running. The drives start up in a fault but i can now reset them so that I can use them. I have been able to tune X-axis pretty good. It is working well and I can get it to work from very slow speeds to speeds around 200 ipm.

I am having trouble with the Y-axis. Last night I could get it to work at very slow speeds around 20 ipm and slower. It would jerk at those speeds and would sometimes stall and squeal. I was powering the Hall sensors with 5V. I found in the manual for the original siemens simodrive that the voltage supplied to the hall sensors was 15V across a 100 ohm resistor. I figured that the hall sensors could have been working part time causing the issues.

I also took some current measurements for the hall sensors and they pull 0.03A. So there would be 3V drop across a 100ohm resistor. That means 12V would be supplied to the hall sensor itself.

I reworked the break out board that I made for the hall sensors so that they were powered by 12V across a 100 ohm resistor (9V at the sensor). I also changed the configuration of the pull up resistors as they were previously connected to the 5V powering the hall sensors. Now they are pulled up to the 3.3V coming from the Pico servo amps.

Now the Y-axis works better. It does not squeal anymore. It runs pretty good except for some random jerks in the movement were it seems the servo stops momentarily then catches back up. It works for low speeds to medium speeds (around 100 ipm) but it has these random jerks in the movement.

I am considering removing the 100ohm resistors and putting the 12V to the hall sensor direct.

More troubleshooting to go. Do you think it could be noise on the encoder? I am using the differential signal from the encoder so it should be pretty immune to noise also the cable is shielded. I converting the differential to single ended with a part from CNC4PC. Do you think it could be an issue there?

I am getting closer to a working machine but I keep having these hurdles to jump.

I will post a video of the Y-axis tuning on youtube it shows the Halscope plots of following error.

Video of the Y-Axis and some screenshots of Halscope.

Another update.

I had Jon at Pico Systems repair the servo amps that were damaged during the reverse voltage incident. I installed them yesterday and did a little checking on the system. I found the issue with the pulsing Y axis that was shown in the video. The derived velocity had spikes in it when it should not have. The spikes are only present on the Y axis with the new firmware from Pico. Jon is working on trying to figure out why it is happening. He can't reproduce it in his lab so it appears to be something specific to my UPC. More checking to come. The previous firmware is working without the velocity spikes so I am running it for now.

I had to rebuild the counterweight stack for the Z axis as it had become disassembled sometime in it's life. Another surprise I found while working on the machine. Anyway I had to remove the weights one by one out of the Z column then I had to mount up the weight holder to the counterweight chains. Then reload the weights onto the weight holder one by one. All of this working in a hole about 10" x 10" square. What a pain in the rear. I had to make a new bushing to center the guide rod for the weight stack as someone had previously replaced the centering bushing with just a washer that would not hold the guide rod centered.

After reassembling the counterweight, I started tuning the Z axis. It tuned with little problem. Now I have all three axis tuned decently. I will do some more tuning trying to get a little more accuracy but it appears to be working well.

Items still to do. Fix the spindle direction with change from high speed to low speed with the back gear on the spindle. Make the automatic lube pump run when any axis is running. Set up the pico spindle DAC to change the speed of the spindle.

Once I get those Items complete it will be time to make the first chips with the retrofit.

All in all had a pretty good couple of days working on the machine.

I will try to take a video or two this weekend to show the progress.

More progress.

I was able to get my lube pump working. I modified a HAL example that was posted on this forum and add some additional features. The modified HAL file is posted in the HAL examples section.

I also set up a new configuration using gmoccapy. I always intended to use gmoccapy but I did my initial setup on Axis since it was what the example configuration for the Pico UPC board used.

Unfortunately my touch screen is not working so I can't get the full benefit from the gmoccapy screen.

I still need to fix the clockwise and counterclockwise direction based on the use of the back gear on the bridgeport style head. What does everyone recommend for this configuration. Should I use the gearchange component as it has an reverse property and could change the gear ratio with the change in direction. My big issue with gear ratio is the head is a variable speed head so the secondary reduction after the backgear reduction is infinitely variable. Right now I don't have a spindle encoder installed. I plan on it down the road but I don't want to tear the head apart yet.

Anyway I am open to suggestions on the best way to configure the back gear so that it works to correct the spindle direction at least.

I actually ran a sample gcode file tonight and the machine worked great. Of course the spindle spun the wrong direction.

Andy,

Thanks for the feedback. I will get the gearchange component configured tonight for the back gear.

I was contemplating setting up specific "Gear" locations on the mechanical variable speed dial. Lets say Gear1-3000rpm, Gear2-2250rpm, Gear3-1700rpm, Gear4-1250rpm, Gear 5-950 rpm, Gear6-700rpm. Then I was contemplating using several gearchange components one for each "Gear" on the dial. Then I could select the "Gear" in the UI and manually adjust the variable speed head to put the head in the proper "Gear".

I need to use the variable speed head since I don't want to run the factory motor at too low of a frequency with the VFD. This is for fear of overheating the motor since it is not and inverter duty motor. I don't think I want to run at less than 60% of rated speed.

What are others running their non inverter duty motors at.

How much overspeed are you using? I am a little afraid of running the variable speed head at too much overspeed maybe 125% or so.

Since the spindle must be running to change the mechanical variable speed head, what should I do in my gcode to allow the spindle to run then pause and prompt a message to tell me what gear I should put the variable speed head in. It would also be nice if it automatically selected the correct gear in HAL and on the UI from the gcode. Is this possible?