Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

How is the NI-9505 'current sense' measured?

Solved!
Go to solution

THE DUMB-PROOF TEST

 

Yesterday we tried what I call the 'dumb-proof test'. In order to demonstrate that the erratic current readings we were experiencing are load-independent, we disconnected the motor and placed a fixed resistor in the CRio-driven circuit. With such a simple configuration, we expected the 'current sense' reading to be constant, independently of the value for PWM duty cycle. 

(In a purely resistive circuit, during high-time, I=V/R, which is a constant, being V the source voltage and R a known resistance). 

 

We tried two different resistors: 15 OHMS and 220 OHMS (with a 15V supply this corresponds to currents of about 1A and 70mA).

We changed the PWM duty cycle from 100% down to 20% at 5% intervals.

 

Surprisingly (or unsurprisingly, should I say), current was not reported as constant by the CRio. At 15 OHMS, a progressive current increase was seen as PWM d/c decreased. The difference between currents sensed at 100% and 20% PWM d/c was about 10% (approximately 900mA vs 1A)!!

Values for sensed current were much more erratic at 220 OHMS. Current ranged between 70mA, irregularly skipping to 30, 50, even 200mA as PWM d/c was decreased. Clearly, this typeof error exceeds the digital error claimed by NI on their datasheet (12 bit sampling for +/-12.7A, which corresponds to 6.2 mA).

An oscilloscope placed across the resistor verified that peak-to-peak voltage (and thus high-time current, we assume!) was exactly the same for all of the tested  PWM conditions.

 

Results didn't change if we sampled the current at 75% of high time instead of 50%, nor if we tried to implement the multi-value average algorithm briefly outlined in the previous post. 

 

Our conclusion is that the PWM drive is regular and reliable. However, there seem to be some [serious?] issues with the way the CRio 9505 performs the 'Trig AI' or 'current sense' tasks invoked by the FPGA.Our results will be forwarded to NI for further investigation of this matter. The only response we have got from them so far is that under no circumstances would we be able togain access or even sight the schematics for the current sense circuit. 😞

Again, we have three of these units and they all perform similarly. A hardware failure is therefore rather unlikely.

 

We would much appreciate some input from anyone out there who has come across similar issues or has more in-depth knowledge on these modules. 

Looking forward to other replies

Cheers

Nic
0 Kudos
Message 11 of 54
(5,984 Views)

Nic,

 

I reproduced the behavior you are seeing.  I want to discuss this with our hardware engineers, however, they will be out next week.  I will get back to you with more details when I have them.  In the meantime, can you post the datasheet for the solenoid you are using?

 

In response to the previous question about the 9 clock delay for the current sense, when you read the current, the FPGA has to communicate with the ADC chip through a serial interface (SPI) and request that the ADC chip take a sample.  This process takes 5 clock ticks plus an additional 100ns (4 clock ticks at 40Mhz).  Hence, 9 clock ticks.  After the current is sampled, it takes an additional time (up to 20 us) for the 12 bits of ADC data to be sent back to the FPGA.  It is important to remember that it takes 20us (roundtrip) to return the data, because the PWM width in the examples is 2000 clock ticks (only 50us).  So, you cannot sample the PWM signal more than twice each PWM period, or more than once at 50% duty cycle if you want to have your sampling only occur during the "on" portion of the PWM signal.

 

I want to make another point, the NI 9505 was designed to be a brushed DC motor controller.  Thus, the current sense circuit was never meant to be the high precision, temperature tolerant, noise immune, calibrated circuit we all have come to expect from the NI DAQ products.  The current sense is meant to be used as feedback to a PI current controller and then to further be wrapped by an outer PID position controller.  After both of these controllers have been implemented the imperfections of the current sense circuit are negligible for motors with more than 500uH of inductance and a continuous current rating of 1.5A or more.  Having said all of that, the behavior you and I are seeing deserves some investigation and I will get back to you with what I find out as soon as possible.

 

Thanks for being persistent,

 

Lorne Hengst

Motion Control Product Support Engineer 

0 Kudos
Message 12 of 54
(5,969 Views)

Thank you Lorne.

 

To clear up a little confusion, there are two of us posting to this thread.  I asked the original question about pre-triggering by 9 clock cycles.  I am now satisfied by the answer.  Is that 9 clock cycle delay true of other signals routed through the FPGA?  (For instance an analog input voltage from a 9201 module)

 

