LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Discrete Transfer Function Direct VI

Solved!
Go to solution

Hello,

 

I am having issues utilising the "Discrete Transfer function direct" VI. In the attached VI, a discrete transfer function (for a bandpass filter), and a chirp signal are created. the chirp signal is applied to both the "Discrete Transfer function" and "Discrete Transfer function direct" VI's however only the "Discrete Transfer function" VI gives the correct response.

 

Thank you in advance for any help

 

Josh

 

0 Kudos
Message 1 of 8
(4,133 Views)

Hi jc763,

 

Is there a reason why you want to use both Discrete Transfer Function Direct and Discrete Transfer Function to generate the same response? Maybe I’m not seeing the larger context of your application. I did find another thread that addresses Discrete Transfer Function Direct, perhaps it can shed some additional insight:

 

http://forums.ni.com/t5/LabVIEW/Help-on-Discrete-Transfer-Function-Direct-VI/td-p/3139283

 

I hope this helps!

Ross S.
Applications Engineering
National Instruments
0 Kudos
Message 2 of 8
(4,083 Views)

Hi Ross,

 

Thank you for your reply. The reason I am Impementing both transfer function VIs is simply so that the responses may be easily compared, highlighting that there is an issue with the way the way the Discrete Transfer Function Direct is being implemented. To give some context for the actual aplication, the Discrete Transfer Function Direct VI will be implemeted on a cRIO's FPGA allowing the filter to be applied to an analogue input and passed to an analogue output. I have redesigned the VI to reflect the method used in the suggested post, however the problem is still the same. I have attached this modified VI aswell.

 

Thank you kindly,

 

Josh

0 Kudos
Message 3 of 8
(4,070 Views)

I am currently in the process of installing the appropriate software to work with your code (not sure why I didn’t have this on my machine already), but in the meantime perhaps you can tell me a little bit more about the discrepancy you are seeing between the two methods. When you redesigned the code, did the discrepancy between responses remain similar to your first program or were they new differences?

 

Thanks for the insight!

Ross S.
Applications Engineering
National Instruments
0 Kudos
Message 4 of 8
(4,035 Views)

Thank you kindly for your help. The discrepancy is Identical regardless of the implementation.

However I have found an interesting solution; the DTFD VI reacts as expected as long as the signal amplitude does not increase above 0.01, this could be a solution as the actual system will only receive inputs of a maximum +-10, meaning I could simply divide the input, and then multiply the output by 1000 which then gives the desired response. The downside to this is that you lose 3 decimal points of resolution; however this should be acceptable for my usage.

 

The fact that this solves the issue perhaps implies that there must be some kind of overflow occurring within the VI, however I don’t understand where since all data seems to be at least (fixed-point <32,16> [-3.276800E+4,-3.276800E+4]:1.52879E-5) which unless I understand incorrectly, implies that the data type can handle numbers up to around +-30 000 to around 5 decimal places, which is much larger than the 0.01 limit that is observed. Any thoughts on this?

I have attached a version of my code containing this solution in case this helps anybody in the future.

0 Kudos
Message 5 of 8
(4,019 Views)
Solution
Accepted by jc763

The Issue lies with the feedback loop within the VI overflowing. To rectify this I have redesigned the block with a larger FXP data type, This VI functions the same as the Discrete Transfer Function Direct VI however it is designed to operate at inputs of +-10 (with a bandpass filter and probably any other filters), and has an output resolution of around 1.5E-5, which is more advantageous for most analogue data manipulation than the original VI

0 Kudos
Message 6 of 8
(4,003 Views)
Solution
Accepted by jc763

There is a mistake in my previous VI where I left in an FPGA error handler from the original block that was causing compile errors. The corrected VI is attached

0 Kudos
Message 7 of 8
(3,990 Views)

I’m glad to hear that you figured it out! Thanks for posting the revision.

Ross S.
Applications Engineering
National Instruments
0 Kudos
Message 8 of 8
(3,920 Views)