Jump to content

strange Labview behavior on server


Recommended Posts

Hello all I have a very strange problem that I am not sure what category it falls under smile.gif

When I modify a vi (details below) it runs fine on my development box for hours...the development box runs dual core centrino with windows xp.

When i transfer the same modified VI to my server it will run for about 5 minutes or so and then labview instantaneously closes with no windows or error messages popping up. there are also no error messages when labview is restarted. the server has 8 core xeon processor and is running windows server 2003.

I am wondering if the additional cores is causing a problem related to labview trying to multi-thread the vi using all cores? so when it try's to divide the code and run in parallel it is messing with the vi timing somehow?

The modification to the vi is below:

post-16790-125978121455_thumb.jpg

Unfortunately i cant send the entire vi, but this snippet sits in a wait loop and monitors an open adodb connection, this connection must stay open for very long periods (it is part of a web portal) and the DB will time out the connection at times.

the ado get connection properties vi is monitoring the adodb connection and if the db drops the connection the true statement reestablishes it. The db connection and error outs are wired to a large loop that is monitoring for events related to date time. I would think this wiring should force the two to be run serially but i am not sure...

If this snippet is disabled or deleted from the VI it runs fine

Does anybody out there have any ideas or perhaps know of another reason labview maybe shutting down on its own? and why it would work fine on the "smaller" box but not the server?

Any help would be greatly appreciated smile.gif

thanks Chris

Link to comment

Hello all I have a very strange problem that I am not sure what category it falls under smile.gif

When I modify a vi (details below) it runs fine on my development box for hours...the development box runs dual core centrino with windows xp.

When i transfer the same modified VI to my server it will run for about 5 minutes or so and then labview instantaneously closes with no windows or error messages popping up. there are also no error messages when labview is restarted. the server has 8 core xeon processor and is running windows server 2003.

I am wondering if the additional cores is causing a problem related to labview trying to multi-thread the vi using all cores? so when it try's to divide the code and run in parallel it is messing with the vi timing somehow?

The modification to the vi is below:

post-16790-125978121455_thumb.jpg

Unfortunately i cant send the entire vi, but this snippet sits in a wait loop and monitors an open adodb connection, this connection must stay open for very long periods (it is part of a web portal) and the DB will time out the connection at times.

the ado get connection properties vi is monitoring the adodb connection and if the db drops the connection the true statement reestablishes it. The db connection and error outs are wired to a large loop that is monitoring for events related to date time. I would think this wiring should force the two to be run serially but i am not sure...

If this snippet is disabled or deleted from the VI it runs fine

Does anybody out there have any ideas or perhaps know of another reason labview maybe shutting down on its own? and why it would work fine on the "smaller" box but not the server?

Any help would be greatly appreciated smile.gif

thanks Chris

With the limited data I can only guess that the Global holding the reference is suffering from a race condition.

Ben

Link to comment

Ben,

thanks for the quick reply, and that makes sense, but debugging this would be a new area for me, any tips on how i could determine if it is? and how to fix it? (or can you point me to some documentation that may help?)

thanks again Chris

Trouble shooting intermitant problem is not easy particularly if I can't see the code (not implying I want to shifty.gif ).

As I wrote above I was just guessing at it being a race condition since globals are wonderful for demonstrating them.

The best I can do now is (and it will sound drastic) recomend you wrap all of the functionality associated with that reference in an Action Engine with an approriate set of actions so that the the reference never leaves the AE but is used exclusitvely in the AE.

Here is the Nugget I wrote on AE's if you are curious.

http://forums.ni.com/ni/board/message?board.id=170&message.id=240328#M240328

Ben

Link to comment

Ben thank you an excellent nugget of which I am still trying to digest all of it, but I think the concept will actually help me in some other apps as well :)

Ton, Thanks, I will try that, although this solution was an attempt to get of af a worse memory leak from our first attempt at keeping the connection alive. Unfortunatly i do need to keep the global as it is being populated in order for a multitude of other VI's in the portal system to use. the get connection that continues on is being used internally in the vi as well.

thanks again, I will let you know how it goes when I get all of the proposals tested....

Chris

Link to comment

Is Windows server 2003 a supported target for LabVIEW 2009? I know that it specifically WAS NOT under prior versions, though over the years there have been reports of folks running LV apps on WS2003. I'm just asking to point out that you may not be able to get support from NI for any issues you have. Whether this is an issue for you, I couldn't say.

Along other lines, have you checked the Windows event log on the target? Perhaps there is an application error event getting recorded which could suggest what's going on.

Good luck!

Dave

Link to comment

Ben thank you an excellent nugget of which I am still trying to digest all of it, but I think the concept will actually help me in some other apps as well :)

Ton, Thanks, I will try that, although this solution was an attempt to get of af a worse memory leak from our first attempt at keeping the connection alive. Unfortunatly i do need to keep the global as it is being populated in order for a multitude of other VI's in the portal system to use. the get connection that continues on is being used internally in the vi as well.

thanks again, I will let you know how it goes when I get all of the proposals tested....

Chris

I know that you probably don't want to hear this but as Ben suggested I would seriously consider removing the globals from your application. There are much better and safer ways to share information between parallel tasks. These include action engines, queues and notifiers.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.