Divide bug in Labview?

In labview, if you divide fractional numbers, you end up with a rounding error.
For example if you use quotient/remainder and divide 0.6/0.2 the quotient should be 3, but it is 2 instead. This acts exactly the same as doing that divide and then using "round toward -infinity".

Kier wrote:
OK, thanks.
My solution is to add 0.000001 to the dividend, that seems to work, at least for my application.
This value only makes sense if you use single precision floating point number and the whole part of your number only has one digit. It is meaninful because single precision floating point values have about 7 significant digits in decimal representation. Double precision have about 16 significant digits and you would have to change your number again.
Your value would be to small if you want to avoid rounding errors for numbers having 2 or more digits in the whole number part and the operator to use on this correction would also depend on the operator you want to use for the calculation.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Similar Messages

Serious Bugs in LabVIEW 2011

Dear Sir or Madam,
I have been working with LabVIEW for 10 years.
recently I have istalled the last version (LabVIEW 2011) and encountered some fundamental Bugs as bellow:
1-when I want to close LabVIEW 2011 Platform,it taks about 3 sec time to be closed ! while this was not in earlier version such as LabVIEW 9 sp1.
2-In a typical Front Panel,when I press Ctrl+M to chenge to Run mode,it went but after pressing Ctrl+M again,it will not exit from run mode(THIS BUG HAPPEN SOME TIMES NOT ALWAYS) or when I do right-click to view Function pallet or Control pallet,nothing happen!(THIS BUG HAPPEN SOME TIMES NOT ALWAYS).
I will be happy if you tell me what is the reasons and can I trust on LabVIEW 2011 for big projects or It is better for me to used LabVIEW 2009 as the past.
thank you for your kind attention.
Regards,
Ata Rahai,
Specialist Engineer.

Hi
I believe that 2011 is a very stable version (I was beta testing) and in my system the CtrlM works both ways, always.
Taking a few seconds to close is normal since version 8.0, depending on how many services are running. LV does clean up the system.
greetings from the Netherlands

Bug in LabVIEW 6.1 with Windows 2000 permissions

This is a bug I've discovered when using LabVIEW 6.1 in a multi-user Windows 2000 environment.
After underlying software changes and the like, it is common that when exiting a VI, a message pops up saying that an underlying VI has changed and must be saved. As a regular user, this cannot be done, because regular users don't have write access to the LabVIEW system folder.
When the same thing is done as Administrator, the changes can be saved. In this case, it was a change to a VI residing in the NI-DAQ ai.llb. After the save, the permissions on ai.llb (which by default included liberal access for the Users group) were changed to allow only access by the Administrators group, making it impossible for a regular user
to use that VI or any VI depending on it.
The solution is to manually edit the permissions on the .llb after the save to add the Users group back into the allowed users list.

NI has been keeping fairly up to date on permissions. If you search the entire www.ni.com using Administrator as the keyword, you'll find many of these issues and their resolutions.
2006 Ultimate LabVIEW G-eek.

Find Control in Event Structure doesn't show the object when it is not in the frontmost Tab page [Bug Report, LabVIEW 2012]

