Labview dies when saving vi

Hi,
I have a large Labview application (7.1.1) that I am having trouble saving. I was being careful while performing a major modification and saving often. After the last save there was only one error reported, a broken wire. When I remove the broken wire, no errors are reported. When I try to run or save the program, Labview crashes and I get the Windows popup asking if I want to report the crash. I have tried everything I can think of to get rid of this broken wire & save, but nothing works. I made a major change to the code during this editing session, and stand to loose a few hours of work.
Please help!
Howard Spec
CMC Electronics
Canada

Thanks for all the helpfull suggestions. I was able to save the vi after removing the bad wire. I'm still not sure exactly what solved the problem. After trying every method of removing the bad wire, and then saving the code (unsuccessfully), I started trying to find a way to get the code to run after removing the wire. I turned on Highlight Execution, ran the code and it did not blow. After that I was able to save. Hopefully I won't see another problem like this for a long while. Makes you realize that saving often is not always going to help. Source control or manual backup should also be used in case you run into a situation like this, and don't have as much luck as me.
Thanks,
Howard

Similar Messages

Labview crashed when saving vi and now cannot open VI libray

Hi
I am using LabVIEW 7.1.
I am developing a moderately large application. I Just saved my main VI and LabVIEW crashed for some reason.
My vi library will now not open. When I try to open the library I get the error message: "an error occured when listing the contents of (my directory/myvi.library)".
Has anybody ever had this problem and if so does anybody know how I can recover my vi library?
I have just lost about 2 days work so if anybody has any ideas I would be most grateful.
I hope it is not a fatal problem - I cannot even show the vi's in the vi libray using windows explorer.
Many thanks
Ashley

It looks like you've learned the hard way why you should not use .llb's
during development. If a single VI in the library get's corrupted, the
entire library is bad. This is why during development, you're much
better off keeping everything in an organized directory structure. This
way, a crash like you had would only affect those VI's that had not yet
ben saved.
I've heard rumors that NI has an internal untility that might be able to recover the library. I'd try contacting support directly to see if they can help.
Good Luck
Ed
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.

LabVIEW crash when saving from LV2012 to LV2011 with express VI and reopen in LV2012

Hi all,
Preconditions:
Save the "Meas Angular Position-Buffered-Cont-Sync AI Sample Clk.vi" for a previous version of LabVIEW, in this case from LV2012 to LV2011
Reopen the LV2011 VI in LV2012 according to the steps below.
Steps to get it to crash:
Unzip Crash.zip
Open the "Meas Angular Position-Buffered-Cont-Sync AI Sample Clk.vi" and from there double-click (open) the "PulsedDerivative.vi" and from there double click the "Derivative dX/dt" express VI.
LabVIEW crashes!!
Alternatively when LabVIEW does not crash:
Unzip Crash.zip
Open "PulsedDerivative.vi"
Inside the VI double click the "Derivative dX/dt" express VI.
LabVIEW does not crash?
Some compiler bug?
Br,
/Roger
Solved!
Go to Solution.
Attachments:
445b4df5-fd64-49a2-8302-f8ddf06af2d3.zip ‏62 KB
Crash.zip ‏166 KB

Hi Roger,
Thank you for reporting this. I have filed CAR 390673 to our developers.
Regards,
Jeff Peacock
Product Support Engineer | LabVIEW R&D | National Instruments

Labview crash when saving

Hi Forum
When trying to save the attached file in 8.6 (the file is created in 7.1) LabVIEW crashes with a Windows error telling me that the system has encountered a problem and needs to close.
All the SubVIs save without problems and I don't see what should cause this specific VI to cause trouble.
I have searched the forum and tried the different tricks mentioned in other threads about this issue, but none of them seems to help on my VI.
I hope that somebody has a good suggestion as to what I can do.
B.R.
Martin
Solved!
Go to Solution.
Attachments:
Crash when save.vi ‏87 KB

The problem appears to be with the typedefs. Specifically, it looks like it's the text ring. Disconnecting the typedefs in 7.1 and resaving it allows it to be opened in newer version. Attached is in 8.2
Attachments:
Crash when save 8.2.vi ‏27 KB

LabVIEW Crashes when Opening Project

