Labview PID

[Benvalet]

Hi All,

I just customized the PID from NI example finder for my use. I am implementing the pid in 7833R target (the pid reside in the target). The yellow wave is the wave sent directly from Rigol funtion generator to the oscilloscope whereas the blue wave is the output from the pid. However, I get spikes at the point where the signal wave crosses the zero values (see the attachment). What could be the reason for this and how can I solve this problem? Any clues please?

My second question is, from labview, the NI PID is not compatible to the target. Does NI has a PID that can be implemented directly in the target?

Thanks.

Kind Regards,

Opuk

[GerdW]

Hi Opuk,

I just customized the PID from NI example finder … What could be the reason for this and how can I solve this problem?

The reason might be your customization. Solution would be to clean up the customization… .)

from labview, the NI PID is not compatible to the target. Does NI has a PID that can be implemented directly in the target?

There are PID functions available for RT and FPGA - atleast after installation of the PID (and Fuzzy) toolkit…

[ZX81]

Looks more like a hardware glitch to me...  What are you using for the output (and amplifier)?  Can you probe before the amplfier?  And can you chart the PID input & output in software?

The output is very noisy, which is the first clue.  And the glitch is positioned a little offset from 0, on the trailing side of each transition.  That's common for a push-pull amplifier when it switches between the NPN and the PNP output transister operating range.  Commonly, a capacitor and/or resistor to ground can reduce that.

[Benvalet]

Hi GerdW,

Thank you so much for the prompt response. Now, even if I use the PID from NI example finder without any customization, I still experience the same problem.

I have installed the pid and fuzzy logic toolkit but it seems I cannot still get access to PID subvi. An error window is generated (see the attachment). I used the NI Academic Site License suite (2011) cd for installation. Is there away out of this?

Thank you.

Kind Regards,

Opuk

[Benvalet]

Hi ZX81,

Thank for the response. For my output I simply use an oscilloscope. I generate the wave from a function generator and branch it, 1 to the oscilloscope directly (yellow signal) and the other is read via target and processed using the pid before the signal is fed to analog output channel that is sent to the oscilloscope (blue signal). So I dont use an amplifier at all in my set up at the moment but will use one though at some time later.

Kind Regards,

Opuk

[GerdW]

Hi Opuk,

did you read the error message? Did you check NI License Manager? Did you call NI to discuss this problem as stated in the error message?

[Benvalet]

Hi GerdW,

Thanks for the response. I managed to solve the license issue with NI. I can now use the FPGA PID, but I still get the spikes though the magnitude has reduced a little bit. I want a zero spike or so. I just cant think of any possible reason that causes the spikes.

Is there anything I can do to stop this? Any clue?

Thank you.

Best Regards,

Opuk

[ZX81]

My gut still tells me this is hardware (30 years of experience).  To be sure, can you put a graph on your LabView Front Panel, to see the data?  I suggest you put the chart in a conditional block (on the block diagram), with a toggle-switch to turn it on & off.  Turn it on to collect data, then off to see it & scale it easily.

Another useful test would be to skip over your PID, and simply output a copy of the input.

There are a few things that can cause the glitch that are half-way between software and hardware.  The worst (and less likely) is if the bits for the output don't all get sent to the DAC (Digital to Analog Converter) simultaneously.  If you go from +0 (0x0000) to -1 (0xFFFF), and the first 8 bits get written before the others, there is a moment when you are actually writing 0xFF00 (-256), which is very wrong, and would cause a glitch.  Most analog outputs should have protection built in (the typcial tools protect you from that error).  But if you use some other method to transfer the digital value, that might explain it.  Another problem might be in data conversion (i.e. unsigned vs. signed, or SGL to integer).

Another possibility would be the scope or the probes on the scope.  Try swapping channels (leaving the BNC end of the probes alone, but moving the clips), and see if the glitch switches to the CH1.

What hardware are you using for output?  Have you looked for any known issues for that hardware?

One main reason I still think it's hardware is that the signal is very noisy.  But that could be typical PWM saw-tooth behaviour.  Can you zoom in on the time domain, and see if the signal has a regular pattern (both in the smoother part and the glitch)?

I'm curious why the PID is outputing a scaled duplicate of the input.  It looks like you have a constant setpoint, sinusoidal process variable, and no or very little 'I' or 'D'.  That makes a good test case.  Is that all it is, for now?

BTW, I'm glad to see you have the license take care of.  I just looked, and the PID for FPGA is part of the FPGA Module (not Fuzzy Logic/Controls).  It's in FPGA Math/Control.  It may not show up for every FPGA (because it uses 'float').

A possible (but very unlikely) software cause would be that the data types are a mix of integer and unsigned.  -5 converted to unsigned then back to integer is still -5, but in-between it might be 65531, which would do odd things to filters.  Normally, that should give one big spike + and one -, every glitch, which isn't what seems to happen.

[nathand]

Can you show us your code, as well as the PID tuning parameters and the setpoint? I could believe that if your setpoint is 0 (or whatever the midpoint of your sine wave is) and there's some noise on the signal around that point, you might get funny behavior from residual integrated error, or the derivative component if the sign of the error changes rapidly at that point. If your setpoint is in fact that midpoint, then the proportional component of the control will be nearly 0 at that point, so the spikes are likely caused by the integral and derivative elements.

[Benvalet]

Hi Nathand,

Thanks so much for your response. Attached please find the PID tuning parameters and FPGA code. Actually, I am just testing the code with proportional component alone while the integrator and derivative components are zero. Even if I put a value for intergrator gain, the spikes are still present. I know for sure that  I will not use the derivative component in my application.

I tested my hardware with an analog PID with similar set up (only the P gain values) and I found out that there were no spikes at all. So it means my hardwares are working OK. I suspect there is a problem with the NI PID code that is generating these spikes. But I have no knowledge on PID design at all. Any further clues?

Best Regards,

Opuk