When you are looking for the control/indicator handled by a case in the Event structure, you can use the contextual menu item "Find Control" (doesn't distinguish between control and indicator, BTW).
The result is that the control/indicator is highlighted on the FP. The problem is, if that control is in a Tab and specifically in a page of that Tab that happens to not be the frontmost, the only thing you'll see is marching ants, but no control:
<=========== the wrong TAB page was shown. LV did not bother to switch to the relevant one....
In other words, "Find Control" in the Event Structure doesn't switch the tab to the owning page. This is contrary to what happens if you right-click, say, the terminal of this control: the FP will switch to the owning Tab page.
I'd call this a bug and this is definitely an annoyance (which most likely has been around since the creation of the Event Structure).

I did not. Is there any better chance for it to be caught there by a NI eye than it is in the LV forum? I though these threads were deemed to gather bugs/features that had been already acknowledged by NI with a CAR number.
I (and others!) wished there was something like this: http://bugs.sun.com/ or http://bugs.python.org/ for LabVIEW...
I am just coming back from a short conference of scientists who quite uninamously ended up with the conclusion that LabVIEW was to be disregarded as a lab development environment because of maintenance problems (which could have been argued for any language in my opinion, although I think they meant spaghetti diagrams are the natural tendency of students who could not care less as they are not going graduate because of their LV skills or lack thereof), but I guess I could have added my grain of salt and added the complete opacity on bug and feature handling by NI.

I found a bug In LabView 2009!!!!!

When i am using String to Spreadsheet function i observed that there is not effect of "format string" if i declare it as "%.1f", "%.2f","%.3f" and so on. whatever is the input format (Precision) the output will also be of same type. My input data an 2.33545,2.3566,8.56666. I specified "format string" as "%.2f" but my output was same as input. Is this really a bug or not. Anybody help me
Abhimaniu

It's also documented in the LabVIEW Help in the Format Specifier Syntax page:
For functions that scan a string, such as Scan From String and Spreadsheet String to Array, a format specifier uses the following simplified syntax elements.
%[Width]Conversion Code

Serious bug in LabView 8.5 Formula Node

Hello,
Thought I would warn my fellow LabView programmers about a serious error in the Formula Node:
The problem may be encountered by anyone running a non-us LabView installation:
I am located in Norway, and over here we use the comma (,) as the separator in floating point numbers: So, the use 3.14 is written like 3,14.
The problem is that the Formula Node accepts both formats, but only the US Notation is interpreted correctly !
Example:
float64 x1, x2;
x1 = 3.14;    // Interpreted Correctly !
x2 = 3,14;     // Interpreted as 3: One might say this leads to problems.......
Message Edited by geirove on 06-13-2008 06:23 AM
Geir Ove

geirove wrote:
JoeLabView wrote:
Hi Geir,
It is not a bug.  ............
The node does not recognize localized decimal separators."
Of course it is a Bug: **Any** code that **any** compiler does not recognize, should be flagged with an error message ! I have written my share of compilers myself, and they all flag down code that is not accepted as an error.
Failing to do so may cause serious, expensive and very hard to trace errors.
Sorry, but I would expect that the NI team in their 20. year of LabView development is capable of better than this.
Sorry to disappoint you! It's not a bug since that statement is absolutely valid albeit useless in that context.
The Formula Node since LabVIEW 7 supports C syntax except some advanced features such as pointers. In C the comma in expressions is the sequence operator meaning it separates expressions that will be executed from left to right and the last one will actually be the result of the entire sequence expression. This is often used for the initilizer expression inside the for statement, to initilize several variables to a start value.
And the NI team really is a lot better than you think. The online help may be a bit short about the reasons why the comma is not supported as decimal point but there have been many people thinking about this before it was made like that. It was either C syntax support without localized decimal point or some homegrown syntax with localized decimal point and they went for the first.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Bug in LabVIEW 2013 RTETT Download

I've called this in to NI, but am posting it here in case you've downloaded LabVIEW 2013 before they fix the problem.
Downloading the toolkits from ni.com/trylabview usually is a three-step process. First, you download a "downloader", a small program (154 KB) that manages the download of the Installer. When you run the Downloader, it downloads the Installer, usually as an executable ZIP file. The final step is to run the Installer, which first unzips itself into a folder (by default, C:\National Instruments Downloads), then executes the unzipped Setup.exe contained therein.
There is a (usually) consistent naming convention to these various files. For example, the files for LabVIEW Real Time are 2013RealTime-Eng_Downloader, 2013RealTime-Eng (the Installer), and LabVIEW RT (the name of the folder that the Installer "unzips" into). I've downloaded 8 modules, and (with the exception below) they all follow a similar pattern.
The "bug" is in the Real Time Execution Trace Toolkit (RTETT). The Downloader is 2013RTETT_downloader, and it brings in 2013RTETT as the Installer. However, the Installer is set to unzip into LabVIEW RT, the same folder that is used for LabVIEW Real Time. The "fix" is to change the name of the UnZip folder to LabVIEW Real Time Trace Execution Toolkit (this name is analogous to the LabVIEW Desktop Execution Trace Toolkit name for 2013DETT). Alternatively, you can run one installer, rename the folder, run the other, and adjust the folder names to your liking.
Bob Schor

I am using Windows 7 (x64), fully patched. As I understand it, the purpose of the Installers is two-fold -- to extract themselves to individual folders (by default in C:\National Instruments Downloads) and then to run their respective Setup executable to actually install themselves.
I have not (yet) installed RTETT, but I have installed LabVIEW RealTime. However, in the interest of time-efficiency, I first did downloads of all of the elements I wanted to install (which included both RealTime and RTETT), ran the Installer, but only the "extractor", then planned to run the actual installations from the folders in the Downloads folder. That's when I discovered that the folder labelled LabVIEW RT did not contain LabVIEW Real Time, but LabVIEW Real Time Execution Trace Toolkit. Thinking I'd forgotten to extract Real-Time, I tried extracting it again, and discovered that it and RTETT "shared" the same folder in NI Downloads. I fixed the problem for myself by manually relabelling the folders so one was LabVIEW RT (for LabVIEW Real Time) and one was LabVIEW Real Time Execution Trace Toolkit. With these distinctive names, I'm much less likely to install "the wrong thing".
I consider this a "bug", as NI clearly (and logically) intended for the different Toolkits to be downloaded into their own folders. I mentioned it here in case others faced a similar confusion of "Where did my download folder go?". Note that if you only download Real Time or only download RTETT, the "reuse" of the folder name won't matter to you.
BS

Bug? LabVIEW 2009 Enum in Datalog Refnum Loses Data in LabVIEW 2010+

Hi
Can I please get support from an AE?
Attached is a LabVIEW 2009 VI with a Control of an Enum in a Datalog Refnum.
Whereby the Enum's FP Object is represented as an image.
In LabVIEW 2009 this works fine however, in any higher version (I have definitely tested with LabVIEW 2011, but have been told LabVIEW 2010 is the same) the image is blank.
Is this a bug - is data being lost?
Interestingly enough, if I remove the LabVIEW 2009 Enum from the Datalog Refnum then load in LabVIEW 2011 this image displays correctly.
Is there anything I can do (setting? etc...) in LabVIEW 2009 that will correct this problem so it displays correctly in later versions?
This issue originated in this LAVA thread.
Cheers
-JG
Certified LabVIEW Architect * LabVIEW Champion
Attachments:
Datalog Refnum Enum_LV2009.vi ‏10 KB

This was reported to R&D (# 311354) for further investigation.
As a possible workaround, if you move the enum control out of the datalog refnum before saving in LV 2009, when you open your VI in LV 2011 the image will still show up for the enum control. You can then move the enum control back into the datalog refnum and it should work fine.
Thanks for the feedback,
Daniel H.
Customer Education Product Support Engineer
National Instruments
Certified LabVIEW Developer

Erratic date control / bug in LabVIEW?

System: LabVIEW 6.0.2, Windows 2000 or NT4, Norwegian or Danish regional settings (have not tested others).
I have an application (made and built in LabVIEW 6.0.2) where a numeric control with time format is used to select a date...This works fine on 90% of the PCs it is run on...however on some the numeric control has a will on its own...when you enter 10.05.2001 it changes its value to 05.10.2001...and reverse...if you enter 2002 it might change to 2020..11.03 might be changed to 01.03 etc. There is no code writing to a local of the control or anything like that ...the problem seems to be a bug with the control itself.
I have tried to figure out what could cause this...and it seems that if you choose the date format to be s
ystem date you can turn on the problem...This could make sense if the control did not accept too high month numbers in the day input and then to tried to guess the intended input switched the two around...but that is not the case...
Now - is there some regional option or other that can be adjusted to get rid of this...or do I have too build the application again with the control set to use custom format?
MTO

Sorry, I guess I didn't understand the problem correctly. It seems that if you enter the date in a format that is different then what LV is expecting then it tries to fit it the best it can. For example on my computer if I enter the year in 4 digits (2002) and its expecting 2 digits LV will just cut off the last two leaving 20 (obviously not what I wanted). I'm not sure why it would change a valid date that you typed in though, maybe you did find a bug. I would try to narrow the problem down by seeing if the problem is linked to certain regional settings that are set on the problem pc and not on the ones it works on. Sorry I can't be of more help.
Brian

Bug blinking LabVIEW 8.2

J'ai un problème avec la propriété Blinking sur les booléen classique avec LabVIEW 8.2.
Quand cette propriété est active le texte du booléen n'est plus visible. En revanche si on utilise un booléen moderne la propriété fonctionne normalement.
J'ai pu vérifier qu'il n'y avait aucun problème en LabVIEW 7.1.1.
Ci-joint l'exemple qui démontre ce problème.
Attachments:
blinking.vi ‏10 KB

Bonjour,
Ce bug été constaté et sera corrigé dans une prochaine version de LabVIEW.
Cordialement,
ClémentG

Reproducible and critical bug in labview 7.0 (test VIs included)

In upgrading from 6.1 to 7.0 recently, I've found a bug in at least the Linux and Windows versions of LabView 7.0.
I have verified the bug on Windows XP as well as RedHat 8.0 (with a 2.4.24 custom kernel).
As a part of this post, I am including a tar-gzipped set of three VIs that demonstrate the bug described here.
The synopsis (refering to 3 included tar-gzipped VIs):
- lv-bug1.vi has a three clusters with similar contents
- lv-bug1.vi passes the contents of cluster1 to lv-bug2.vi and to lv-bug3.vi
- lv-bug2.vi increments one of the integer fields in the cluster and then returns the resultant cluster to be displayed in lv-bug1.vi's cluster2.
- lv-bug3.vi also increments the same integer field in the EXACT same manner to be displayed in lv-bug1.vi's cluster3.
What you will notice first off:
1. The incremented integer field is indeed incremented
in both returned clusters.
2. In lv-bug2.vi, none of the other fields will be carried through to cluster2 (change them as you will, these changes will not go through).
3. In lv-bug3.vi, ALL of the other fields will be carried through to cluster3
4. If you open up the panel of lv-bug2.vi, everything works as expected (ie. all values of cluster1 go through lv-bug2.vi to cluster2).
5. If you close the panel of lv-bug2.vi again, cluster2 does not receive any new changes of cluster1.
Some more details:
In both lv-bug2.vi and lv-bug3.vi, the steps are:
1. copy input to output
2. increment said integer field in the output cluster
- This increment is done by (abstractly):
output->intfield->property_node->value =
input->intfield + 1;
3. The only difference between lv-bug2.vi and lv-bug3.vi is that lv-bug3.vi has a Reference to some other unused control. This control is unwired and its Reference is also unwired. I find that as long as I have a Reference on the diagram to anything (be it to the one of the clusters or something else), the VI functions properly. But in the case of lv-bug2.vi, where there is no Reference to anything, the values are not correctly copied from the input to output.
Attachments:
lv-bug-files.tar.gz ‏24 KB

I agree it is a bug since the subVI should return the content of untouched cluster elements and behave the same with panel opened/closed.
However, you have to know that indicators (on FP) and terminals (on BD) are not exactly the same thing in a VI. Controls are graphical objects to display data. Terminals hold data in the block diagram. They are related as the Control usually displays the Terminal data, but LabVIEW tries not to update the Control unnecessarly when the front panel is closed or otherwise not visible.
But they are not exactly the same. For example take the working lv-bug3.vi and make it reentrant. You'll see that it doesn't work anymore. The Control has been incremented on the front panel but the subVI outputs the same cluste
r as input. That is because when you make a VI reentrant, the Terminal is disconnected from the Control. All instances of a reentrant VI share the same FP and Controls but keep their own terminals. In your code your write a value in the terminal and another in the control since the value property node is a property of the control, not of the terminal.
In your test case (non-reentrant) the bug occurs probably because LabVIEW fails to keep the terminal data and the control data properly synchronized when the front panel is closed.
There is no reason to use the value property node in a non-UI subVI and it should be avoided. The correct way to implement your code is as altenbach showed in his picture: use wires and write output to the terminal.
LabVIEW, C'est LabVIEW

Potential Bug with LabVIEW 2009, Report Generation Toolkit, and MS Office 2003

We have discovered an issue with the above listed software. Specifically this pertains to Print Report.vi in the Report Gen palette. Basically, we have discovered that with Office 2003 installed the VI will error out. We've been using it in an executable, and the executable physically fails (and asks us to report an error to Microsoft). With Office 2007 we don't have a problem. We've tried building the examples into executables, and those work because they are printing HTML reports.
Also, we have converted back to LabVIEW 8.6 and rebuilt the executable and installed and it works perfectly. Its on the combination of LabVIEW 2009 and Office 2003 that seems to fail.

yeah, we had seen that, and been told about it by another user. we tried, to no avail. we still have ended up having to migrate back to 8.6.1 to get the executable to run properly.

Bug? LabVIEW-2009: Boolean wire missing some dots

I opened a VI from someone asking a question on this forum and noticed some missing dots on two boolean wires.
This was opened using LV 2009. It's an Evaluation installation (in case someone is wondering about specifics).
I minimized and maximized the block diagram and the dots were okay.
I don't know if this was already reported.
R
Message Edited by Ray.R on 10-08-2009 06:06 PM
Attachments:
missingLine.PNG ‏45 KB

Ray.R wrote:
LOL! Imagine all the people that would need help if we came up with wireless wires...
Of course we could also ask for underground wires that could be threaded below the diagram for some busy areas where they are not needed.
Message Edited by altenbach on 10-09-2009 02:07 PM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
WireTunnel.png ‏2 KB

Lot of bugs & Crash labview 2012 SP1 in Table control

Run applied vi.
We see lot of bugs in Table control. I fixed some on the right table, but not all.
How fix other?
Thanks in advance, Alex.
Attachments:
NI_BugReport_in_Table.vi ‏30 KB

The attached modification includes a workaround for the ctrl+z bug on the Data Mixer (Not Table). It basically keeps a history of your deleted headers and adds them back in when the user types ctrl+z. Not the most elegant solution, but gives you an example of what you can do to work around it.
You could clean it up by using functional globals instead of shift registers.
www.movimed.com - Custom Imaging Solutions
Attachments:
NI_BugReport_in_Table (Modified).vi ‏49 KB

Bug in LabVIEW UDP Read?

Hello All
With a little modified UDP Sender and UDP reader you can see that there is a problem in LabVIEW UDP read.
Enclosed, you will find a UDP sender and UDP reader, which you can run simultaneously on one machine (the same over the network).
If the UDP Sender sends 60 packets with 138 bytes in each, everything is OK and Receiver receives all 60 packets.
(Note 60*138=8.280 kbytes)
If the sender sends >138 bytes in packets, not all of them are read by LabVIEW!!!
With increase in number of bytes in packet, less and less packets are received by LabVIEW.
E.g. with double amount of bytes in packet (276), half of packets are received (again 276*30 = 8.2k).
I have tried also to reduce the number of bytes and increase the number of iterations.
E.g. 100 bytes in a packet and 82 repetitions is the maximum LV can handle. With increase in repetitions over 82 LabVIEW can receive only 82!!
Again, note 82*100 = 8.200 kB.
From some resons UDP read can read only around 8kB of UDP packets in the Windows buffer.
I need to read much more than that, so I wonder if somebody has a losution for this.
thanks in advance
Pawel
Attachments:
UDP Rx Tx.zip ‏28 KB

Hi again
I have just checked it.
It is not the LabVIEW problem, it is a Windows buffer problem.
When I read data very fast, before this 8k buffer is filled I can read all the data.
So I guess it solves my problem , I just need to make a loop and queue and pull data from there. As simple as that .
cheers
Pawel

Divide bug in Labview?

Similar Messages

Maybe you are looking for