Labview DAQ freeze when pc is connected to network

[MoFiggin]

We are having the same problem on multiple PCs were if the computer isn't connected to the network the exe will run for days with no problems but if the same computer is connected to the network via Ethernet the DAQ will stop running after a random amount of time, usually that same day. I am never there when it does freeze but our IT guy says that all he has to do is go into NI Max and reset the 6501 DAQ card and run the program to get it going again. 

The pc is using the DAQ to send and receive signals, and a GPIB USB to SR720 LCR meter to receive data. Running on LabVIEW 2013

[MoFiggin]

I cleaned up the program previously attached but it has not been tested yet. It is almost exactly the same though if it helps to look at this one since the previous version has a surplus of unnecessary wire connections.

[GerdW]

Hi Mo,

---

@MoFiggin wrote:

I cleaned up the program …

---

No, you did not!

• Way too much local variables!
• Way too many sequence frames… (What's the point of that 1-frame sequence around your main while loop???)
• No error handling…
• …

There are also missing subVIs, missing DAQmx definitions, missing typedefs…

When the VI "freezes": at which operation/subVI does it freeze? Does it really "freeze" or simply run with missing DAQmx interaction?

Implementing some error handling might be of good use here…

[MoFiggin]

I am new to LabVIEW and I was unaware that stretching a wire across the block diagram is better than making it a local variable. I just meant that the original was covered in wires that were sometimes hard to follow. I ordered LabVIEW graphical programming by Richard Jennnings and Fabiola De La Cueva to learn more about it. I didn't write the original program and used it to learn LabVIEW as I recreated it.  

The outside sequence frame was supposed to have a second frame to exit program like in the original. I just forgot to add it. Some of the subVI's are just written out instead of in a subVI, like putting the test head up and down, as I was trying to learn how it was all working. 

So its better to run wire connections than to make local variables?

Besides the outer frame which frames needed to be removed?

The freeze happens during the testing possible during the retest since it gets stuck somewhere with the test head down.  I hope the book helps with error handling as I have only seen the error in and out options but it doesn't have the terminal on a lot of the parts. 

edited as I didn't originally see whole reply

[Bob_Schor]

Most LabVIEW Functions (and 98% of the sub-VIs that you create) have (or "should have") Error In and Error Out terminals in the lower corners of their icons.  To "serialize" (or "sequence", or "order") LabVIEW actions, you connect Error Out from one "block" to Error In on the next.  One thin line (carrying potentially very important information!) gets operations running in a much "cleaner" order than using a Frame Sequence.  [Don't worry -- if you stick with LabVIEW for enough years, you may encounter Frame Sequences again in LabVIEW FPGA programming, where Error lines are not present ...].

When you start using Wires, remember these "Style" principles that will help you write "more readable" code:

• Wires enter Functions and Structures from the left, and leave them from the right.
• Data should (almost always) flow from left to right.
• Try to keep wires running with as few bends as possible (it helps line up your functions and sub-VIs as well).
• More readable code is generally easier to write "correctly the first time", easier to understand, and easier to debug.

Bob Schor

[JÞB · Accepted solution]

I didn't look at the code but follow Bob's excellent advice.  Read the book you ordered! And look here You may find the style guide a useful resource to improve your code http://www.ni.com/pdf/manuals/321393d.pdf#labview_style_guide

( let me know if that link is now obsolete)

One thing you mentioned give me a very good clue.  "I am never around when it freezes" and a DAQ reset from MAX helps.

Check your Windows Power Manager settings! Windows defaults to shutting down USB hub power when there is no user activity!  Of course that shuts off the DAQ device.  Use the Device Manager to change the Power Settings for the USB Hubs.

---

[MoFiggin]

Thanks for the tip, that does sound like a good culprit. Strange it only happens while the computer is connected to the internet. I went and changed the settings on the computer, reconnected the Ethernet cable, and will most likely know by the end of the day if it causes problems or not. I will return with results of the change tomorrow. 

I am looking forward to getting the book, for some crazy reason it is taking a while over a week to get here from amazon. 

[MoFiggin]

So the parts I have in the Frame Sequence need to happen in order but most of the stuff has no error in & out. Do I need to convert the frames into subVI's and get rid of the frames?

I have been messing around with LabVIEW for a little over a week and I get the left to right structure of things but it seems like everything inside of a frame executes at the same time without the error in and out option. Are you saying I need to get rid of all Frame Sequences? 

Thank you for your time

Jeff

[JÞB]

---

@MoFiggin wrote:

So the parts I have in the Frame Sequence need to happen in order but most of the stuff has no error in & out. Do I need to convert the frames into subVI's and get rid of the frames?

I have been messing around with LabVIEW for a little over a week and I get the left to right structure of things but it seems like everything inside of a frame executes at the same time without the error in and out option. Are you saying I need to get rid of all Frame Sequences? 

Thank you for your time

Jeff

---

Since you are brand new to LabVIEW I'm going to train you right!

If you ever start a new vi from a blank vi think twice!

It is much better to start from a template using "File>>New..."

Look at that!  The description even reads "Use this template to build a vi to use as a sub vi."

[Bob_Schor]

---

@MoFiggin wrote:

Are you saying I need to get rid of all Frame Sequences? 

---

Jeff,

     Until you've been doing LabVIEW for a few years and are starting to write code for LabVIEW FPGA, you should very rarely need a Frame Sequence (so, yes, Get Rid of All Frame Sequences).  You do not need to make everything a sub-VI -- what you need to do is use the Error Line when you need to make code run in "sequential" (as opposed to "in parallel") operations.  Until a few years ago, when Malleable VIs (".vim") were introduced, almost the only time Frames were required was to "place a 100 ms delay between This Function and That Function" (the "Wait (ms)" delay doesn't have Error Lines -- it wants to run As Fast As Possible).  Some of us (such as I) wrote a "Delay (ms)" sub-VI with Error In and Error Out (much prettier than a Frame) to do this, but now I use Stall.vim, which can be placed on any wire, including the Error Line.

Bob "Error Lines, Not Frames" Schor