Archive for February, 2010

Installed cable carrier

Friday, February 26th, 2010

The cable carrier arrived a couple of days after I ordered it.  I was a little too busy with “real work” to deal with it for a while, though.  With help from Bill at Shaltz, I finally got it installed tonight.  It was pretty easy to install.  First, I removed the T bar from the top of the cart and attached the moving end of the carrier to the T bar (actually Bill did this, since it involved drilling and tapping holes in metal).  I put the T bar back on the cart and started to figure out where to connect the stationary end.  I held it where I thought it should go, then moved the cart from end to end.  I realized I had about 6 extra links that I didn’t need, so I removed 5 of them.  I double checked the new position and drilled a couple of tiny holes in the shelf, then used a couple of small screws to mount the stationary end.  At this point, everything moved very smoothly with minimal effort.  I disconnected the last link from the stationary end and threaded each cable through one at a time.  I had to cut the connectors off to get a nice clean end for threading.  After threading all three cables through, I used a cable tie at the cart end to secure the cables and keep them from moving around.  I reattached the stationary end and put a cable tie on that end as well.  It looks really nice.

Now the down side.  The cables I used seem to be fairly stiff and don’t like bending as much as the cable carrier wants them to.  When I move the cart all the way to the left (smallest carrier radius), there is much more effort required to move the cart either direction.  When I move it all the way to the right, it is much easier to move because the carrier makes a bigger radius.  I am kind of wishing I had selected carrier with a bigger radius.  It would be sticking out above the cart, but the motion would be a little easier.  I just hope the difference in effort doesn’t totally mess up my cart dynamics.  Hopefully it will be a simple force that is just a function of position and velocity and can easily be corrected for.

Ordered cable carrier

Wednesday, February 17th, 2010

After testing the encoders while running the motor and not having any noise issues, I decided it was safe to run all the cables in the same carrier.  I ended up picking the 0202.20-KR28 carrier from KabelSchlepp.  It is wide enough to handle three quarter inch diameter cables, and it is thin enough to fit underneath my cart assembly.  The price for 30 inches of carrier (38 links) is $22.23 plus shipping.  The folks at KabelSchlepp were kind enough to waive the usual minimum order of $50.  I placed the order today and should get it in a few days.  When I install it, I will probably have to remove all the connectors on my cables, then reattach the connectors after threading the cables through the carrier.  Hopefully I will do a better job soldering the second time around.

Pendulum position and speed

Tuesday, February 16th, 2010

I wired up the encoder for the pendulum and ran a few tests.  It was a major pain to solder the wires into the connector.  The connector is so small and light that it slides all over the place while I am trying to heat up the solder cup and insert the wire.  I melted a big section of the plastic connector base while chasing the connector around.  I ended up plugging the connector into the 9411 module to give it more bulk and managed to complete the job.  It is pretty messy, though.  I decided I need to buy a small vise to hold the parts while I am soldering.  This will make it much easier.  I found a few in the $20 range that look pretty good.

Once I wired it up, I tried out a copy of the position and speed measurement routines that I used for the cart.  I quickly found a major bug in the algorithm – I was storing the space measurements as signed values, and when it was changing direction I was averaging large positive and negative numbers, which gives numbers close to zero.  After division, I was getting very large speeds instead of close to zero like I should.  I separated the signs from the magnitudes and everything was good.  I tweaked a few other parts of the algorithm to get very accurate measurements.  I found the pendulum encoder still has a pattern that repeats every four pulses, but it isn’t nearly as bad as the position encoder.  At higher speeds averaging four spaces works very well to give a smooth speed measurement.  At very low speeds, it is better to use single measurement to minimize the delay of the speed measurement.

Once I was satisfied with the measurements for the pendulum, I copied the changes back to the cart routines.  They probably still need a little tweaking since the cart behaves differently than the pendulum, but it should still be an improvement since I eliminated some major bugs.

Current PID first look

Monday, February 15th, 2010

I added PID control for the current to the program.  I used the standard NI PID routine that comes with the FPGA toolkit.  All I have to do is feed in my PID coefficients, setpoint and control variable and it takes care of the rest.  I just added it to the output of my current measurement routine so it updates the PWM value once per cycle.  I also added a switch so I can change between PWM control and current control.

The initial tests are promising.  I made the setpoint alternate between small positive and negative currents and watched the current values as it cycled.  I managed to come up with PID coefficients that quickly reach the setpoint values without going unstable.  The values were small enough that nothing moved.  There is still a lot of testing to go, but the PID control of current looks pretty good at first glance.

Measuring position and speed

Saturday, February 13th, 2010

