08-19-2019 10:15 AM
In the attached VI, I have tried to add some functionality to keep the "Get Waveform Subset" from throwing errors and warnings all over the place. Maybe I'm just using "Get Waveform Subset" wrong, but it has proved to be very frustrating to use. My current problem is that when my VI is passed a parameter that is very close to either the start or end time of the waveform, I get a warning "1800" saying that one of the limits has been coerced to the start or end time. I am pretty sure I have tracked this down to a floating point error, but I don't know how to fix it.
Should I just ignore the warning (i.e. use a case statement to just clear the error if it is 1800)? That seems unwise because I would also miss any other problems that might cause the VI to throw that warning.
Should I round off the last decimal place(s)? If so, how do I know that the value I round to won't just cause a different floating-point error problem?
Should I do the subtractions in the attached VI with EXT for more precision? How do I know that won't just cause the same problem? The limits are going to be coerced back to DBL when passed to "Get Waveform Subset", right?
I never learned about how to deal with floating-point error, so any help would be appreciated.
Solved! Go to Solution.
08-19-2019 08:15 PM
Some caveats: I've never used the Get Waveform Subset function, so I may be missing something. But I don't understand what you want to do and what the input values mean.
Can you provide an example in the following format:
Actually, point #2, above, might be the Answer to you Problem ...
Bob Schor
08-19-2019 11:28 PM - edited 08-19-2019 11:29 PM
The code you've shared seems fairly reasonable - I'm not sure why you should get an out of range error.
I'd suggest it's possible that either the subVI you've not shared is the cause of the problem (although I'm guessing you only used that to try and correct this problem, in which case, it can't be true (unless you fixed one problem and created a different one...)).
The alternative might be that your "absolute times" are not really absolute. You're presumably calling this as a subVI, but it might be that you'd be better off using Timestamps as the inputs for "t max" and "t min".
Timestamps are a wider datatype than doubles (same as EXT) and perhaps that can cause a problem if you're really close to the same time (because the value will be around 3.6e+9 now, and so changes smaller than perhaps 10^-6 in seconds will get lost/messed up (DBL is ~16 significant decimal figures precision). Using EXT instead might help, but only if you're careful with where they're coming from etc (the values you pass to the WFM Subset are DBLs but only for relative time, so unless your measurement started in 1904 you should be fine 🙂 )
08-20-2019 02:43 PM
Thanks to both of you for your input. It turns out the problem was elsewhere in my code, though I think I will try to add some protective code to avoid this problem in the future.
08-20-2019 04:00 PM
Sorry for the false positive. I got the error again:
Warning 1800 occurred at Start or end time rounded to nearest value in Get Waveform Subset.VI.
Possible reason(s):
LabVIEW: (Hex 0x708) Start time input is not an integer multiple of dt. Value was coerced to nearest integer multiple of dt.
I have also attached the waveform data (voltage from a thermocouple) that was passed to "Get Waveform Subset", and I have also attached the slightly updated version of the VI I previously attached and a screenshot of the probe watch window right after the warning occurred. As you can see, the relative start value requested appears to be zero, but the error says that the start value provided is not an integer multiple of zero; this situation lead me to suspect floating-point error. I have never had to deal with floating-point error before, so I don't know much about debugging it.
03-21-2024 06:19 AM
HI,
have you solved the problem? since it happens also to me. I am acquiring a 1000Hz signal at 5500 S/s and when I pass the waveform to “Get Waveform Subset VI” I obtain the warning. After some test it seems that by reducing the Sample Rate (i.e. 5000 S/s) the Warning seems to be less frequent. Is there a solution maybe in the configuration of the DAQmx read or timing VI or some other parts?
Thank you for the help.
Best Regards,
Zuc