Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

09-07-2019 08:39 AM

Options

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

Solved! Go to Solution.

- Tags:
- Formula node problem

09-09-2019 08:29 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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^{−16})

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

Measurement Computing (MCC) has free technical support. Visit www.mccdaq.com and click on the "Support" tab for all support options, including DASYLab.

Measurement Computing (MCC) has free technical support. Visit www.mccdaq.com and click on the "Support" tab for all support options, including DASYLab.

09-09-2019 11:59 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

- cj

Measurement Computing (MCC) has free technical support. Visit www.mccdaq.com and click on the "Support" tab for all support options, including DASYLab.

Measurement Computing (MCC) has free technical support. Visit www.mccdaq.com and click on the "Support" tab for all support options, including DASYLab.

09-09-2019 02:41 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

Highlighted
Options

Solution

Accepted by Simon-lee

09-10-2019 04:33 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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.

- cj

Measurement Computing (MCC) has free technical support. Visit www.mccdaq.com and click on the "Support" tab for all support options, including DASYLab.

Measurement Computing (MCC) has free technical support. Visit www.mccdaq.com and click on the "Support" tab for all support options, including DASYLab.

09-12-2019 09:09 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

09-12-2019 09:59 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

Measurement Computing (MCC) has free technical support. Visit www.mccdaq.com and click on the "Support" tab for all support options, including DASYLab.

09-18-2019 02:53 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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