LabView TabControl Refnum bug?..
LabView 6.0.2 is getting crashed if to create new control (not a VI!), then to create Control Refnum and to drag&drop TabControl into it. Immediate memory fault follows together with LV crash.
However if to assign VI Server Class explicitely by right clicking reference and selecting "Select VI server Class -> Generic -> GObject -> Control -> PageSelector -> TabControl" then everything goes fine. The problem is that I still want to be able to create TabControl's "strict type" refnum in order to avoid type cast while using this refnum, does anybody know how to do that?
Hi,
Place a Tab Control on a VI front panel, then create a reference to the control,this will appear on the diagram. Then you can copy this reference from your block diagram to your VI front panel. It will have the strict typed.
Regards
Ray Farmer
Regards
Ray Farmer
Similar Messages
-
LabVIEW 2011.
I have this LabVIEW template which I use whenever starting a new programming session
It among others, contains an empty menu reference which I check regularly.
Originally I used to initialize this reference at program startup.
One day I decided that I don't bother to set this reference when I do not use the menu system when running the program.
So far so good. One program I had made, worked perfectly when polling this empty reference too.
Then I built an application of this program, and this application also worked perfectly well.
I even left it running on idle (250 ms loop) doing almost nothing for days just because it was no reason to close it until next use.
Though by accident I one day had a look into my temp folder and saw some LV text logfile of quite some size, like 250 MB.
The beginning of that log file looked like this:
#Date: 9. feb 2012 13:06:22
#OSName: Windows 7 Enterprise Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: QuickPlot
#Version: 11.0f2 32-bit
#AppKind: AppLib
#AppModDate: 02/06/2012 15:17 GMT
#LabVIEW Base Address: 0x30000000
09.02.2012 13:06:23.491
DWarn 0xACE16152: CallIsARefnumFunction : bad refnum kind = 9
e:\builds\penguin\labview\branches\2011patch\dev\source\objmgr\OMRefnumSupport.cpp(51) : DWarn: CallIsARefnumFunction : bad refnum kind = 9
minidump id: dde0e1e2-4980-48c5-bffb-de98be10a344
0x30074773 - lvrt <unknown> + 0
0x307D2E50 - lvrt <unknown> + 0
0x30672298 - lvrt <unknown> + 0
0x30628C9C - lvrt <unknown> + 0
0x041AA76C - <unknown> <unknown> + 0
0x046C9258 - <unknown> <unknown> + 0
0x3090DB00 - lvrt <unknown> + 0
0x0000E8EC - <unknown> <unknown> + 0
... and repeating...
Of course, the item that drew my attention is the line saying: "CallsARefnumFuncion: bad refnum kind=9"
Through some investigation I finally found out that that warning was due to the checking of the empty menu reference.
Every 250 ms the LV runtime system hit that reference and added some lines to that log file.
I feel this must be some kind of bug since that this only happens when running a built application, not when only running the development system program.
And of course it's an annoying bug if that log file gets a chance to grow GB big an maybe crash a whole computer.It's simple as this. LabVIEW 11 executable and VI and LV8 VI.
Attachments:
Menu ref bug executable.zip 128 KB
Menu ref bug.vi 8 KB
Menu ref bug LV8.vi 8 KB -
Labview 2012 DLL bug need solution
DLL initialization routine failed error for lvanlys.dll..........Should be located in resource folder
When you place a sinewave generator vi on a vi call library function node error: library not found or failed to load.
Have viewed LV bug list. Did not find this bug.
Can you provide a patch to fix problem. Have all updates and problem not solved
Regards
Michael RyanI must not have your toolkit....
All I see is "Sine Waveform.vi", there is no "Sinewave generator vi" in sight anywhere (see image). Are you really sure about that name? In any case, nothing in that palette generates any errors for me.
You did not say if you tried to repair your installation. What is the exact make and model of your CPU?
When you installed LabVIEW, did you use the default installation locations or did you "personalize" for lack of a better word? Were there any problems during installation? Did you reboot after the installation? What other NI software is installed?
Have you tried other functions? There are plenty of function that use lvanlys.dll. Do all the other functions still work fine? (for example try "A x B.vi" form the Mathematics...linear algenbra palette).
Do other labVIEW program run fine?
wetland wrote:
If it works for you then you are lucky. This is my first bug l have found
This has nothing to do with luck, because in my case everything works exactly as intended. Luck only plays a role with bugs that only occur once in a while when trying to reproduce the problem, but in your case it seems 100% reproducible on your system.
I still seriously doubt it is a bug (and I probably have found hundreds of real LabVIEW bugs over the years ). If it really were a bug, you could post a link in the monthly bug thread. Is is checked regularly bi NI.
To be a confirmed bug, it needs to be reproducible by others (and also by somebody at NI).
To help out, I have tried hard to reproduce your problem, but since your instructions are insufficient and ambiguous it is still not possible. You need to give much more detail!
Does LabVIEW create a crash report? Is there anything interesting in the Windows 7 event viewer?
Have you checked your computer for viruses and malware? What antivirus program are you using (maybe it triggers a false positive reaction on this file).
LabVIEW Champion . Do more with less code and in less time .
Attachments:
SineWave.png 18 KB -
LabVIEW 8.5 Bug Report: VIExecState.cpp, Line 530
This bug seems to restricted to the attached code. Any change to the VI block diagram which in turn marks the VI changed
in the title bar with an asterisk. If I try to run the VI in its
unsaved state it crashes with the VIExecState.cpp Line 530 error.
This is how I induce the fault using the attached code.
1. Before starting LabVIEW add "DWarnDialog = TRUE" to the LabVIEW.ini file without the quotes.
2. Open "BurnIn Shelf 2 - Shell Only.vi"
3. Click the "Run" toolbar icon code then click "Abort Execution".
4. Edit the block diagram e.g. add a free label.
5. Click the "Run" toolbar icon again.
6. This should induce the VIExecState.cpp, Line 530 error.
As this is a "warning" I have set "DWarnDialog = TRUE" in the LabVIEW.ini before starting labview. This means any warnings not critical to execution are displayed immediately. They are normally kept hidden until you start labview. Unfortunately, things like occurence notification stop working so its critical to some of my code implementations. Remove this entry from your labview.ini if you have finished debugging.
I have not found the source of the issue in my code yet. The error has been reported to NI UK. CAR reference for this error is #45703. I will keep the forum informed of any developments.
David
Message Edited by David Crawford on 04-07-2008 04:19 PM
Attachments:
BurnIn Shelf 2 - Shell Only Folder.zip 893 KB
lvlog04-07-08-15-53-15.txt 4 KBHi David,
Thanks for posting this on the forums so that the community can be aware of the issue, I believe you spoke to a collegue of mine yesterday and in turn he has filed the Corrective Action Request for R&D to look into.
All the best,
Applications Engineer -
Labview screen refresh bug (disappearing VI icons in diagram window)
Hello,
I have Labview 6 (fully patched with just about EVERY download NI offers on this site) running on a Windows NT 4.00.13.81 box. Since this is a screen refresh problem, it might be useful to mention that the graphics card is a ATI 3D Rage Pro (bought in 1999, driver versions 5.2.040, 4.0.0).
I think I've ran into either a Labview or a graphics card driver bug, because the VI icons in the diagram window seem to disappear every time I move the mouse over them. Minimising the window and maximising it again makes them appear (if only someone had included a "refresh" shortcut in Labview I could even learn to live with this!), but the bug persists. Shrinking and reinstating the diagram window co
nstantly is a reasonable way to work.
I cannot remember for sure, but I believe this bug appeared when I patched Labview 6.0 into 6.0.2.
Any help will be much appreaciated, this bug is frustrating and doesn't let me work!I really do not want to upgrade to Labview 7 either, as all my work is in 6.0.x and I have no time for major shifts in versions.
Thank you,
-AlexandrosHi Alexandros
I believe this could help:
http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=50650000000800000055550000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0
regards
Pawel -
Hi Everyone,
have found a bug in the labview sound vi's. It is quite a complicated one to explain, but here is my configuration first.
I have a dell precision 390, with a built in sound card on the mother board which uses a "SigmaTel High Definition Audio CODEC controller", I also have a PCI sound card installed in PCI slot 5, a M-Audio Delta 1010LT. The M-Audio card is set in windows xp as the default sound card.
When I open labview (8.5) and run a little labview program I made to control the sound card (soundTest.vi attached), the program runs but no sound is produced. In fact, the program tells me that the sound card is playing (even though no sound is being produced), and because of the nature of the program it just loops continuously forever (until I hit it with the hammer of the "Abort Execution" button). (Note: The sound card is configured properly using its control panel, and the device ID is the correct one. Also windows tells me that there are no device conflicts. And before starting the labview program, windows is able to play sounds using the sound card. Once I have run this vi and stopped it though, windows is no longer able to make any sounds.)
Now here is the funny part. If I close labview completely (the sound card resource is returned to windows control), and I open in windows the Device manager, and disable the SigmaTel CODEC (the onboard card), then Open labview, run the soundTest.vi once (it still doesn't work) and Abort it, then (without closing labview) Enable the SigmaTel CODEC in device manager, and then rerun the soundTest.vi I get an Error message (below), but then if I run it a second time the soundTest.vi program works correctly!
If I close Labview, I have to redo this sequence to get the vi to work again. Also if I restart the computer I have to do that too. I went through many other sequences of doing things to try to get the vi to work, but this precise sequence was the ONLY way to make it work. (I also tried disabling the internal sound card through the BIOS, but that didn't work.)
It's quite annoying to do that everytime you restart labview, and also it took me a whole day to find that sequence to made the vi work!
Does anyone know of a better fix than my one?
Thanks,
Paul.
p.s. The error message was: Error 4800 occured at sound output configure.vi. Resean, Labview: (Hex 0x12C0) Selected Device is Invalid.
Attachments:
soundTest4.vi 26 KBHi there,
I thought it would be quite hard to reproduce this error.
I would like to use the program with the M-Audio card. Because it has multiple channels labview uses multiple ID's for each pair of channels. I am using channels 1, and 2, which has a device ID of 0.
If I want to use the M-Audio sound card I have to go through the procedure above. However, if I use the integrated sound card, the program works straight away with no problems. However, as soon as I change the device ID to the M-Audio card, the program doesn't work and I have to go through the above procedure to make it work.
So in answer to your question, it doesn't really matter whether the PCI card is taken out, since the integrated sound card always works with that program. I only have problems with the M-Audio PCI card. Also as I wrote previously, if I disable the integrated sound card from the BIOS, and reboot, the problem remains, and I haven't found a way to make the M-Audio card work with labview in that situation.
Windows tells me that I have no driver conflicts. It says that both card are functioning normally, and indeed windows is able to use either sound card with no problem, its just labview that has the issue with the PCI card.
paul -
Hi all,
I was told by Mathworks support that LabView writes registries that incorrectly use the Flexlm license manager and would cause problems with any other application that does this. I don't want to have to dump LabView, so can anyone confirm this? This is the email I got:
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, September 28, 2005 12:17 PM
To: Bold, Jason (ALPE)
Subject: RE: Starting up issue
Hello,
Please remember that Flexlm is not our product and that many programs use it to manage licenses. If NI has chosen to put this value in the registry it will cause an error not only with MATLAB but any other product which uses Flexlm. My suggestion would be to contact NI for a fix or continue to use the -c in your startup icon.
If you have any further questions, please do not hesitate to e-mail me back. Please be sure to keep the Thread ID included at the bottom of this email intact when replying to this message.
Regards,
Jason Kuter
Installation and Licensing Specialist
The MathWorks, Inc.
508-647-7000 option 5
[email protected]
----Original Message-----
From: [email protected]
Sent: 2005-09-28 01:09:38 PM
To: [email protected]
Subject: Starting up issue
There is an entry under HKEY_LOCAL_MACHINE/SOFTWARE/FLEXlm License Manager/NILM License Manager.
It has several entries under C:\Program Files\National Instruments\Shared\License Manager\<TBD>
Where <TBD> is "Licenses", "\Bin\mgrd.exe", "\Bin\mgrd.log"
And last but not least one entry that is simply "NILM License Manager"
without the directory. Is there a known conflict between National Instruments Labview (which is what this is) and MATLAB?
Thanks,
Jason
FI ---> PI > E
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, September 28, 2005 9:51 AM
To: Bold, Jason (ALPE)
Subject: RE: Starting up issue
Hello,
You can search your registry for Flexlm (run regedit from Start-->Run) to see if there are entries pointing to other license file locations.
The fact that -c works means that there is another Flexlm application causing the issue. If you are unable to find an environment variable or registry entry then you will have to continue to launch with the shortcut which points to the correct license file location.
If you have any further questions, please do not hesitate to e-mail me back. Please be sure to keep the Thread ID included at the bottom of this email intact when replying to this message.
Regards,
Jason Kuter
Installation and Licensing Specialist
The MathWorks, Inc.
508-647-7000 option 5
[email protected]This is a known issue. Please see document ID# 2XTABK9P.
http://digital.ni.com/public.nsf/websearch/69D774EB126339538625701400662FA6?OpenDocument -
Hello, one of our customers just encountered an execution error in a vi running under LabVIEW 6.1, which doesn't exist under LabVIEW 5.1 or 6.01. I have a simple vi that has two encapsulated For Loops. Two string arrays go in, one goes out of the outer loop. Inside the outer loop the first array is indexed. The string which results from this indexing is compared with all other strings from the second string array in the inner loop. If it matches one of the strings of the second array, it is not outputted, otherwise this string goes through the inner For Loop to the output of the inner loop and from there to the output of the outer loop. The count
terminal of the outer/inner loop is connected to the Array Size of the first/second string array. If the second array is empty, that means that the element in test from the first arry cannot match anything from the second array, so the element in test is send to the output of the inner loop and from there to the output of the outer loop. This works fine in LabVIEW 5.1 and 6.01, but NOT in LabVIEW 6.1. In LabVIEW 6.1 the inner loop is never executed if the count value is zero (which is correct), but the data line running through the loop is not executed either, which is different to what LabVIEW 5.1 and 6.01 do. There, the input string is sent to the output of the inner loop correctly even if the loop counter is zero. The solution is easy - I just have to connect the output of the outer loop to the data line BEFORE it enters the inner loop. But: I don't know if this is a LabVIEW 6.1 bug or if it is supposed to be a feature, but it brings some incompatibility in programming between the
different LabVIEW versions.
Best regards,
GabsiHi,
When a for-loop runs zero times, all outputs are 'undefined' (and should
be).
Besides, how would LV know what the output of a not executed routine should
be?
It might be handled differently in LV5 and LV6, which is unfortunate. In
both cases, the result is undefined.
It's not a bug. It's just something that should be avoided in any LV
version.
> The solution is easy - I just have to connect the
> output of the outer loop to the data line BEFORE it enters the inner
> loop. But: I don't know if this is a LabVIEW 6.1 bug or if it is
In some cases this does the trick. But if the data is changed in the inner
loop, this will effect the results if the N is not zero.
Technically, I think the output in this construction is also 'undefined'.
But LV handles this as expected / desired.
Another solution is to use a shift register. If N is zero, the input is
directly passed through to the output.
Regards,
Wiebe.
"Gabs" wrote in message
news:[email protected]...
> LabVIEW 6.1 If For Loop count terminal is zero then value going
> through the loop is not passed on to the output of the loop
>
> Hello, one of our customers just encountered an execution error in a
> vi running under LabVIEW 6.1, which doesn't exist under LabVIEW 5.1 or
> 6.01. I have a simple vi that has two encapsulated For Loops. Two
> string arrays go in, one goes out of the outer loop. Inside the outer
> loop the first array is indexed. The string which results from this
> indexing is compared with all other strings from the second string
> array in the inner loop. If it matches one of the strings of the
> second array, it is not outputted, otherwise this string goes through
> the inner For Loop to the output of the inner loop and from there to
> the output of the outer loop. The count terminal of the outer/inner
> loop is connected to the Array Size of the first/second string array.
> If the second array is empty, that means that the element in test from
> the first arry cannot match anything from the second array, so the
> element in test is send to the output of the inner loop and from there
> to the output of the outer loop. This works fine in LabVIEW 5.1 and
> 6.01, but NOT in LabVIEW 6.1. In LabVIEW 6.1 the inner loop is never
> executed if the count value is zero (which is correct), but the data
> line running through the loop is not executed either, which is
> different to what LabVIEW 5.1 and 6.01 do. There, the input string is
> sent to the output of the inner loop correctly even if the loop
> counter is zero. The solution is easy - I just have to connect the
> output of the outer loop to the data line BEFORE it enters the inner
> loop. But: I don't know if this is a LabVIEW 6.1 bug or if it is
> supposed to be a feature, but it brings some incompatibility in
> programming between the different LabVIEW versions.
> Best regards,
> Gabsi -
Critical graph scale bug in LV2009?
Put a graph or XY plot in LV2009 on Vista - and set the X scale to be in absolute time. If you do this in LV 8.6 you will now see multiple time stamps along the X axis. In LV2009 you will only get the two at each end.
Fill the graph with data...now you may get 1 extra axis point along the X axis...but never more, regardsless of the axis style, - and its position will either be in the middle or at either 25% or 75% of the full time range. (See attached picture of chart and graph).
I know this is not how things behaved before, but is it a bug? Unless I'm overlooking something it is, and it is a show stopper....I hope it's me.
If not, a fix should be sent out immediately.
MTOIn a project as big as LabVIEW bug fixes that involve changing the actual executable as opposed to changing some VI components, either in vi.lib or in one of the frameworks, is not a matter of days but more like several weeks, especially if it is something like this most likely going very deep into the operational handling of LabVIEW. This bug isn't there because of a typo but most likely because of an addition of some other code that now causes this behaviour. And simply changing it to behave as before might turn other features, specific to 2009 but also earlier ones suddenly into running havoc, so it is definitely not like changing some lines of code and then recompiling the entire thing and voila. It basically has to go through the entire regression test suit on all platforms as well as going through some serious interactive tests of many UI aspects by several guys/gals, before they can even consider wrapping everything up into a patch distribution. By that time this is done, the impationetly awaited Service pack fix for 2009 most probably is around the corner anyhow, so it will likely get wrapped into that release.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions -
LabVIEW Simple operator interface deployment
Hi All,
I try to deploy a TS 3.1 application with a LV 7.1 Simple OI. I successfully (no errors) built the OI executable and created an installer with default options. I also built the Deploy TestStand System and created an installer with default options, except I selected only User Interface->Simple->Labview (no development system). I installed them on the target machine without any problem. The problem appeared when I ran the OI; it reported "Error 97 occured at Unknown System Error in TestStand-Set TestStand Application Window.vi->Simple OI-Top-LevelVI.vi. Possible reasons: Labview: Null Refnum was passed in as input".
I beleive this happened because the "Application Manager", "SequenceFileView Manager" and "ExecutionView Ma
nager" ActiveX Controls, which were required by the OI, were not present on the target PC.
Obviously, TestStand Deploy did not distribute them.
Does anybody know how to distribute these ActiveX controls or have a successful experience of distributing the LabVIEW Interface?
Thanks.PPascal,
We've seen this error before, and it usually fixed by a simple reinstall. You could also possibly just run a repair on the TestStand engine within add/remove programs and this should also fix the problem. Please try this and post back if this does not fix the problem for some reason. Thanks and have a good one.
Adam B.
Applications Engineer
National Instruments -
How can I pass a file refnum into and out of external c++ code? What type does it convert to in c++?
I am trying to write external c++ code that will read a file already opened by Labview and therefore assigned a refnum. (Unfortunately, I definately can't use the standard Labview vis.) However I am not sure what c++ type to use in order to manage the refnum.
All help and thoughts appreciated. Thanks,
JoannaYou could do ALL your file handling in C or C++ (MFC CFile for
example) and pass Microsoft file handles into and out of LabVIEW
instead of LabVIEW file references into and out of C. This may be an
easier way to attack the problem.
You could create a DLL in MSVC that exports a FileOpen function, a
FileClose function and a FileRead and/or FileWrite Function and then
call that DLL from place to place as required in your code.
It would help us if you would explain what kind of data you are trying
to read or write and what the application is. Is it binary data?
text files? Do you need some special Win32 file system feature like
file mapped memory? I guess what I am asking is what is your
motivation for doing file handling in C or C++?
Douglas De Clue
LabVIEW developer
[email protected]
"Rolf" wrote in message news:...
> A LabVIEW file refnum is an internal Magic Cookie to LabVIEW and there is no
> way to directly extract the actual information assigned to that Magic
> Cookie.
> However the CIN Reference Manual describes one function which allows to
> retrieve a lower level "File" handle and at least on Windows 32 bit and
> LabVIEW
> from version 5 up to and including 6.1 this "File" LabVIEW datatype directly
> maps
> to the Win32 API "FILE" Handle.
>
> The function to use is
>
> MgErr FRefNumToFD(LVRefNum refNum, File *fdp);
>
> It is declared in extcode.h or one of its dependant headers and exported
> from "labview.lib"
> all located in the cintools directory and you can link this lib also to a
> normal DLL project.
> However calling this DLL then from any other process than LabVIEW or a
> LabVIEW
> executable will not initialize the DLL anymore correctly.
>
> Your best option if you need to write in C(++) should be to use the LabVIEW
> file manager
> functions described on the External Code Manual (manual/lvexcode.pdf) on
> this File handle.
> If you need to use directly some Win32 API functions with it please note
> that although currently
> the "File" in the LabVIEW file manager functions matches the FILE in Windows
> 32 bit API
> functions this is an undocumented and hence unsupported feature. The next
> LabVIEW version
> may actually use a different datatype for its "File" parameter to the
> LabVIEW file manager calls
> and your use of assuming File == FILE may simply crash.
>
> Also operating on a file refnum in LabVIEW which has been accessed directly
> with Win API
> functions may result in strange behaviour such as the file read/write mark
> not being updated as
> you would maybe expect it.
>
> "Jo" wrote in message
> news:50650000000800000016520000-1023576873000@exchange.ni.com...
> > How can I pass a file refnum into and out of external c++ code? What
> > type does it convert to in c++?
> >
> > I am trying to write external c++ code that will read a file already
> > opened by Labview and therefore assigned a refnum. (Unfortunately, I
> > definately can't use the standard Labview vis.) However I am not sure
> > what c++ type to use in order to manage the refnum.
> > All help and thoughts appreciated. Thanks,
> > Joanna -
"Search Results Go To" tentative Bug Report
Start from the following simplified situation:
Then go tho the Numeric Control terminal and right-click>> Find>> Local Variables.
The Search Results window should show this:
If you double-click any of these two occurrences, LV will bring you to it.
Now change one of the Numeric Control local variables into a String local variable (simply left-click on it and select String from the drop-down list.
You'll get this:
Now check the Search Window again (don't do a search, just go back to it).
It hasn't been updated!
If you double-click on the second "Write" item in the list above (which does not exist anymore, since it is now a local variable associated with String), you will be brought to...the String local variable:
Brings you here:
I would have expected something similar to what happens in the Search Results window when you delete an object, that is, the occurence of this object in the Search Results window becomes grayed out, like this (check item 2):
which proves that the Search Results window CAN respond to user events happening in some other windows
Now, are you ready for the best part?
OK, so if I Undo the deletion of the local variable on the diagram (which I did to obtain the snapshot above), what do you think happens?
Well, obviously nothing, to be consistent with the previous lack of update of the Search Results window... or wait... it did actually react to a deletion, but it does not to an "undeletion"?
So now we have two "Numeric Control" write local variable on the diagram, but only one is accessible from the Search Results window (same snapshot as above).
I tried the usual black magic Ctrl-Run Arrow trick, but to no avail.
I'd say it is a bug.
Tested in LV 2013 SP1 W7-64Jeff is saying to stop creating code in LabVIEW that has bugs. The steps you undertook to come across this bug within LabVIEW itself are very unusual. You created a local variable of the wrong data type. Then you needed to search through that code for all the instances of that local variable and need to replace it with a local variable of another data type. As a result, the search dialog box just didn't handle its updating as cleanly as you would've liked it to. If you didn't create a bug in your code where you used the wrong local variable, you never would have needed to do the search and replace that you did.
In order to stumble across the LabVIEW bug, you had to create a certain set of circumstances that no ordinary LV programmer has ever seemed to done. There is a reason why this particular LV bug has never been discovered before. Using the wrong local variable and needing to replace it with another this not that uncommon. But using the wrong local variable that is one datatype such as numeric and then needing to replace it with another of a different datatype such as a string, especially much later that you need to use the search function to find them all, normal people just don't do. Usually, you figure out you have the wrong variable when you see you have the wrong datatype and it doesn't wire up to the rest of the code the way you might expect without broken wires.
I'm sure NI appreciates you finding bugs and reporting them. You seem to have an uncanny ability to find bugs that nobody else seems to come across. More than your fair share. I don't know why that is. Somehow I think you have a different mentality than other programmers that leads you down paths that others just never think to do. Whether that is a good thing or bad thing, I don't know. NI takes notes issues CAR's and evaluates them and tries to fix them as they can based on priority, scheduling, resources, .... They aren't going to be able to fix things as quick as you might like them too. And if it is bug that is not significant, or not affecting a lot of people, or has a viable but perhaps inconvenient work around, then it is going to take them much longer to get to fixing it then a major, showstopper bug that affects everyone with no workaround. It might even take years. But you seem to have developed more of a negative attitude such as "I can't just believe NI allows this bug to exist in their code that obviously has existed for years" for bugs such as this that I don't think anyone before you has ever come across before. -
Utilisation de CodeSoft 8.5 avec LabView 8.5
Bonjour,
j'essaie d'imprimer des étiquettes avec le logiciel CodeSoft8.5 à partir de LabView8.5. J'ai récupéré sur le forum en anglais des codes pouvant géré cela mais en les essayant et quelque soit le refnum utilisé, j'ai toujours le message d'erreur : "erreur 97 : LabVIEW: Un refnum Null a été transmis comme argument d'entrée". J'utilise la démo de codesoft8.5 disponible à l'adresse suivante : http://www.teklynx.com/download//download_demo.html.
Je fournis en pièces jointes les vi que j'utilise.
En vous remerciant d'avance
Pièces jointes :
TekLynx.zip 94 KBBonjour à tous,
je tente désespérément depuis 2 jours de modifier une étiquette pour mon entreprise.
J'ai un code barre, fait avec codesoft 8.5, avec le code en haut et des XXXXXXXXXX en dessous. Lorsque j'insere la fonction de mon code barre dans un menu avec formviewer, je peux saisir un code pour remplacer les XXXXXXXXXX et imprimer le tout.
Jusque là, tout fonctionne correctement.
Sauf que mon fournisseur me demande maintenant un nouveau format de caractères sous mon code barre:
les X doivent avoir des espace de style XX XXX XXX XX
Pour ça encore, ça va, il suffit d'aller dans le format de sortie. Mais il faut aussi que le 3ème groupe de XXX soit en écriture "inverse video" (c'est à dire en écriture blanche avec un carré noir en fond) et que le dernier groupe XX soit en écriture un peu plus petit que le reste.
Le problème, c'est que je ne trouve pas du tout où modifier la police sous le code barre... J'ai penser à faire 3 variable (pour 3 polices différentes) mais je ne trouve pas non plus le moyen d'associer mes 3 variables en un seul code barre...
Est-ce que quelqu'un aurait une solution, je suis complêtement désespéré...? -
Is there a bug with calling 'eval' from a mathscipt node in a LV exe as of LV 8.2?
Hi.
I have a large LV VI that calls dynamic VIs, and one of these VIs has a mathscript node that calls a script that has an 'eval' operation.
The VI runs properly.
I made an executable. And though the dyamic VIs are called properly, it now generates a -90001 error at that mathscript node and
I've traced it down to the eval line.
There is also an sprintf on that line, but I saw a LV 8.5 fixed bugs list that made some kind of a reference to 'eval' but wasn't clear
as to the nature of the problem.
Any ideas?I believe you are referring to CAR 41K7AIKQ entitled "eval function needs to be blocked from the run-time engine" linked in the LabVIEW 8.5 bug fixes document.
The root of this CAR is that the eval function is not supported in the runtime engine, yet this wasn't documented in LabVIEW 8.2. The net result is that in the 8.2 help for eval, there's no mention that it is actually unsupported in the runtime, but in the 8.5 help, there is. This and you would receive a more descriptive error saying "'Function not available (RTE)" instead of the generic -90001 which is "A problem occurred in a subVI call".
Regards,
Craig D
Applications Engineer
National Instruments -
Cursors - bring to center (Labview 8.0 only)
Bring to center does not bring cursor to center unless scale multipler = 1.0
if multiplier is 1.0 and your x-scale is 0.0-100.0, then bring to center will set the cursor to 50.0 (correct)
Waveform graph , graph, properties, scales, multiplier = 2.0 (anything but 1.0) then
scale will be 0.0 - 200.0 and "Bring To Center" for that cursor will not consider the scale factor and will put cursor at 50.0 (not in center).
If your scale multiplier is 0.5 (your graph scale is 0.0-50.0), Bring To Center will set cursor at 50.0 which is at end of graph(not in center).
Labview Version 6.1 worked fine in this area. Is this a Labview 8.0 bug?Hi Ceties,
Here is an excerpt from LabVIEW help :
Bring to Center—Centers the cursor on the graph without changing the x- and y-scales. When the cursor mode is Single-Plot or Multi-Plot, this option centers the cursor on the plot on which the cursor is currently positioned and updates the cursor coordinates in the cursor legend. When the cursor mode is Free, this option centers the cursor in the plot area and updates the cursor coordinates in the cursor legend.
There is no built-in property to directly bring the cursor to center programmatically. However you can use the Cursor Position property to change position of the cursor programmatically.
Hope this helps,
Ankita
Maybe you are looking for
-
Import design object into integration repository
HI. We are going to import "XI3_0_SAP_BASIS_6.40_SP09_01.tpz" into integration reposiotry. So, we move this file into "G:\usr\sap\DEV\SYS\global\xi\repository_server\import" and start integration reposiotry. Then, I clicked tool -> import design obje
-
HT1222 Security Update 2012-001 crashed my macbook pro with 10.6.8. What do I do?
I did the automatic update last night, and now my Macbook Pro gets stuck at the white screen with the apple and soinning wheel!!! What do I do??? HELP!!!
-
OK, here's a variation on a theme; as I boot my iMac G4, the CD drawer pops open. I'm not holding the mouse button or any keys down, just part way through the blue screen it pops out. If I close it using the open/close key, it shuts, then almost imme
-
Recovery Media Creator Installation error
I have a P745-S4320 that somehow does not have the Recovery Media Creator Installed. I have downloaded it from the Toshiba website and when I try to run the installation, it pops an error message saying: Feature: StartMenuShortcuts Cmoponent: StartMe
-
How to change the iphone apple Id, how to change the iphone apple Id
How to change the apple Id on the phone, cause just change my apple Id on my computer but somehow it doesnt sync with my iphone