09-24-2010 12:34 PM
Hi..first of all i would like to thank to all NI helpers that in some way give the contribution to help me solving some problems, and tell them that i'm already capable of controling an IGBT bridge with the cRIO that i'm working with.
But, i still have some troubles that i want to solve...i am acquiring signals with my crio that i want to scale, so i can ilustrate the real signal, i'm using an example of scaling from NI in FPGA.vi before sending the data into DMA transfer, the problem is that i'm using voltage probes that reduces the signal 100 times or 1000 times and when i multiply the data by a number that diferent than 1 i starts to get a signal that is not the real one...it appears to get some distortion and i get very high values of my signal peaks, even with filtering and as much as i grow the factor scale my signal representation gets worse.
My signal it's not constant once i'm turning on and off my IGBT's at 25kHz frequency, so it is like a pulse signal, i have applied a DC measurment to read the value and to be the input variable of my pid control. Once again the scale factor is a problem, because i want the setpoint of my pid to be at the same magnitude of the real signal, so it gets easier to the end user to understand and set values. The other problem is that the values that i get from the DC measurment aren't so stable as i wish and because of that my PID becomes instable too.
Finally i would like to know how to tune the DC measurment settings and loop rate to get better results.
I have attached my project.
Thanks in advance..
Mário Silva
09-24-2010 02:03 PM
Are you trying to scale the fixed point numbers or are you converting to a floating point number, like SGL or DBL? Could this be resulting in a loss of significant digits and therefore loss of resolution?
09-26-2010 04:00 PM
Hi rex1030,
thanks a lot for answering, the convertion that i'm doing it's exactly the one that's on the FPGA.vi and again on Host.vi, it converts the FXP number to a Bolean array and right after to a Unsigned Word of 16 bits. I tried to use a convertion recommended on cRIO Development Guide that was converting FXP into SGL and encode it as U32 so it would result in a faster precessing to the Host. Unfortunatly i couldn't get this to work properly, and i never found the reason why 😞
after this convertion the values on the host were to strange and to big, making no sense. As soon as i can i will send you some pictures from my acquirments with the same waveform as different scale factors. By the way, what of these to convertions you think that is the best?? (if the last one i told you really works)
Thanks again
Regards
Mário Silva
09-27-2010 03:47 PM
Well, I don't normally have the fpga do everything you are doing right now. You are using the best crio hardware on the market right now and I haven't had a project I could justify that yet. Usually I just use the FPGA to acquire data and send it via DMA to the RT side and do all the conversions there. I usually record as much raw data as I can and then do filtering and voltage to value conversion in post processing. I really don't have much experience trying to run the filters on the FPGA side, but I know thats where FPGA really shines.
You mentioned you converted to boolean array, then to SGL? Why are you converting to a boolean array. I recommend going straight from fixed point to SGL. When you get the data to the RT side. You can literally do that with the usual native convert to ... vi.
I think one reason a lot of people haven't been posting to help you out is because your problem is pretty low level and specific. Its going to be rather difficult to duplicate your issue without the hardware. Do you have a support contract? Can you open a ticket?
09-27-2010 05:47 PM
Hello rex,
thanks again for your answer, maybe i do not express my self as good as i should to...the convertion to boolean array and then to U16 that i've told you is on the FPGA side, i can't convert FXP to SGL on FPGA side, just on host. In fact i'm using this type of convertion because i took it from the FPGA wizard. It says on CompactRIO Developers Guide that "Each data point needs to be converted from the fixed-point (FXP) data type to a single-precision floating-point data type (SGL). One way to implement this is to send the FXP data across the DMA FIFO and convert it to SGL in the real-time application. It is more efficient, however, to convert the data type to a single-precision floating-point value on the FPGA and encode it as a U32. On the real-time application, type-casting a U32 to an SGL is almost 40 percent faster than converting from FXP to SGL. This simple technique saves valuable CPU resources on the host controller." (page 152)
So you think that i should do the convertions and the filtering on the Host side?? I'll try but i think that, however i have to implement a PID control too, so i don't think that the host processor will handle all the things, including the graphical display of the waves and tha PID reaction.
I didn't understand what you meant with "support contract" and "open a ticket"...
Regards
Mário Silva
09-28-2010 02:24 AM
Hi Mario,
The problem is the conversion you used.
In your code, you translated your FXP value as a U16 bit to bit representation.
Then, you convert the U16 as a single, wich only convert the numerical value of your U16, so, if the FXP to U16 conversion get a 255, the SGL conversion will be 255.
What you need to do, and what is explained in the cRIO developer's guide is to use a special conversion option, wich is accessible at this link.
There, the FXP value will be coded as an U32, but with the bit representation of a SGL value, so the RT conversion will be really quick.
Regards,
Olivier L. | Certified LabVIEW Developer
09-30-2010 10:07 AM
Hi Olivier,
is good to read from you again...i've tried that special convertion that we have talked about and i wasn't succeed once again. I looked for other options on forum and i found one that i include in my code, however the results were not what i expect. I attached my code and a picture from a 30V DC measurement, the value with the convertion that i get from the FPGA wizard seems ok if i scale it with a x10 factor scale, if i scale it x100 or x1000 factor, wich is in fact my voltage probe factor, i got very wierd values even negative values :s
When i look at the values converted with the other two convetion that i've found on forum, they just seemed wrong at all. I think that i'm doing something wrong on the Host side, and i can't find what.
Other question that i want to make is, am i able to run the visulization of the graphs and some convertion under my computer just by putting a vi under it like the one that i got unde the RT?
i'm asking because my Host is getting too slow at graph display and buttons response.
let me give an apologise to you and rex for so many questions.
Thanks a lot for help
Regards
Mário
09-30-2010 01:58 PM
Hey M_Silva
I'm sorry to hear that you are still having issues. I really thought Oliver's conversion suggestion was the answer to your scaling problem.
Ok I've gone through your program and I would like to point some things out. Open your FPGA VI. Your probis probably coersion. See my attatched picture. Those little red dots are bad. They are coersion dots. Your data is being coerced from one data type to another, which when you are trying to maintain precision and resolution, you dont want to leave it to labview to automatically coerce your data into the correct type.
You are going from fixed point to boolean array, no problem. Your problem is the "boolean array to number". It is converting the boolean array into u16, which is an integer. In the same array you are converting from FXP to FXP for no reason, then from FXP to SGL as U32. See how there is no coersion dot there? That means that all the other inputs to the build array are being coerced to SGL as U32. This little mess is so messed up I have no idea what you are trying to do here but I am positive that this is where your problem is, at least one of them. You need to completely eliminate the coersion dots and hover your mouse over each wire to look at the data types and make sure through your process you arent losing precision. I don't believe a U16 can hold a very big number.
You have a lot of stuff going on on this front panel. Are you running the crio headlessly or is there a computer that is always connected to it? In general graphs and indicators can be processor intensive. I would suggest using a tab control and putting the graphs, Acquisition control, Filtering control, and PID all on seperate tabs. If you are running through a computer all the time I would send the data to the PC and have the PC do as much of the work as possible that you have going on on the crio.
PS - You also might want to change the ip of your crio now, seeing how you included it in your project zip and anyone can access it...
10-01-2010 01:30 PM
hello rex1030,
thanks for the answer. Sorry if i didn't exposed my ideas clearly, i understood the coercion problem and i normaly don't have my FPGA code like the file i send to you...What i mean with those convertions was just for to show you and for you to help me understood wich one should i use to get the correct measurements and not the one that are on the picture that i sent in the zip file with the project.
The point is that i'm measuring 100V with a voltage probe that outputs 0,1V(when measuring 100V). And i want to see in my front panel Host the wave like the real one, that means, multiply my acquired wave by 1000. At this moment i'm not able to do that because if i multiply my signal by 1000 i get very wierd values.
About the RT and computer processing question, i'm using the computer always connected with my crio. I was thinking about to put the PID control in FPGA.vi, the variables control on Host(so i can unplug the crio from my computer and the hardware still running ok) and the graohs display on my computer(to show to the end user), what do you think?
I didn't understood the tabs that you've talked about the the ip configuration.
Thanks a lot rex.
Regards
M_silva
10-04-2010 04:16 AM
Hi Guys,
I agree with the comments rex did. But more than the coersion dots, I really think that there is something wrong in the way you convert your datas.
Why don't you want to use the function I gave you ine my previous post?
I have to admit that I didn't understand your explanation about the scaling factor that doesn't work as expected, but there is probably something to see with either your data representation either your conversion.
Before the scaling factor, are the datas good? If they are, and multiplying by 1000 gives bad results, so your data representation is not able to represent datas as big as you would like to.
If they are not good, so there is something in your conversion that is not good.
Regards,
Olivier L. | Certified LabVIEW Developer