Solenoid causing LabVIEW crash?

Hi
I am using LabVIEW 8.6 with an NI-9481, 4 channel relay module (amongst others) to control a solenoid valve which opens and closes a hydraulic circuit. The relay module controls a 24V DC supply to the solenoid.
The solenoid valve is opened and the hydraulic circuit operates. Once a condition is reached, the solenoid valve is closed by LabVIEW,shutting down the hydraulics. A few seconds later, the computer restarts. To try to remedy this problem a diode was fitted, parallel to the solenoid to protect the circuit from back EMF's generated by the collapsing magnetic field in the solenoid. This reduced the problem but has not solved it.
Can anyone suggest any remedies? Could the back EMF pulse be the reason for the computer resetting itself? Or could there be another reason?
Any help would be greatly appreciated.
Many thanks.
John
Solved!
Go to Solution.

Could you be having a "blue screen of death"? Just this morning I had to solve a problem with the PC restarting itself. The error messages when Windows restarted told me nothing. I found a tip on the forum how to turn on the blue screen message. Go to My Computer/Properties/Advanced/Startup and Recovery Settings, and uncheck the box that tells the PC to restart itself. Once I did that, I saw I had a blue screen related to the serial driver for a USB/Serial port converter. That led me down the path to updating the driver and all seems to be working fine for the moment. Now why the blue screen what able to know which driver caused the problem, but Windows didn't know when it restarted, that just shows the idiocy of windows.
If you have a blue screen, this will show it and maybe give a clue as to whether you have a crash due to a driver issue or some power failure.

Similar Messages

Easy text report in DLL causes LabVIEW crash