The output of the current sense circuit is still suspect.  The coil I'm driving is a disassembled Ledex B4HD-253-M-36.  The inductance of this coil (operated as a voice coil) is 63mH.

0 Kudos
Message 13 of 54
(5,937 Views)

Estern,

 

"To clear up a little confusion, there are two of us posting to this thread.  I asked the original question about pre-triggering by 9 clock cycles.  I am now satisfied by the answer.  Is that 9 clock cycle delay true of other signals routed through the FPGA?  (For instance an analog input voltage from a 9201 module)"

 

No, that behavior is specific to the current sense circuit in the 9505.

 

Lorne Hengst

Motion Control Product Support Engineer

0 Kudos
Message 14 of 54
(5,926 Views)

Estern,

 

Let me be a bit more specific.  The team I work in developes the NI 9505, that is why I am familiar with how its current sense circuit works.  I am not knowledgable about the 9201, however, I do expect the 9201 to have some sort of bounded delay between when you ask it for a measurement and when it actually takes the measurement.  That delay is most likely less than that of the 9505.

 

I took a quick glance at the NI 9201/9221 Operating Instructions and it shows that the time between each sample (for 1 channel) is 1.25us (unlike the 20us on the 9505).  I didn't see any specifying how long it takes for the sample to occur after the sample is requested, I recommend starting a new thread to ask that question.  My guess (however much that is worth) is that the 9201 delay is less than that of the 9505 (5 clock ticks and 100ns).

 

Also, thanks for sending me the info about your Solenoid.  We are aware that quite a few people are using the 9505 with voice coils and it is nice to have information about the voicecoils being connected to the 9505.

 

Thanks,

Lorne Hengst

Motion Control Product Support Engineer

0 Kudos
Message 15 of 54
(5,926 Views)

Lorne,

 

Thank you very much for taking the time to further investigate this matter. I will be looking forward to receiving more information from you and your technical staff. 

 

The details of our 'coil' are as follows:

 

DCmotor (with brushes), escap 16N28-207E.F16.201

Rotor inductance 0.9 mH

Terminal resistance 40.5 OHMS

Operating at 15V

Max. continuous current 0.24 A

 

Cheers

Nic

0 Kudos
Message 16 of 54
(5,906 Views)

gigiozzi,

 

We are still looking at the issue and have made some progress.  I want to give you an update.  We discovered that the -9 clock adjustment for the current sense is incorrect.  Rather, in order to sample the current during the midpoint of of the "on" portion of the PWM signal, you should wait somewhere between 10-14 clock ticks (thus, it was off by 19 to 23 clock ticks).

 

The behavior you and I are seeing is happening because at low duty cycles we end up sampling right on the rising edge of the PWM pulse and we end up sampling the overshoot of the pulse, which makes our current seem really high.  If your duty cycle was low enough, you would actually end up sampling before the high pulse even began (thus measuring a current of 0A, assuming a non-inductive load).

 

We are still looking into the issue and in the next day or so I should be able to give you a more detailed report and suggest some steps to take to resolve the problem.  Until then, adding a 10 tick (40MHz clock) delay to your call to the current sense I/O node and removing the -9 clock tick adjustment in the PWM loop should help tremendously.  See the attached picture.

 

 

 

Lorne Hengst

Motion Control Product Support Engineer

 

 

Message 17 of 54
(5,855 Views)

That helps me.  I had played around with that trigger delay back when I first noticed strange current sense behavior and found that my current loop seemed more stable with with a small delay in there.  Thanks.  I'm looking forward to hearing what else you discover.

Ethan

0 Kudos
Message 18 of 54
(5,852 Views)
Solution
Accepted by EthanStern

All,

 

First off, I want to thank everyone for being persistant, thus, persuading us to take a closer look at the current sense behavior of the NI 9505.  We have found a few things that need to be changed.  This will be a long post.  I will follow the post up with a knowledge base (KB) (it will take a week or longer to write the KB properly).

 

It turns out there were multiple issues causing the "incorrect" current readings (that is in quotes because the reading returned was always correct, just at the wrong time).  So, let me talk about each issue individudually and at the end I will talk about how to resolve the issues (with some example code).

 

Issue #1:  There is an undocumented 170ns delay for the Motor I/O node.

For various reasons (propagation delay, time neccessary to turn FETs on/off, etc.), if you ask the Motor signal to change states on the 9505, it takes approximately 170ns for this to occur.  This will be added to the documentation.

 