Hey Guys,
I'm running into an interesting issue where LabVIEW crashes when opening a project. This is the second time I've run into this issue, on the same project. To get around it the first time I simply deleted and re-made my project, but since it's happened again, I need to figure out how to debug it. The symptom is that LabVIEW will crash when opening the project (sometimes I can see the "vi loading" screen) without any indication that crash has occured. It doesn't even launch the error reporter, the process just dies. Anyone know how I can go about debugging this?
Solved!
Go to Solution.

xkenneth86,
What version of LabVIEW? Have you ever had previous versions of LabVIEW on your computer? Can you attach a screenshot of the crash?
David H.
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 I paste to the diagram

When I paste a part of one diagram to another, Labview 7 crashes with "The thread 'Win32 Thread' (0x910) has exited with code 0 (0x0).
Unhandled exception at 0x0084d46e in LabVIEW.exe: 0xC0000005: Access violation reading location 0x8168592c."

In any particular order? What about NI-DAC? Reinstalling LabView is a pain, as I have the NI-CAN pack I would have to re-install.
There is another machine that has LabView 7 on it. When saving a VI, I have seen a message "Bad Patch", and then it will not run the code. I find if I edit the diagram, I can then get it to run the code.
A screen shot of the code? It would require many screen shots of the code.
For now, I intend to be carefull about saves and copies.

Colour shift in save for web when saving on PC and then viewing on Mac

