Labview 8 crashes when using Read Labview Measurement File

Hi All,
I am a new user for Labview. I installed Labview 8.0 from the CD (evaluation copy). I was just testing the sample code provided by NI. I opened the "Load from File and Display" example and I was trying to open the properties for the Read Labview Measurement File component when Labview crashed. I tried it a couple of times and everytime it happens the same way (when I double click the component or right click on it).
I am using Windows XP with all the updates done. In the Windows crash report, the application version is 8.0.0.4005.
Other problem I encountered is a missing component on the Input Palette (no DAQ Assistant present) and the Instrument I/O Assistant raises the error "Measurement & Automation Explorer or the Instrument I/O Assistant is not installed correctly. Please install these from the Labview Driver CD". For the last problem, I will try to run the Labview Driver CD, once I get it. But I am not sure if the DAQ Assistant will show up then or not.
Any ideas?
Regards,
Nick

Hello Nick,
While it is not my area of expertise, I would expect the DAQ Assistant would appear after installing the driver CD as you said you would be trying.
What caught my attention was the crash. The easiest way to resolve the crash is to delete the instance of the Read LabVIEW Measurement File on the diagram and place a new one from the Express Input palette (now called "Read From Measurement File"). In that situation, I would expect just pressing OK to accept the default configuration should work. The crash occurs in certain circumstances when the Read / Write Measurement File Express VIs are dropped from a previous version of LabVIEW and then their config page is opened in 8.0.x. This issue should be resolved in a future release, sorry for the inconvenience.

Similar Messages

Labview crashes when using NX client

I can use Labview from the Linux console, but when using Nomachine NX to connect, I get the following error & crash when trying to launch Labview:
LabVIEW caught fatal signal
12.0 - Received SEGSEGV
Reason: address not mapped to object
Attempt to reference address: 0x0x72657375
No extra hardware is attached.
Platform: RedHat Linux 5.9 64bit
Product: Labview base package

Hello,
Related with your issue,I have found the following KB that talks about it:
http://digital.ni.com/public.nsf/allkb/A2D53C8E0D88380B86256EBD005B31D2

How to populate column titles for y values when using Write to Measurement File Express VI with a tab delimited text-based .lvm file?

The .lvm file generated by the Write to Measurement File Express VI includes column heading titles for the y values, but they are a default value of "untitled". See attached example of a sample file when opened in Excel, the values in question are highlighted. Is there a way to specify the column titles when the file is written?
This is a similar question to this posting, which received a work around response to use the Write to Spreadsheet File.vi, rather than a solution when using this VI.
Message Edited by Hightop Raven on 05-02-2007 03:37 PM
Attachments:
column_titles.gif ‏13 KB

Sorry for the late reply. I was out of the office Friday.
You can do it, but the code can get rather ugly. Under the hood, the dynamic data type (the dark blue wire) is an array of waveforms. In your case, the scalar values you convert to a dynamic data type are being converted to an array of waveforms, each waveform having one element. You have two options.
Explicitly convert your scalars to one-element waveforms (t0=0, dt=1) and add the title before conversion to a dynamic data type.
Convert your dynamic data type to an array of waveforms and loop through them to add the column labels. The conversion blocks are in the Signal Manipulation Express palette.
I would recommend 2, since it is the easiest to add. It is also the easiest to run only on the first iteration. Just put a case selector around the loop, wire the selection to the While loop iterator, and set the case containing the label code to 0. The default case simply passes through the dynamic data.
My apologies for not including a screen shot. I am in the process of upgrading my machine and can't run LabVIEW. If you need one, let me know and I can post one tomorrow.
This account is no longer active. Contact ShadesOfGray for current posts and information.

Format precision apparently ignored when using read from spreadsheet file

I hope there is ridiculously simple solution to this problem but so far I can't find it. Using the Read from Spreadsheet File function in LabVIEW7.1, I can't get the floating point format (%f) to work; the decimal (%d) seems to work fine. For example, the first value in the attached file is 399.5853. When I read it in using %.2f format I would think I should get 399.58 but instead I get 399.58529663... Oddly if I use %d as the format, I get an as expected value of 399. Can anyone see what I am missing?
Attachments:
ReadFileTEST.vi ‏23 KB
test.txt ‏1 KB

The solution to the problem is the internal representation of floating point numbers: with a limited number of bytes only a limited number of the (infinitely many) real numbers can be represented. The nearest representable number to 399.5853 is 399.58529663 if the so-called single precision representation (abbr. SGL in Labview) is used.
It seems that (ridiculously!) NI has chosen to use SGL as the data format in the Read from Spreadsheet VI which causes the unexpected behaviour you observed.
You can change the representation from SGL (which uses 4 bytes) to DBL (double precision, using 8 bytes) in the Read from Spreadsheet VI and you will observe a better approximation then, but still not 'exact' since the number now reads 399.585300000000018. (With t
he EXT representation, 10 bytes, you could go to even higher precision)
I hope someone from NI reads this and they fix the unnecessary limitation of the precision in the Read from Spreadsheet VI.