Issue #2:  There is an additional 750ns delay (also undocumented) for the Motor I/O node for rising edges.

This additional delay only occurs for rising edges, and is neccessary to give the H-Bridge controller enough time to change the control lines to the FETs.  This will be added to the documentation.  This issue is really the same issue as issue #3.

 

Issue #3:  All PWM pulses generated will be 750ns (30 clock ticks with a 40MHz clock) less than what is commanded.

The delay discussed in Issue #2 is not propagated to the end of the pulse.  In other words, if the rising edge of the pulse you send to the 9505 is at t=0ns and your falling edge is at t=1000ns, then the pulse that is generated will have a rising edge at t=920ns (0ns+170ns+750ns) and a falling edge at t=1170ns (1000ns+170ns).  So, instead of having a pulse width of 1000ns, it will actually be 250ns.  A 50% duty cycle with a PWM period of 50us, that means your on pulse will be off by 3%.  The good news is that the attached code compensates for the 750ns delay by adding an additional 30 clock ticks to the desired pulse width, so that the resulting pulse is correct.

 

Issue #4:  The Current Sense I/O node actually has 6 clock ticks plus 150ns (or 12 clock ticks with a 40MHz clock) of delay.

It was found that the specificaton for the delay of the current sense I/O node is incorrect.  Instead of 5 clock ticks plus 100ns of delay (max), it is 6 clock ticks plus 150ns of delay (typical).  The specification will be updated with the correct values and will also include minimum/maximum/typical delays, instead of only the maximum delay.

 

So, if you take all of that into account, the incorrect current readings are happening for two reasons...

Reason #1:  The shipping example code samples the current at the wrong time.

The shipping example tries to sample the current halfway through the high pulse of the PWM signal.  Simply measuring the current 9 clock ticks before we actually want the sample to be taken does not take issues 1-3 into account, and incorrectly compensate for issue #4 (it should be 12 clock ticks instead of 9).  I created code (attached) that takes all of the issues into account, and always samples the current within a few clock ticks of the halfway point of the on pulse.  Something similar to this code will be used in a future release.

 

Reason #2:  Using a resistor (non-inductive load) to test the current sense circuit causes a problem.

Using a non-inductive load made it easy to see the problems with the current sense circuit.  However, during the first 0-6.25us of the high pulse, the current still needs time to reach its maximum value (due to capacitance in the circuit and in the FETs).  So, even if we have the timing perfectly correct, if your load has little to no inductance and we try to measure the current during the first 0-6.25us of the high pulse, you will not measure Vbus/Resistance, because the current will not have reached steady state by that point.  This isn't actually a problem, it just makes it seem like the current measurement is messed up for low duty cycles and a non-inductive load, when in reality it current sense circuit is measuring the actual current, its just that the current hasn't reached its peak yet.

 

Solution

Copy the PWM loop and current sense loop out of the attached VI and use it in your FPGA code.

 

Important Notes About the Attached Example Code:

1.  The attached VI compensates for the 750ns delay described above.  What I mean is that if you ask for a pulse width of 500 clock ticks at 40MHz, the VI will automatically at 30 clock ticks to the pulse (750ns at 40MHz) so that the resulting pulse will actually be 500 clock ticks wide.

2.  In the 9505 shipping examples that contain the current PI controller, there is code inside that control loop which coerces the PWM duty cycle if the duty cycle causes an "high" pulse that is less than 2us or a "low" pulse that is less than 2us.  In the attached VI, I have moved that coercion code into the PWM loop, so, you will need to remove it from the current loop (as it is not neccessary).

3.  The example is made to work only with a 40MHz clock, if you need a faster or slower rate, you will need to modify the example.

 

Sorry for any grammer mistakes or mispellings, it is late.  Let me know if you have any questions.  Like I said above, there will be a more complete response to this issue in a KB at a later date (and eventually changes will be made to the help files and shipping examples).

 

Lorne Hengst

Motion Control Product Support Engineer

Message 19 of 54
(5,820 Views)

Lorne, 

As you said previously, the current sense circuit in the 9505 may not be the fancy calibrated type of hardware that we have come to expect from NI but your support on this issue went above and beyond.  I really appreciate your efforts and would like to thank you for providing a well researched answer that addresses the fundamental problem.  My control loop thanks you too.

-Ethan

0 Kudos
Message 20 of 54
(5,802 Views)