Using MCC hardware, ULx sub-VIs and LabVIEW. Original program included DAQ from two devices (one over TCPIP, which I had never used before). At very early debugging stage, I was getting weird crashing behaviour. LabVIEW would throw an error (wrong variant type, etc.), and when I pressed "Stop," I would get a big, pink box with this error: LabVIEW Exception: Access violation (0xC0000005) at EIP=0x0000025143143310 and an opportunity to send a message to NI. Then the system would hang for close to a minute, then all LabVIEW windows would close. I don't think I've crashed LabVIEW in 25 years of sporadic use.
I removed the second DAQ device and put all channels on A/D board, but that didn't help.
I wondered whether the network-location of my files (new feature of our IT security) was causing permissions errors, so I copied the whole file structure to the desktop of my machine (force local). No joy.
I then wrote a very simple VI to try collecting and plotting (almost) all in one VI (attached). Still kept getting this error and crashing LabVIEW.
Then I plugged in an NI device and replaced all the ULx sub-VIs with DAQmx equivalents (also attached), and it worked just fine, running off of network files and a home WiFi connection. Then I re-wrote the DAQ parts of my huge, multi-threaded monstrosity, and it just throws errors into the handler like it should; no crashing.
It doesn't make a lot of sense to me, but it's hard not to blame the MCC ULx sub-VIs. Is there a software switch/option that I failed to enable?
Question
framjam
Using MCC hardware, ULx sub-VIs and LabVIEW. Original program included DAQ from two devices (one over TCPIP, which I had never used before). At very early debugging stage, I was getting weird crashing behaviour. LabVIEW would throw an error (wrong variant type, etc.), and when I pressed "Stop," I would get a big, pink box with this error: LabVIEW Exception: Access violation (0xC0000005) at EIP=0x0000025143143310 and an opportunity to send a message to NI. Then the system would hang for close to a minute, then all LabVIEW windows would close. I don't think I've crashed LabVIEW in 25 years of sporadic use.
I removed the second DAQ device and put all channels on A/D board, but that didn't help.
I wondered whether the network-location of my files (new feature of our IT security) was causing permissions errors, so I copied the whole file structure to the desktop of my machine (force local). No joy.
I then wrote a very simple VI to try collecting and plotting (almost) all in one VI (attached). Still kept getting this error and crashing LabVIEW.
Then I plugged in an NI device and replaced all the ULx sub-VIs with DAQmx equivalents (also attached), and it worked just fine, running off of network files and a home WiFi connection. Then I re-wrote the DAQ parts of my huge, multi-threaded monstrosity, and it just throws errors into the handler like it should; no crashing.
It doesn't make a lot of sense to me, but it's hard not to blame the MCC ULx sub-VIs. Is there a software switch/option that I failed to enable?
Any advice gratefully accepted.
EE_SuperSimple_DAQ_MCC.vi EE_SuperSimple_DAQ_NI.vi
6 answers to this question
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now