Is there a file size limit when using Read From Spreadsheet File?

I'm trying to read in a large file, about 52mb, 525600 lines with 27 fileds in each line using "Read From SpreadsheetFile.vi". I then search the 2D array for -999, which represents bad/no data in that field and total the number of fields with -999 in it. This all works on 3 months worth of data. The program is giving me an out of memory error and stopping in the case where the read takes place on the large one year file. So my question is does the Read from Spreadsheet file have size limitations? Is there a better way to do this? Thanks in advance for the help.
ssmith
Solved!
Go to Solution.

Camerond--
Thanks for the help. I recreated the VI you posted and unfortunately it doesnt work. It looks like the index array vi is only looking at the zero index and not the other 26 fields in each row. This would probably require a FOR LOOP to go through each field index. This is what I have and it works on a smaller version of the file. For some reason LV is using up bucket loads of memory to run this smaller file and crashes running the 60MB file. I've attached one of my vi's to solve this problem and the smaller data set. You'll see in the beginning that I trim some columns and rows to leave just the data I want to scan. Thanks again for the help.
I just tried send 3 months worth of one minute data and it failed. So here is a really small version, 20 minutes worth of data. Does anyone see anything that would cause memory usage issues here?
ssmith
Attachments:
Find-999NoLoops.vi ‏17 KB
TEST2MET.txt ‏3 KB

Why does Labview crash when using DLL to retrieve desktop directory?

In Labview 7.0 I run this VI and it occasionally will crash labview upon closing it. The error is "Labview 7.0 Development System has encountered a problem and needs to close. We are sorry for the inconvenience."
The error signature is:
AppName: labview.exe AppVer: 7.0.0.4000 ModName: labview.exe
ModVer: 7.0.0.4000 Offset: 00801e0e
What do you think???
Attachments:
desktop_path.vi ‏14 KB
appcompat.txt ‏19 KB

AKlijn wrote:
> This was, indeed, the solution. Thanks so much for taking the time.
> I must say I could not find this preallocation concept in the labview
> documentation, but perhaps they assume a more experienced programmer
> would be reading it.
As far as I remember it is mentioned in the tutorial. However this is a
very basic C programming concept, that the caller has to allocate and
deallocate buffers passed to functions. This is because there are
basically a myriad of ways to allocate memory and if the allocation and
deallocation is not done by the same entity you have to exactly specify
which memory pool has to be used. Windows itself has about three or four
different memory management libraries and most C runtime libraries add
th
eir own again, although the Microsoft Visual C runtime library does
redirect its malloc() calls to one of the WinAPI memory management
calls. But Borland runtimes typically have their own meory management
library and if a DLL created in Borland C or Delphi would allocate
memory and you would try to deallocate it in a Visual C application you
would get very bad crashes.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Random crashes when using 16 Labview with the 32 bit labview

I am using 2 versions of Labview at the same time, one is version 4 which has a camera and a weigh-in-motion scale attached to it. The second is either Labview version 4, 16-bit or Labview 3.0.1, 16-bit, i'm not sure. The sixteen bit has a data acquisition system attached to it. Its an optim electronics system and the 16-bit Labview drivers for the optim were provided by Optim electronics and so I am stuck with using the same system. When I use both these systems in tandem, the system crashes frequently, but both systems run fine independently. It usually just freezes up or says "Illegal operation performed. Contact program vendor". Its a windows error with a red cross.

So a guy goes into his doctors office and tells his doctor "Ya gotta
help me doc...it hurts when I run my head into the door like
this...OW!". Then the doctor says:
"DON'T DO THAT ANY MORE!!!"
(I promise to keep my day job...oops what job...and not go into
comedy..)
Why don't you convert all the old 16 bit code into 32 bit code and
create one application where the various parts all know about each
other? I don't think that there's any way to coordinate an old 16 bit
LV and a new 32 bit LV application so that they don't step on each
other driverwise like they appear to be doing. I don't think that the
two LabVIEW's even know that the other exists!
Alternatively, get a second computer to run the 16 bit code on and
make the two apps communicate with
each other using TCP/IP or serial.
Doug De Clue
[email protected]
cincidude wrote in message news:<[email protected]>...
> I am using 2 versions of Labview at the same time, one is version 4
> which has a camera and a weigh-in-motion scale attached to it. The
> second is either Labview version 4, 16-bit or Labview 3.0.1, 16-bit,
> i'm not sure. The sixteen bit has a data acquisition system attached
> to it. Its an optim electronics system and the 16-bit Labview drivers
> for the optim were provided by Optim electronics and so I am stuck
> with using the same system. When I use both these systems in tandem,
> the system crashes frequently, but both systems run fine
> independently. It usually just freezes up or says "Illegal operation
> performed. Contact program vendor". Its a windows error with a red
> cross.

