Difference in calculation between V9 and V16

[Simon-lee]

Hi Folks,

I’ve been tasked with rewriting a Dasylab V9 worksheet in Dasylab V16.

The worksheet is designed to calculate flows from a pitot tube.

All looks good but the program seems to hang on one formula node as described below

( -7.246341e-21 * IN(0) ^ 6 ) + ( 7.874489e-17 * IN(0) ^ 5 ) - ( 3.37131e-13 * IN(0) ^ 4 ) + ( 7.098481e-10 * IN(0) ^ 3 ) - ( 7.247486e-07 * IN(0) ^ 2 )  + ( 2.39727e-04 * IN(0) ) + 1.377192

According to the documentation this is to calculate the specific heat ratio of air and has been lifted directly from the standard.

To me, most of the calculation looks insignificant but I’m assured it did work in V9.

It is my understanding that V9 uses a 32bit float and V16 uses a 64bit double and I suspect that is having an impact.

Can anyone offer any insight or explanation?

Thanks 

[CJ_Butler__DASYLab_Pro]

Looking at a comparison of the data the differences are very small - but there are differences. 

In DASYLab 9 computations are done in double precision floating point and converted to single precision. Any more than 6-9 digits is noise

In DASYLab 2016 the computation is not converted to single, but stay in double. 

What data ranges are you looking at? It's possible that the polynomial coefficients need to be more precise? 

Double precision gives from 15 to 17 significant decimal digits precision (~ 1.11 × 10⁻¹⁶)

Single precision is from 6 to 9 significant decimal digits precision

-7.246341e-21 * IN(0) ^ 6 ) + ( 7.874489e-17 * IN(0) ^ 5 ) - ( 3.37131e-13 * IN(0) ^ 4 ) + ( 7.098481e-10 * IN(0) ^ 3 ) - ( 7.247486e-07 * IN(0) ^ 2 ) + ( 2.39727e-04 * IN(0) ) + 1.377192

[CJ_Butler__DASYLab_Pro]

I ran your function, assuming that the input is temperate, in the range -200 to 800. 

I did it in DASYLab V9, DASYLab 2016 and Python 2.7.

DASYLab 2016 and Python 2.7 are closer than DASYLab 9, but out in the e-9 range, which is where single precision is inaccurate

[Simon-lee]

Hi CJ,

Thanks for all that hard work, I have followed your calcs and you a perfectly correct in the assumtion of tempature and how miniscule the rounding errors are. 

After some experiments today it appears that one channel/inducator is lagging to the point of freezing. I have zipped the program to this post, There are three pitots on the sheet but I've only examined the first one. The problrm appears on the Digital Me00 SHR1 or 1-e1.

The system is running at 5hz, is it possible that the maths is somehow tripping me up.

Regards

[CJ_Butler__DASYLab_Pro · Accepted solution]

That's really hard to check because it may be related to your actual input device. 

I can run in simulation and it **looks** fine, but of course that is just with a simulated input that is varying all the time. 

It is certainly very possible that a nth order polynomial will take time to calculate, but the time stamp is retained.

I would debug by doing one or both of these things:

1. drop a Statistics Counter module into the worksheet, configure it for several channels, and on each channel configure it to count samples or blocks. Then wire before and after the Formula that is doing the polynomial computation. Maybe look at one of the other channels near by as well. Display on a digital meter to see if the count from the polynomial formula is really lagging. 

2. In the Worksheet Global settings (options menu or right click on the worksheet), configure "Determine Module Process Time". Then while running, go to the Options menu and select Determine module process time. A box will pop up with timing information. On my computer, in simulation, the Formulas are not the heaviest process time users. 

[Simon-lee]

Hi CJ,

I’ve had a chance to apply your debugging advice and I’m beginning to understand what’s going on.

It appears that the upgrade to Dasylab V16 was required because IT stopped supporting Windows XP.

The original test box configuration was built around a competitor DAQ that can’t run Window 7 – when the technician swapped out the DAQ for a CDAQ, the speed limitation on the NI9211 was missed.

If I’ve read the data sheet correctly then the 14S/s is an aggregate and with 4 active channels were limited <3.5 hz.

Therefore, trying to run at 5hz I have two tasks running at different speeds, the discrepancy builds, and the system suffers, I have confirmed this hypothesis running at 2hz which worked. Unfortunately, 2 hz is too slow for the operator to control the system.

If there is a software solution I would be very interested but if not then I shall order a faster CDAQ module (NI9212 maybe)

Thanks

Si

[CJ_Butler__DASYLab_Pro]

Good catch. I'm not familiar with the NI CDAQ product line details, so I did not catch that. 

[Simon-lee]

Hi Cj,

Update:

The new faster temperature module arrived today and solved the problem, I’ve even pushed the system up to 10hz successfully.

Thank you for the debugging tricks, without them I wouldn’t have spotted the fault, so I more than happy to call that a win and mark the problem as solved.

Si