Labview program freezes computer completely but resumes after 5 minutes

[Cowbell]

- Its running win 7, either home or professional... I can check on that when I'm at the computer.

- Since I realized that this "crash" is recoverable, I haven't bothered to touch anything when it happens. Before, I would move the mouse to try to open task manager, or alt tab to windows explorer, but it wouldn't ever really "open" either (they would be lighter on the task bar suggesting they were "open" but the screen didn't change from showing the labview program.

- I will put the task manager and resource monitor up next time I run it to see if there is any activity. My guess is that they would both hang.... but I have not verified this.

Other things:

- I will also try to use a different PC as the LabView PC and see if I still have problems there. Maybe its just that the laptop we use for that isn't that great. Its a refurbished one we got on the cheap, so that's definitely a possibility.

- I mentioned that my labview program connects over TCP/IP to a master computer which sends the program string commands. I also have the labview computer connected to a linear stage controller over TCP/IP (as a VISA resource). Everything's plugged into a hub and has the same first 3 parts of their IP address the same. Could I have any problems arise from this configuration, that I have a program which uses both a VISA resource and a TCP/IP connection?

- Along theses lines... I used to connect with the linear stage controller via serial port, but the physical location of it made it a lot easier to plug that into the hub and connect to it via the network. A result of this is that I still use VISA Write and VISA Read to transmit/receive data. I used to use "bytes at serial port", but that doesn't apply, and looking around it seems like one way people get around this is to have the sender first send the bytes its going to transmit later, then set the read buffer to that size. Since I can't program the linear stage controller to do this, what I have been doing (which seems like a pretty bad workaround, but it works?) is to read a larger buffer than I expect (say, 50 bytes), and set a short timeout on the VISA Read, then have the clear errors right after this. Is it possible that over time, something is messing up here? I should also note that I have a totally separate program with a totally separate linear stage controller that communicates this way over a direct Cat5 crossover cable (so no hub is needed), and I do not have this hanging problem with that setup. The only difference in that case is the PC that runs LabView is different. This all leads me to believe that that the laptop I'm using might just be a bad computer...

[JÞB]

That's a clue....

Shaking my magic 8-Ball gets me wondering

"is there a greedy loop in that code?"  I'll bet there is! with probably some 300000mSec timeout.

[Cowbell]

The only default timeouts I see are with the TCP/IP read/write functions (default: 25000ms)... I manually set those to 10ms. I also set the VISA resource for the linear stage controller to 5ms using a property node right after the connection is opened....

Again, its not always the same state that sees the "crash" (i.e. sometimes its in the idle state, sometimes its in a state which uses an arduino, etc), and 99% of the time all the states run perfectly fine....

[billko]

---

@Cowbell wrote:

The only default timeouts I see are with the TCP/IP read/write functions (default: 25000ms)... I manually set those to 10ms. I also set the VISA resource for the linear stage controller to 5ms using a property node right after the connection is opened....

Again, its not always the same state that sees the "crash" (i.e. sometimes its in the idle state, sometimes its in a state which uses an arduino, etc), and 99% of the time all the states run perfectly fine....

---

I'm curious - why would you set your timeout so low?  What if you had a little glitch in communications?  1000 ms might be a better compromise.  The timeout value controls how long the connection will wait before assuming no response.  I would give my equipment as much time as reasonable for a response.  I usually grant timeout values measured in seconds, not milliseconds.  It could be every so often you miss data and whatever is expecting the data gets all confused when it receives none.  (I have no idea how your code traps errors.)  Maybe all you need to do is increase the timeout values.

[stephencox]

You're using a crappy secondhand Windows laptop and you're having problems with freezing.  This isn't exactly shocking.  I still don't understand why you've leapt to the conclusion that Labview is the cause.  Did you try to see if the problem disappears if you stop using Labview yet?

[wiebe@CARYA]

The VISA TCP\IP interface doesn't have a Bytes at Port. It's somewhat understandable, but very inconvenient.

I usually (when I can make both sides) go for the "size of message", or, and I prefer that, for the CR\LF approch. When everything you send ends with a cr\lf (you might need to escape \r and \n), you can use the \r\n option to read the data. At least when using the normal TCP\IP functions. I'm not 100% sure visa can use this option when using TCP\IP, it might be a serial feature, like the bytes at port.. This is more stable then the "size of message", since it will recover when you lose track. When you for some reason (timeout) don't read enough bytes the next read might get data bytes that are parsed as "size of message". This can be hard to recover from.

[wiebe@CARYA]

Googling Windows 7 hangs for 5 minutes still gives a lot of hits.

Likelly suspects seem to be, Quick start, Power options, overclocking, memory failure.

I'm hoping you are doing a pro bono or student project. For a commercial project, a new laptop would be the solution. Even if it turns out to be LV or the program, you'll save so much time knowing that fact that the laptop will be a cheap investment.

[Cowbell]

Unfortunately not commercial, just a startup trying to show proof of concept of an automated platform. We're getting to the point where money is tight or I'd have already bought another laptop. I'll try it on the "better" laptop we have and see if that fixes anything. I think from all these replies its definitely pointing at a computer issue. We'll check it out. I'll reply back if a better laptop works!

[wiebe@CARYA]

>Unfortunately not commercial, just a startup trying to show proof of concept of an automated platform.

that's a valid reason as well.