Labview crash when using mscorlib

I notice the following behaviour using LV2013 and LV2014:
When a project is offen which contains a class whose control has a .NET reference pointing to the mscorlib, and the project is then closed, LV reports a crash by closing itself (example of .NETKlass.lvproj)
When another project is offen which contains a VI with the same .NET reference, and the project is then closed, LV do not reports a crash by closing itself (example of MscorlibRef.lvproj).
This behaviour happens only if the .NET reference points to mscorlib.
Has anyone the same problem? Should I close any reference ? But where/how? Is it a LV bug?
I attached a zip File containing the 2 example projects (LV2014) as well as the error protocol. To reproduce the crash do the following:
1/ Open LV2014
2/ Open .NetKlass.lvproj
3/ Close .NetKlass.lvproj (you do not need to open any VI)
4/ Close LV2014
=> LV reports a crash
The same with MscorlibRef.lvproj do not produces a crash. Behaviour occured with LV2013 too.
Thank you
Adelina
Attachments:
d7269f72-e341-453d-8418-62c0b7662c32.zip ‏159 KB
TestClass.zip ‏12 KB

Hello Adelina,
I created a CAR (Corrective Action Request) with our developers to fix this behaviour.
Unfortunately I can't say if this is going to be fixed in the new version of LV.
To check, if this behaviour is fixed, you can create an service request or phone us with reference to your forum post and we will check it.
Best regards
Felix

LabVIEW crashes when using the Get Scale Information.vi

Hi,
I'm using LV 6.02 and MAX 2.2.0.3010 on WinNT 4.0 SP6 and a AT-MIO 16E-10 DAQ-Board.
In MAX I've created some virtual chanels and also some scales. Data-Aquisition works fine so far. But now in my application I need to know the scale coefficients to calculate the voltage of my waveform signal. For this I tried to use the Get Scale Information.vi from DAQ-Chanel Utilities palette. But everytime I run this vi with a valid scale name, LV chrashes down.
Has anyone an idea, what to do?
Thanks in advandce!

Hi Jeremy,
I couldn't test my vi on another computer, I only have one with LV installed.
I also couldn't post the error message, because there is no one. LV is immediatly chrashing after executing this single vi. There is another Windows Application that starts to log some memory and task stuff ('Dr. Watson').
I will attache this vi.
In MAX I have defined three different linear scalings.
Hope, you can help me.
Thanks so far, Andreas
Attachments:
DAQ_Scale_info.vi ‏33 KB

LV 8.5 crashes when using read datasocket

LV 8.5 crashes with a nasty C error message when runnin this simple VI.
soren jensen
[email protected]
Attachments:
Crash LV 85 using datasocket read.vi ‏11 KB

hi there
i'm using 8.5.1 and i see just a simple timo error:
"Error 56 occurred at DataSocket Read in Crash%20LV%2085%20using%20datasocket%20read[1].vi
Possible reason(s):
LabVIEW: The network operation exceeded the user-specified or system time limit."
Can you post the error message or some screenshots?
Best regards
chris
CL(A)Dly bending G-Force with LabVIEW
famous last words: "oh my god, it is full of stars!"

"Hi,I'm having problems controlling the Agilent E4422B Signal Generator with Labview. When using the Labview driver functions such as initialize instrument I always get an Error -1074135040.

I can query the device through the measurement and automation tool. I can also Identify the instrument by issuing a *IDN? with VISA write and read. Why do I get this error while using the drivers supplied by NI for this equipment? Any Ideas?

Hi, Brooks.
Attached please find the files containing all the information concerning my attempt to control the Agilent E4438C. Hope you can make sense of it and help me.
Regards
isaac
Attachments:
nireport.txt ‏2 KB
Capture.spy ‏5 KB
CaptureSpy.doc ‏117 KB

Data reading and writing problem? how to set " Read from Measurment File express.vi" 's readout datasize?

Dear all,
I want to use Labview to process a data.
Now I have a array in a text file.
this array is very very big. which is at least row*col = 6 * 100000;
the column size always 6,
but the row size is ramdom, some times is very big, like bigger than 65535,
when I use "read from measurement file express.vi" to read this file, the array I could get always 6*5339, I don't know why. the column size is always 5339.
and then I delete the 1st row of the array and then write into a txt file via "write measurement file express. vi", it takes a very long time. almost computer has no response. after a while, no file was creat to record the data.
is there an efficient way to process such big data file and store the processed file into a new file
thank you very much
Jack
Message Edited by weichengatech on 03-09-2006 12:00 AM