I was wondering if anyone else could shed some light on this problem (it's got tech support stumped).
To date I have two build machines and three target machines that have had the same problem. I build a DLL in LabVIEW that contains the Easy Text Report vi. I also create a VI that calls this DLL function to test it out. Everything works fine on my build machines. On my target machines, however...
On the target machine I put a call library function node on the block diagram and configure it for the LabVIEW DLL I created, select the function and setup the parameters to the function. Upon clicking on OK on the configuration window for the call library function node, my hard drive access spikes for some period of time (sometimes fractions of seconds, sometimes seconds); I assume the VI inside the DLL is being loaded into memory. I then get a Windows message stating that LabVIEW needs to be shut down at which point Windows terminates LabVIEW. Removing the Easy Text Report from the DLL VI eliminates the crash. Tech support has helped narrow this down a bit -- it seems to specifically be the print portion of the report generation VIs (they sent me a DLL that creates an HTML report which had no issues).
I'm doing this in LabVIEW 8.0. To make things more interesting, I have the same code in LabVIEW 7.0 and 7.1; neither of these have any problems. I've attached the code (LabVIEW 8.0) that tech support and I have been messing with.
Any thoughts or sugestions?
Tim Stahl
Attachments:
My DLL.zip ‏10 KB

Hi DougF,
It has been a while since I looked at this stuff in detail, so I will answer from memory.
There are a number of routines that must be present for the code to work correctly. The two I am thinking about are "CINDispose" and "CINUnload".
I suspect CINUnload is missing or buggy.
I hope this helps,
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Running the VI causes LabVIEW to crash

Hello
While debugging a SW, I found that a particular VI, when run, causes LabVIEW to crash. This happens whether this VI is called while executing an exe or called by higher VI or even when it is run separately.
The VI to be run is NLD_Test_PP_Plot.vi present in the folder "Generic VI's".
The input for this VI is .csv file, which is attached. The csv file needs to be placed in a separate location and that path needs to be entered in the string constant in the VI.
Note: This VI is developed and run in LV v2009.
Thanks
Sharath
Attachments:
SpecimenCW_20150407_193059.csv ‏67 KB
NLD_Test_PP_Plot Folder.zip ‏208 KB

LabVIEW did not crash for me (nor did it throw an error). It made a bmp of your data and then exited. I am using LV 2013.
Did it actually crash or did it throw an error? If it crashed, do you have the crash zip file?
Bill
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.

Deny Access function with invalid file refnum causes LabVIEW to crash

Hi folks,
I have LabVIEW 8.5, and today encountered something interesting that consistently causes LabVIEW to crash. Essentially, if you find the "Deny Access" function under the advanced file IO palette and wire up an invalid refnum, Windows (XP in my case) reports that LabVIEW has to close. I checked in task manager, and the LabVIEW process is still active and using a disproportionate amount of the CPU.
To reproduce the issue, simply drop the function on your block diagram, create a constant from the refnum input terminal, and run the VI. Has anyone else seen this behavior?
Thanks,
Jim

Hi Carla,
I'm glad to help, and thanks for looking into it. The way I ran into the bug was while I was working on an action engine VI to log certain text values (see attached picture). While logging, I didn't want other programs to access the file. When a new file had to be generated, I wanted to stop denying access and close the reference. However, if the value on the shift register was invalid, LabVIEW crashed instead of throwing an error (I guess a crash qualifies as an error).
If you look at the attached picture, my workaround was to use the "Not A Number/Path/Refnum?" function. If the reference is bad, I don't try to use the "Deny Access" funtion or close the file. That worked just fine and seems like a good solution for now.
Jim
Attachments:
Logger.png ‏6 KB

I am using datasocket in seperate vi, with error catching, but network slowdown causes labview to crash without any error message ...

I have a master computer setup as a datasocket server with several vi's that publish. I have about 5 other computers each with a vi that reads the data socket publisher. The interval at which the 5 vi's read is every 15 minutes, concurrently. It seems that when ever there is a network slow down, LabVIEW crashes catastrophically, even though I have timeouts in the datasocket readers. Is this error related to the datasockets not being able to handle the slow down or something else? Should I use another technique - if so - which is more reliable (FTP, TCP/IP?). This bug has been hounding me for several MONTHS.

One thing I forgot to mention - the 5 datasocket readers are also web servers, serving out the front panels to the web after getting updated. Well, after weeks of trial and error, would you believe that if I turn off the web server logging, everything works fine. I have had it off for a week now and no crashes. I first discovered this by realizing that if I turned off the web server everything ran fine (which would be totally useless for my application), so then I searched this site and found an off the cuff remark about the web server logging function causing crashes for an unrelated problem. I figured what the heck, I'll disable it and see what happens. So far so good, I am still keeping my fingers crossed ...

Error 404 causes Labview 2010 to crash but only occasionally

Hello,
I am requesting help to solve a problem with LabVIEW 2010 crashing. I am new to this company and the last Labview developer left without providing
background on this problem. Labview crashes after running project VIs. Labview closes without warning or error messages. The project acquires data from pressure transducers, dP transducers, thermocouples, IEPE, load cells, and voltages through NI real-time system and has digital I/O. NI hardware includes PXI-1050 with modules 6221, 6280, 6224, 6220 and NI PXI-1052, SCXI-1306, SCXI-1112, SCXI-1520, and SCXI-1102. I've reviewed the labview program and the software relies heavily on shared variables, references, and local variables but I cannot find anything that stands out as a problem in the software .
The program crashed again today after running for only 1/2 hour and was not recording data. No error message occurred before the crash and the only error after restarting LabVIEW was the standard message that LabVIEW did not close properly. I went to the Event Viewer and at the time of the crash I received the following information:
Event ID = 3299
Source = LabVIEW
Log = Application
Level = Error
LabVIEW Information: Error 404 "Not found" for "/national instruments/ real-time execution trace toolkit/ 2.0/ trace receiveport", file "Crogram files (x86)/ national instruments /shared/ ni webserver/ www/ national instruments/ real-time execution trace toolkit/ 2.0/ trace receiveport": Can't access URL
According to Event Viewer, this error 3299 occurred 15 times in the last 3 days. LabVIEW crashed today at 10:19 am at the same time this error 3299 occurred but LabVIEW did not crash the other times this error occurred in the last 3 days. I believe this error is related to the crash but does not usually cause the crash. It appears to me from reading the error message that the error is the result of occasional lose of communication with the real-time system (Can't find URL). Any suggestions how to resolve this would be greatly appreciated.
Bill

1. Have you had this code working before on this or another machine?
2. Which operating system and version of LabVIEW are you running? (This can be found in Control Panel >> All Control Panel Items >> System)
3. Which National Instruments Drivers are you using? (This can be found in the measurement an automation explorer under the software tab [a screenshot would be good])
I would look into removing afsetup.exe which is a data collection tool provided by Microsoft which could a) not be installed correctly and/or b) trying to pull data from LabVIEW. I think this may help you out, as even though your programs aren't explicitly calling it, the service is running in the background.
Secondly, I would look into stopping the NI Web Server application that could be polling a web page that's not needed.

3D graphs cause LabVIEW 2010 to hang