I wired up the encoder to the 9505 module so I can measure position and speed of the cart.  It is a standard quadrature encoder with 1000 pulses per rev.  Looking at the transition edges, we get 4000 edges per rev.

I started with a LabVIEW example to read the position of the encoder.  This works fine and was very easy to set up.  I also want to measure speed, though, and that gets a little more challenging.  I decided to look at instantaneous speed by measuring the space between consecutive edges.  I started with a routine that outputs the max of either the last space measured (space-1) or the current space being measured.  Including the current measurement helps when the system is slowing down.  I ran the motor at low speed and took a look at the space measurements.  I found out that the pulse edges on the encoder I am using are not equally spaced.  The graph below shows alternating long and short spaces.  The long spaces were about twice the length of the short spaces.  This would make the speed measurements very wild and inaccurate.

Speed - One Pulse

Speed - One Pulse

My second approach was to always average the last two space measurements.  I averaged space-1 and max (space-2, current) to get a smoothed measurement of the spacing.  This worked pretty well and reduced the variation significantly.  The graph below shows there is still a small variation that repeated every four spaces, though.  I realized that the widths of the on and off portions of the A and B pulses were not perfectly spaced either.  I am guessing the on portion is slightly longer or shorter than the off portion of each signal.

Speed - Two Pulses

Speed - Two Pulses

My third approach was to average the last four space measurements.  I averaged space-1, space-2, space-3, and max (space-4, current) to get a very nice, clean space measurement.  This removed all the cyclical variation from the measurements and gave me a nice smooth curve, which you can see in the graph below.  My only concern was that at low speeds with deceleration the delay for measuring true speed could be significant.  The measured speed is always a couple of counts behind when averaging four values.  I decided that when the current space measurement exceeds 40,000 (1/1000 of a second), I will only use the last two spaces.  This trades a little variation for quicker response.  I may adjust this cutoff level later.

Speed - Four Pulses

Speed - Four Pulses

Now that I had a very accurate measurement of the spacing between the pulses, I had to convert it to speed.  I ended up using the new high throughput division available in LabVIEW 2009.  I was able to divide 40,000,000 (total counts per second) by the spacing to get pulses per second.  One nice thing is that the high throughput math works inside a single cycle timed loop.  There is a delay of 29 cycles between inputting the numbers and getting the answer, but that is a very short amount of time when each cycle is 25 ns.  Good enough for me!!!

Now I feel I have very accurate measurements of current, position, and speed.  The next step will be adding PID control of the current.

On a side note, there is no noticeable noise in the encoder signals.  Apparently the combination of shielding and differential encoder inputs is enough to eliminate any noise issues.  This means I can run all the cables in the same track when I get some cable carrier, which will save me a little money.  If there was too much noise, I was considering using two cable carriers in opposite directions – one for the encoders and one for the motor cable.  I need to order the carrier soon, because the cables would get very tangled if the cart moves around much, and I am very close to moving the cart.

Even more current analysis

Tuesday, February 9th, 2010

I thought my plans for scaling the current and calculating the overall current would work well.  The exact factor of two was appealing – until I ran the motor in the other direction.  In that direction, the factor looked closer to 1.8, which totally confused me.  I was frustrated and decided to take a break for while.  In the meanwhile, I continued discussing my issues measuring current on the NI discussion forum.  Yesterday Eric from NI answered all my questions very clearly (see How is NI-9505 current sense measured? for details).  He explained that there are two resistors used to measure the current.  During the On cycle, the resistor that the current passes through depends on the direction of rotation.  During the Off cycle the current goes through both resistors, which makes the measured current twice the actual current and totally explains why the Off cycle was measuring about twice the On cycle.  The different factor for each direction of rotation is because the two resistors have slightly different values.  Once I realized this, I compared the waveforms and found out that for CW my 9505 module has an Off/On ratio of about 2.05, and for CCW the ratio is about 1.95.  Once these correction factors are applied, the On and Off cycles are almost exactly equal for both directions.  Therefore, my current measurement scheme will be:

  • Measure at the center of the Off cycle if the PWM < 30% (to avoid spike effects in small pulse widths) and leave the value as is.
  • Measure at the center of the On cycle if the PWM > 30%, and multiply it by the appropriate scaling factor (CW = 2.05, CCW = 1.95) to get it to match the Off cycle.

This will give me an accurate current measurement at any PWM and either direction.  The scaling factor for the current measurement will be 3.1 mA/count since I will have twice as many counts during the On cycle.

I believe this resolves my issues measuring current, so I can move on to the next step – reading the encoders to determine position, velocity, and acceleration.  I can also start programming a PID loop to control the current.