LabVIEW 2016 crashes when communicating with Newport CCD and or monochromator

[clmartinez100]

Two USB/serial devices that LabVIEW communicates with will suddenly crash LV at random times.

We've increased the time to "close" the device between commands, and that helped quite a bit.  Increasing the time more has not helped further.  The 2 suspect devices are:  1) Newport/Oriel CCD Linespec array detector, and 2) a Cornerstone MS257 monochromator.  Has anyone has experience trying to use these 2 devices with LV?  Anyone had a similar problem with USB/serial devices?  This is really old RS232 serial interfaces converted to USB.

Thanks! 

[RavensFan]

Any error messages when it crashes?

What kind of crash is it?  Just LabVIEW, a windows crash?  A blue screen of death?

Can you get a screenshot of your PC once the crash as occurred?

Do you need to close the device at all between commands?  Normally communications open the port once, communicate in a loop with Writes and Reads, and close the port only at the end.

What if you only tried to communicate with one device and not the other to narrow it down which device or if both devices are causing a problem?

[Kyle97330]

Unless you're using DLLs to communicate with these devices via serial, it's a virtual certainty that the devices themselves can't cause crashes simply because Serial/RS232 is about the most passive communications bus that exists.

I'd be willing to bet that the problem is actually in the USB to serial converters.  Most (90%) use Prolific chips, which are usually low quality and often counterfeit.  The best use FTDI chips but are more expensive.  I'd start by updating all of your drivers, both for your converters and also for the USB drivers of your motherboard's chipset.  If that fails, try either different Prolific converters or switch to FTDI ones.

[clmartinez100]

Hi There.  Well, it's definitely the CCD camera that has the communication problems and not any other device in the system.

I've programmed a test vi to open the CCD 1 time at the beginning, and collect data from it in a loop, then when finished with the loop, "close" the device.  It got hung up on loop #106 out of 360 at the beginning of the data collection.  It does use a DLL.  I've tried increasing the time between the device subvi's, but that didn't seem to help.

Attached is the experiment vi, and a shot of the LV error message.

Any other thoughts?

Thanks.

[clmartinez100]

Hi There,

Please see the reply below to answer your questions.

Thanks!

[RavensFan]

---

@clmartinez100 wrote:

Hi There,

Please see the reply below to answer your questions.

Thanks!

---

I don't know what this message is about.  If you are replying to a specific message in the thread, then you should use the quote button.

Now you've done some things to narrow down the source of the problem and given some more information that can give a clue.  The error dialog you posted doesn't give very specific information, but seeing the type of dialog helps tell us the nature of the problem.  That kind of crash dialog happens when something is corrupted in the memory of LabVIEW while it is operating.

You said that device uses DLL's and that is where I believe the problem is.  Poorly written DLL's can stomp all over memory that doesn't belong to it and lead to the kind of crash you see.  We can't see the DLL or how it is called because the subVI's that contain those calls weren't included.

Where did you get the subVI's from?  From the manufacturer or are they homemade?  I'm not a DLL guy, but my first thought is that the DLL might not be thread safe.

Someone who is more familiar with DLL's can join in and comment and give more specific help.

[clmartinez100]

---

@RavensFan wrote:

---

@clmartinez100 wrote:

Hi There,

Please see the reply below to answer your questions.

Thanks!

---

I don't know what this message is about.  If you are replying to a specific message in the thread, then you should use the quote button.

Now you've done some things to narrow down the source of the problem and given some more information that can give a clue.  The error dialog you posted doesn't give very specific information, but seeing the type of dialog helps tell us the nature of the problem.  That kind of crash dialog happens when something is corrupted in the memory of LabVIEW while it is operating.

You said that device uses DLL's and that is where I believe the problem is.  Poorly written DLL's can stomp all over memory that doesn't belong to it and lead to the kind of crash you see.  We can't see the DLL or how it is called because the subVI's that contain those calls weren't included.

Where did you get the subVI's from?  From the manufacturer or are they homemade?  I'm not a DLL guy, but my first thought is that the DLL might not be thread safe.

Someone who is more familiar with DLL's can join in and comment and give more specific help.

---

I'm new to the help board, so thanks for the directions.

The DLL came from the manufacturer, but I'm sure it was a subcontractor that wrote the software.  The camera manufacturer doesn't have any experience programming LV or how to troubleshoot their product software.  

What do you mean by "not thread safe"?  Is it worth getting a new copy of the DLL from the manufacturer?  Thanks.

[clmartinez100]

---

@RavensFan wrote:

---

@clmartinez100 wrote:

Hi There,

Please see the reply below to answer your questions.

Thanks!

---

I don't know what this message is about.  If you are replying to a specific message in the thread, then you should use the quote button.

Now you've done some things to narrow down the source of the problem and given some more information that can give a clue.  The error dialog you posted doesn't give very specific information, but seeing the type of dialog helps tell us the nature of the problem.  That kind of crash dialog happens when something is corrupted in the memory of LabVIEW while it is operating.

You said that device uses DLL's and that is where I believe the problem is.  Poorly written DLL's can stomp all over memory that doesn't belong to it and lead to the kind of crash you see.  We can't see the DLL or how it is called because the subVI's that contain those calls weren't included.

Where did you get the subVI's from?  From the manufacturer or are they homemade?  I'm not a DLL guy, but my first thought is that the DLL might not be thread safe.

Someone who is more familiar with DLL's can join in and comment and give more specific help.

---

Here are the subvis that came with the camera.  I managed to "crash" their "Example" program in 3 minutes.  Thanks for you help.

[RavensFan]

I think you'll have to contact the manufacturer then.

"Thread-safe".  https://en.wikipedia.org/wiki/Thread_safety will explain it better than I could.

[550nm]

Hi clmartinez,

It seems "CL Read CCD Area" fills-in an array - is that right?  If so, the "Data" array must be preallocated.  If the calling VI isn't allocating the Data array, then I'm guessing this could be a problem.  It would be easy to modify "CL Read CCD Area" to preallocate the array-space, but I don't know how big the array should be.  Do you know how many pixels are expected and how many bytes-per-pixel?  By the way, I didn't see an example program in the.zip file - can you attach it?