I've been using LabVIEW 2010 for several weeks without any problems, but today I noticed that it doesn't work at all with anything related to the 3D picture control. Today was the first time that I tried doing anything with the 3D picture tool since installing LV 2010. Dropping any of the 3D Graphs on the front panel of a new VI causes LV2010 to hang. (By hang, I mean the VI window remains open but most UI things no longer work. Right-clicking on the window does not show a context menu. The main menu doesn't work. The X button does not close the VI front panel window nor the diagram window. Control-Q does not cause LabVIEW to quit. I have to kill the process in Task Manager.) It is the same story with just a plaing 3D picture indicator. Also, the solarsystem.vi example does not work either. The problems start as soon as I open the solarsystem.vi. After killing LV with Task Manager and relaunching LV10, I do not get the LV message about a previous crash.
The problem I am talking about is for LabVIEW 2010 with the f2 patch running in Win7. I am actually running it using VMware Fusion 3.1.3 on a 2009 Mac Pro running Lion. The Mac drivers are all updated. Since it is VMware Fusion machine, the video driver on the Windows side is part of the VMware Tools installation, which is up to date.
After searching the forums, I've tried all the other potential solutions I could find: 1) repaired LV2010 using add/remove programs and 2) tried using the compatibilty mode settings to turn off Aero.
Interestingly, 3D graphs work fine on the Mac side for LV2010 for Mac.
Even more insterestingly, 3D graphs work fine on Win7 for LV 8.5, which I still have installed. The fact that it works fine for LV 8.5 would seem to indicate that Lion did not introduce the problem and that the video driver is working fine.
Solved!
Go to Solution.

Yep, it's the same virtual machine. I set it up almost 2 years ago and it has been extremely stable. Both LabVIEW 8.5 and 2010 have been perfectly happy on it. It's a great way to do LabVIEW on Win7. I didn't notice any changes at all to the VM when I upgraded from Snow Leopard to Lion. I installed LabVIEW 2010 before upgrading to Lion, but I didn't have occasion to work with 3D controls before the upgrade to Lion so I don't know if it would have worked on Snow Leopard. The Mac versions of both LabVIEW 8.5 and LabVIEW 2010 also work great on the both Snow Leopard and Lion.
I happen to have an XP virtual machine too, but I haven't installed LabVIEW there. Let me know if that would be a worthwhile test.
You might check with Marc Page--unless he has already upgraded again I think he has a similar machine to mine.
The video card is the original stock:
NVIDIA GeForce GT 120:
Chipset Model: NVIDIA GeForce GT 120
Type: GPU
Bus: PCIe
Slot: Slot-1
PCIe Lane Width: x16
VRAM (Total): 512 MB
Vendor: NVIDIA (0x10de)
Device ID: 0x0640
Revision ID: 0x00a1
ROM Revision: 3386
Displays:
Cinema HD Display:
Resolution: 2560 x 1600
Pixel Depth: 32-Bit Color (ARGB8888)
Main Display: Yes
Mirror: Off
Online: Yes
Rotation: Supported
Display Connector:
Status: No Display Connected

LabVIEW crashes when you run a VI that contains a mixed signal graph with a multi-plot cursor.

Hello, LV 8.2.1 notes indicates the following bug fix:
43SAIR2A Fixed an issue where LabVIEW crashes when you run a VI that contains a mixed signal graph with a multi-plot cursor.
I am running this version, and still have this behavior. Is there anything I may be missing, and/or certain circumstances that may still be causing this?
thanks in advance,
Darren

Darren:
I looked at the CAR ID that you mentioned and the issue has been resolved in LabVIEW 8.2.1. To verify something similar, I ran the attached VI and things worked just fine. Please feel free to send me the steps to follow to reproduce the issue you are running into in 8.2.1.
Regards,
Rudi N.
Attachments:
MixedGraphs.vi ‏15 KB

Labview crashes with Excel ActiveX

Dear all,
I have written a program to read and write the data in the
excel using ActiveX sheet but crashes the Labview drastically when
executed.
Please go through the attached files.
Actually the program has to sort the data in ascending order in a
column in a
Specified worksheet and it should write the sorted data in another
worksheet in the same excel file itself. But while writing it should
neglect the repeating data and should write the corresponding data in
the other column with respect to sorted one.
For example , In datafile.xls in sheet1 cells are like below. Let a,
b & g are columns
a1=0.02, b1=2.1 , g1=0.1
a2=0.04, b2=4.2 , g2=0.3
a3=0.05, b3=4.2 , g3=0.35
a4=0.06, b4=4.3 , g4=0.43
a5=0.0
7, b5=7.1 , g5=0.43
a6=0.08, b6=7.2 , g6=0.43
a7=0.09, b7=7.2 , g7=0.75
a8=0.11, b8=7.4 , g8=0.75

I am not sure what is causing the crash. Can you give us more information? For example what does the crash say, when you relaunch LabVIEW does it comment on an error log file?
The code you mentioned was not attached, so I was not able to try and reproduce it. I would be happy to try it here, if you can attach it.

LabVIEW crashing when running NI-DSP VI on Windows XP

I am in the process of upgrading a software application from LabVIEW 3.1 on Windows 3.11 to LabVIEW 7.0 on Windows XP with NI-DAQ 7.2. The hardware has been replaced, the relevant hardware change here is from the AT-DSP2200 to the NI-4551.
The source code uses the NI-DSP libraries to control the DSP2200. I can't find any equivalent in the new LabVIEW (and have assumed that there is none, this is all covered in the MAXX now). The source code has been convereted to LabVIEW 7.
When the source code is opened on the Windows XP machine LabVIEW crashes. I've traced to cause of this crash to the NI-DSP code. Whenever I try to open any VI that contains the DSP code it crashes LabVIEW. I think the problem is the CNI call
inside the DSP library. When I try opening the source code on a computer that doesn't have the NI-4551 installed there are no problems.
What is the upgrade from NI-DSP to? Is there a direct mapping of NI-DSP functions to equivalent NI-DAQ ones? How is it that having the hardware plugged in causes a crash even though it shouldn't be accesssed until I run the VI?
Any help would be appreciated.
Thanks.

Hello EborLance,
The NI-4551 can use either NI-DAQ or NI-DSA as the driver. If you only have NI-DAQ installed, any program that uses the NI-DSA functions may be crashing.
There is no direct mapping of NI-DAQ functions to NI-DSA functions but you can download and install the NI-DSA driver from the website. Current DSA Drivers
Once you have installed the NI-DSA driver, you should see the functionality you were previously used to and your program should run.
Thanks,
C. Flip
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 crash on lvdaq.dll

Labview 7.1 crashes when dropping any Traditional Daq on diagram. Traditional daq version 7.3.
Mass compile crashes when lvdaq.dll is displayed, have removed and reloaded traditional daq
Any ideas ?
thanks
Mike

Hi Mike,
Thank you for posting to the NI Forums! I have searched out database and have not found any reported issues with Traditional DAQ causing LabVIEW 7.1 to crash. Traditional DAQ version 7.4.4 is the latest version that is compatible with LabVIEW 7.1 I would recommend upgrading to this version to see if this fixes the problem. Be sure to read the readme for this version of Traditional DAQ as there are some specific installation instructions. Hope this helps! Let me know!
Regards,
Margaret Barrett
National Instruments
Applications Engineer
Digital Multimeters and LCR Meters

Labview crashes upon opening a specific VI

In LabVIEW 6.1 in Mac, LabVIEW crashes everytime I open a specific VI. I went to this article (http://digital.ni.com/public.nsf/allkb/8C333947DE8EC423862567AC00510975) also known as KnowledgeBase entry 1NB8NIU0. I downloaded Macsbug and followed instructions. When LabVIEW crashed, Macsbug openned. I typed stdlog, clicked enter, but no log was generated on the desktop as the knowledge base article indicated. Can anyone help me troubleshoot this? (I'm running Mac OS 10.4.9. Labview opens Mac OS 9 classic when it runs. I don't know if this has anything to do with it.)
Thanks,
Nathan Fast

Hi Nate,
This is odd. Do you have any previous versions of this file? If so, could you please let me know what may have changed in the code between when it worked and when it caused LabVIEW to crash? At this point, a workaround would probably be the best bet in order to get the code back up and running.
Best regards,
Steven

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

Internal error or labview crash in 7.1ver thread.cpp(2842) whats reasons and how to fix it

Hi
Everybody ,
I am working with pci-6723 and labview 7.1 yesterday when iwas testing , the programme was running , suddenly the power has gone , since i have not connected my system to UPS system got shutdown , and when i booted pc its higlighted this error , now to what extent this problem affects to my software, and how to fix it.
"Internal error or labview crash in 7.1ver thread.cpp(2842) whats reasons and how to fix it"
Thanks in advance
Rajesh

Hello Rajesh,
Do you get this error frequently or you got it only once after the power shutdown? Are you making a call to a DLL in multithreaded environment? Try mass compiling the VI by going to Tools->Advanced->Mass Compile. Also please follow the suggestions provided in this knowledge base entry regarding thread.cpp and see if that will fix the problem:
http://digital.ni.com/public.nsf/websearch/01B186B5CEB1D07786256747000F4319?OpenDocument
If you continue to have this error, is there any way you can send me a pared-down example demonstrating what your program does, so I can at least investigate to see if I can narrow down the cause of the thread.cpp failure?
Thanks and good luck!
Shakhina P.
National Instruments

Solenoid causing LabVIEW crash?

Similar Messages

Maybe you are looking for