Hey peeps, I am aware of this colour shift when saving images for web. I have a designer resizing, cropping photos, and then saving on PC. He uses PC and when he sends the photos over to me on my Mac there is a big colour shift (photos are much lighte
Could anyone please explain exactly what he needs to do in order for these photos to look the same as the originals on my computer, basically no lightness shift? Any help would be much appreciated.
Thanks
Adam

Because the WWW is based on untagged (2.2 gamma) sRGB - your genius is probably sending you untagged sRGB if they were Saved for the Web (that's how I prepare my Web color).
Your Mac display should be profiled to 2.2 gamma (you are likely at the old default 1.8 gamma now if you're seeing a lightness shift on untagged sRGB)...if you want "your color" back in Photoshop, you will need to (re)Assign the sRGB profile...

The niFPui.mxx plug-in caused an exception in the CmxAggregateItemUI::InvokeCommand function in the NIMax process. When saving *.iak file in MAX4.6

The niFPui.mxx plug-in caused an exception in the CmxAggregateItemUI::InvokeCommand function in the NIMax process. When saving *.iak file in MAX4.6
Hi There,
The subject header just about says it all. This is the first action I took with MAX - it is a fresh install. The file I wanted to save was still written and the FP seems to be working ok. However, I need to know what happened.
I can't post the whole log file due to the amount of characters allowed on this post. I can cut and paste sections if there is a specific part of the file you need. Below is the first section and last section.
Context where exception was caught:
Func:
CmxAggregateItemUI::InvokeCommand Args: plugin=niFPui.mxx Item=0107EAB1
cmdID.cmdId={4A36174B-EC0C-4D73-A23D-F15D164542DE} cmdID.index=0
Application   : C:\Program Files\National Instruments\MAX\NIMax.exe
User Name     : slaney
OS Version    : 5.1.2600 (Service Pack 3)
Exception Code: C000001E
Exception Addr: 457BC448
Return Address: 457BC448
Function Name : nNIFPServer::tFpLinearScaleRange::`vftable'
Module Name   : FieldPoint71
Parameters    : F001008E 7800FDDD C5100DFC EC0107EA
Source File   : (not available)
Return Address: 481000C3
Function Name : (not available)
Module Name   : (not available)
Parameters    : 00000000 00000000 00000000 00000000
Source File   : (not available)

Hi,
I did a research on your error message and it seems this problem was introduced with MAX 4.6. This version switched to a new error reporting mechanism and reports even errors that are which are not critical to your task.
These errors typically show up as "unexpected" and if your error falls into this category have a look to this KB for further assistance.
If it doesn't fall into this category, your could try to go back to the MAX 4.5 or 4.4.. Of course you would need to reinstall some components and might not be able to use newer drivers at all.
Let me know.
DirkW

Page shows different data when saved after few minutes

Hi,
I have a peculiar problem to describe.
I have a page which contains af:table inside af:panelCollection layout. I use a af:commandLink to drilldown to another page using setCurrentRowWithKey method.
I am able to drill down to the correct data in another page which contains data that is editable. Once after editing the page when i click save button, i am able to save the data. This is working fine.
But the problem is, once i drilled down to this edit page and edit some fields and save it after few minutes, say 5 minutes later, it is not saved. Also, the page is refreshed to bring some random record.
Can anyone let me know why is this happening and how to resolve it?
Thanks

Hi Timo,
Which jdev version?I am using jdev 11.1.1.3.0.
Is it possible that the data has changed (e.g. by an other user) after you drilled to the one record you want to change?There is a possibility that the data can be changed by other user as well. But, for the time being we have implemented for the single user environment.
When you click save after some time, do you get any error (on the screen or in the logs)?Yes. On the screen, it is displayed as "oracle.jbo.JboException: Document type mismatch (source INVOICE, type Sales)". It is a validation exception thrown at viewRowImpl level by me. But it validates the data perfectly when saved immediately after editing
Which session timeout do you have configured in your web.xml?Session-timeout is given as 240
Have you tried your use case with the HR schema?Yes. when i reproduce the situation in HR schema, it is getting saved perfectly
Regards

Print program is not getting triggered when saving the application

Hi all,
My requirement is when i save the invoice using VF01 the print program should get triggered.
The print program is not getting triggered when saving the application even when i have configured the outtype and have attached the print program.
The setting "send immediately (when saving application)" is also checked.
I need to configure it for VF01 transaction.
The error message displayed was " please maintain output device in master data".
Regards,
Umesh

Hi Umesh
Please check if you have missed any of the following:
1. Defining Access Sequence(can use existing).
2. Defining Output Condition Type(can use existing). - Assigning the Driver Program and Form in processing routine.
3. Output Determination Procedure
4. Assign Output Procedure to Billing Types
Kind Regards
Eswar

Downloads Folder No Longer Jumps Up When Saving Attachments

When saving attachments in Mail, my downloads folder on the Doc used to jump up a couple of times when I hit "save" from within an email that I received to signify that I just saved it into that folder.
However, for no rhyme or reason, the downloads folder no longer jumps up when I save attachments. The attachment still save in to that folder but I miss the pop-up action telling me that it did.
I searched the net and posts and found nothing on this quark. This is driving me nutz!
Please help!

Check in System Preferences>Dock and check off Animate opening applications and see if that doesn't do it. Not sure if that is why but it is worth a shot.

Errors when saving to SMB mounts (a thorough examination)

Several of the users I support have reported the following issue when trying to save files to the network from Photoshop. I have found several threads about this on both the Adobe forums and the Mac forums. However, in most of the threads the information provided is incomplete or does not control for enough variables. And the result is that Adobe seems to blame Apple, and Apple seems to blame Adobe. So blame aside, here is information that I hope helps Adobe solve the issue at hand.
When saving to a mounted SMB point, users report one of two errors:
Could not save <filename> because of a program error
Could not save <filename> because write access was not granted
I can replicate the issue on:
Lion 10.7.X with Photoshop CS 5
Lion 10.7.X with Photoshop CS 5.1
Snow Leopard 10.6.X with Photoshop CS 5
Snow Leopard 10.6.X with Photoshop CS 5.1
Details:
We have only seen this error in Photoshop. << Adobe has seen the same problems in several other applications >>
I have not tested out whether the issue applies to any other products in the CS suite.
At first I thought the issue might have to do with permissions, but it does not. I have reapplied permissions and the issue persists. And it affects all users, including Domain Admins, such as me, who have no R/W restrictions at any level.
The issue only occurs when Finder is in a view that shows a thumbnail/preview of the image.
Switching Finder to list mode resolves the error in all scenarios
So far I can replicate this with any file on any mount on any of our servers
It only occurs on mounted network points (ie - if I move the files locally, no errors are encountered)
For the following tests, presume the following:
Source folder: smb://example/source/folder
Target folder: smb://example/source/folder
Target sub-folder: smb://example/source/folder/sub
Here are the steps I tested:
Opened the file problem_file.psd.
A warning pops up prompting me to resolve a font vector issue, I chose "Update"
Note: that this error does not pop up for every file, just the original file I worked with, but this warning has nothing to do with the errors being received
Moved a layer so that there would be a change to save
Clicked save
Received the error: "Could not save <filename> because of a program error" << probably related to the known MacOS bug on SMB, or a known Finder/thumbnailing bug >>
The original file, problem_file.psd, is *DELETED* (very problematic) << Known MacOS bug in SMB service, Apple is working on it >>
Then I tested with multiple variations of the following to conrol for things such as layers or font issues:
To eliminate the source file being the issue, I used a .png file that I had created locally with the OS-X screen shot keyboard command. This eliminated layers and fonts as issues.
In step 2 I chose to not update the font vector issue
In step 4 I tried saving as different file types (.jpg, .png, .gif)
Prior to step 6 I flattend the image to eliminate fonts and layers. This eliminated layers and fonts as issues.
Prior to step 6 I flattened the image, duplicate the image, closed the original (without saving), and attempted to save the new duplicate. This eliminated layers and fonts as issues.
Each variation still resulted in "Could not save <filename> because of a program error" and resulted in the deletion of the source file.
Next I controlled for saving image previews:
Photoshop -> Preferences -> File Handling
Under File Saving Options -> Image Previews, I set it to "Never Save" previews
Now when I repeated the tests from aobve, I receved the error "Could not save <filename> because write access was not granted".
Next I controlled for .DS_store files:
Disabled .DS_Store file creation on remotely mounted points.
Deleted the .DS_Store file for the source folder
Verified that .ds_store files were not being created on remotely mounted points
Ran the tests above, and the issue persisted: "Could not save <filename> because write access was not granted"
Now I decided to test sub-folders:
Created a target sub-folder.
Repeated the test above, and its variations, but saving the problem_file.psd to the target sub-folder.
Still received one of the two errors, depending on the variation, but the source file is no longer deleted. This make sense because saving in another directory is really a "save as", and one would not expect safe saving (talked about more later) to affect source files in this scenario.
Sort of a Solution:
Open the file from Finder
Depending on the Finder view, Finder shows a thumnail of the image
Go back to Finder and select a different file
Make changes to the file
Save the file
No error is received
This is when I discovered that the error only occurs when Finder is in a view that shows a thumbnail/preview of the image. Further testing of Finder show that in Cover Flow the error only occurs for the selected image. For example:
Cover flow shows thumbnails/previews of files: A, B, C, D, E
Open A
In Cover Flow select file B
The thumnails of of files A, B, C, D, E are still visible
Make a change to the open file
Save the change
No error is received
This shows that Finder is treating the thumbnails/previews of unselected files different than selected files.
An Interesting Twist:
If from the last scenario with Cover Flow...
Open file A
Go back to Finder and select a different file
Then make a change and attempt to save to the target sub-folder
Receive the error "Could not save <filename>" because of a program error.
Discussion:
Photoshop does something called safe saving.
Photoshop saves the current document to a temporary file with a unique name
Photoshop deletes the original file << this is incorrect >>
Photoshop moves the temporary file to a file with the name of the original file that was deleted in step 2 << incorrect: the temp file replaces the original with an OS call to a function that is supposed to be an atomic operation >>
However, you can see that "safe saving" is misnamed, because while the original is deleted, Photoshop does not appear to be correctly ensuring that permissions exist to allow the temporary file to be ranemd or that the temporary file was renamed without error. Photoshop is either:
Not checking for the error << yes, it is >>
Checking for the permissions and not catching the error << incorrect >>
Checking for the permissions and giving an error to generic to discern the exact problem from. << also incorrect >>
Somewhere there is a conflict (perhaps a race condition) between:
Photoshop creating the temporary file
The server applying permission to the newly created temporary file
OS-X reporting the file has been created
Photoshop deleting the original file
Photoshop saving the new file
Finder updating the thumbnail of the file
As I've shown here, the problem doesn't seem to reside fully with Apple or fully with Adobe. Hopefully this post provides enough information for some clever engineer to create a fix.
My information about safe saving is from an Adobe mod on a previous thread regarding this issue << and copied incorrectly, plus added bad assumptions>>. He detailed the process and also explained that Photoshop uses OS APIs to create and delete the files during safe saving. If his details are accurate, it seems that a temporary fix would at least change the safe saving process to the following:
Photoshop saves the current document to a temporary file with a unique name
Photoshop moves the original file to a temporary backup file (original-file-name.original-extension.bak)
Photoshop moves the temporary file to a file with the name of the original file moved in step 3
Photoshop checks to make sure that the temporary file has been succesfully renamed
If the temporary file has successfully been renamed, it deletes the backup file from step 2 OR if the temporary file has failed to be renamed, the backup is returned to its original file name
The appropriate error message, if any, is displayed
A Few Sources:
http://adobe.hosted.jivesoftware.com/message/4016324
http://forums.adobe.com/thread/732422
https://discussions.apple.com/thread/3380971?start=0&tstart=0

You got several details wrong.
And it sounds like you are describing 2 known MacOS bugs:
1) The OS fails when creating or swapping files on SMB servers, and this happens more often on files that have a resource fork.
2) The Finder/QuickLook/Thumbnailing holds a file busy when it should not, causing program errors or file is busy errors.
We did as much as we could to work around these issues in Photoshop CS6 - after spending a lot of time debugging the OS issues and working with Apple.
Apple is still working on proper fixes within the OS.

Error "Session Timed Out" When saving webi report as PDF

Hi,
I am getting below error when saving report as PDF
The Session Timed Out.The document *.wid has been auto saved in the Favorites~WebIntelligence Folder..Click Restore to retrieve it.
(ERROR : WIJ600001).
I get above error in PROD but works fine in DEV.
Version : BOE 3.1 SP7 (DEV & PROD).
Session Time out set as one hour.
Report runs for 3 minutes .once I get the data if I try to save it as PDF immediately I get the above mentioned Error.

The default Webi auto-save is every 600 seconds, which is 10 minutes. You could increase it to 3600 seconds (1 hour) in CMC -> Applications > Web Intelligence > Properties > Auto-save Settings on "Auto-save time delay".
See KB 1297132 - Error: WIJ 60001 after the Web Intelligence Java Report Panel is left inactive some time on http://service.sap.com/sap/support/notes/1297132.
Hope this helps,
Jin-Chong

Office 2013 hangs when saving files to local profile locations on Windows 2012 server

We installed Office 2013 a few weeks ago instead of Office 2003 on a Windows 2012 standard terminal server. We installed the last updates and Office is up-to-date now, but we experience problems with saving word, excel and powerpoint documents when we start
a new/clean document. It's not possible to save our documents to the local profile (desktop, documents etc.), but it's no problem to save our stuff to a network share on a different server.
Word is not responding after pressing save or save as and after a few seconds we see the 'microsoft is looking for a solution and will restart microsoft word'.
We did a complete reinstall of Office 2013 and removed the old installation with the removal tool from the microsoft website, without luck. We have the same saving issues with Office 2010, so it's not an Office 2013 issue.
We were looking in the access/rights on the terminal server, because we thought that it was an access/rights issue. But unfortunately we have the same problem with an domain admin user.
I tried to disable DEP and my AVG 2012 antivirus, but this steps are also not the issue.
I'm looking for a solution and i'm working on this case for a few days now. It gives me a headache when i'm thinking about a clean installation of this server. So please contact me when you have a solution or a tip to solve this problems!
Thanks!

Hi,
In regarding of the issue, it may be caused a lot of reasons. Please check to see whether the following link is helpful:
https://support.microsoft.com/kb/313937/en-gb
http://support.microsoft.com/kb/921541/en-gb?p=1
http://support.microsoft.com/kb/271513
Then Office hang when saving the file also may be caused by a printer installation.
Check to see the following link:
http://blogs.technet.com/b/the_microsoft_excel_support_team_blog/archive/2012/04/12/excel-hangs-or-becomes-unresponsive-when-saving-or-closing-a-workbook.aspx
If you could upload the event log, I'll do deeply
research.
Thanks,
George Zhao
Forum Support
Come back and mark the replies as answers if they help and unmark them if they provide no help.
If you have any feedback on our support, please click "[email protected]"

Labview dies when saving vi

Similar Messages

Maybe you are looking for