Hello,
There’s no real efficient way to read the file if you don’t
know exactly how many rows of data you have.
Your going to just have to read a row at a time and add the results to
the end of an array (granted for the clever programmers there are some more
efficient ways to do this than just with ‘build array’). I would start by asking you how much
information you know about the file and what the exact structure of it is (i.e.
is it a binary file, a tab delimited file, or a LVM file)? Could you provide a screenshot of the code
you are running? If you provide a little more information on the file structure
we might be able to contribute some additional information.
Look forward to hearing back from you-
Travis M
LabVIEW R&D
National Instruments

Labview crashes when creating large image files

I have a problem with Labview 6.0.2( I've tested evaluation version 7.0 too).
I'm constructing a very large image, for example: 4500x4500 pixels. Labview crashes when converting the pixture to a pixmap. The image is fully constructed on my screen (in a picture control), but when converting it to a pixmap (for saving the image in a known format (bmp, jpg, tiff)), Labview crashes.
I did some testing and when the number of pixels exceeded the limit of 2^24(16777216), the file 'image.cpp' crashes on line 1570. The vi to convert it to a pixmap is: P'icture to pixmap.vi'
Does someone know a workaround for this problem? Or is there a fix for it?
Thank you!

I've tested the 6i version of my VI in Labview 7.0 evalutation version. It raised an error but not the same error:
d:\lvworm\src\lvsource\compatexport.cpp(37) : DAbort: Called a routine not in the compatibility LVRT table
$Id: //labview/branches/Wormhole/dev/lvsource/compatexport.cpp#11 $
0x004BD4CB - LabVIEW_Eval + 0
0x0EB710D9 - lvs248 + 0
0x094C87A0 - + 0
So i replaced the picture VI's with the 7.0 evalutation version VI's, and it worked. It is now possible for me to construct very large image files!
I see no attached VI to test. But i guess it is also solved in Labview 7.0
I used this file to convert the picture to image data:
C:\Program Files\National Instruments\LabVIEW 7.0 Evaluation\vi.lib
\picture\pictutil.llb\Picture to Pixmap.vi
And this file to convert image data to bmp:
C:\Program Files\National Instruments\LabVIEW 7.0 Evaluation\vi.lib\picture\bmp.llb\Write BMP File.vi
I guess i have to write a workaround for this problem:
divide the picture in blocks of 4096 x 4096 and then merge the image data arrays of the bloks together.

LabVIEW crashes when trying to use VISA controls

When I try and place VISA controls onto the front panel or a constant into the block diagram LabVIEW crashes and says that LabVIEW.exe caused an error and that LabVIEW must be restarted. Is there some setup required in order to use VISA or is there something wrong with LabVIEW?

I saw something that sounded exactly like this myself on two PC that where running some kind of "Eveidence Eleminator" software that got its hooks into everything.
I never did get it running on those two machines.
I saw something similar when trying to access a serial port that was hanging off of a USB gizmo.
We downloaded the latest and greatest version of the driver for the USB to serail device
and
upadted NI-VISA to the latest and greatest.
Then everything worked.
It was just like you mentioned, LV looks fine right up until you drop a VISA control.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Why does LabView crash when unloading my DLL (reentrant calls)?

I have written a DLL in Borland Delphi using multiple threads that exports several functions (stdcall). I am using LabVIEW 6i on a WinXP machine. All functions in the DLL work as expected and return correct values. Everything works fine if I set all Call Library Function Nodes to 'UI-Thread', but as soon as I set one Function Node to 'Reentrant', LabView crashes when I close the VI after it has been executed. I assume the error is caused by the DLL unloading mechanism of LabView. Other C++/Delphi programs using the DLL reentrantly work fine, this only occurs in LabView. In which thread does LabView call FreeLibrary/DLL_PROCESS_DETACH? Has anyone experienced similar problems?

I have never run into this situation myself, but I do know that calling a multi-threaded DLL or CIN from LabVIEW does depend upon the following criteria:
If your CIN/DLL doesn't have any global data storage (global variables, files on disk, etc.), AND it doesn't access any hardware (register-level programming) AND it doesn't call any functions/DLLs/Drivers that are thread-unsafe.
OR
Your CIN/DLL protects (with semaphores or mutex's) access to those global resources.
OR
Your DLL is only called from one, non-reentrant VI
OR
Your CIN is only called from one, non-reentrant VI AND you don't access any global resources from CINInit, CINAbort, CINDispose, etc. procedures.
Hopefully this information can help you out in some way.
J.R. Allen

Labview 8 crashes when using Read Labview Measurement File

Similar Messages

Maybe you are looking for