LAVA Forums Buy cool LAVA gear Forums RSS Feed

Welcome Guest ( Log In | Register )

Tags
This content has not been tagged yet

> Related links

Visit our LabVIEW Wiki External Code Portal.


 
Reply to this topic Start new topic
> Preventing an unstable ActiveX component from crashing my application?
ned
post Jun 12 2008, 01:36 PM
Post #1


Very Active
***

Member
Posts: 110
Joined: 26-January 06
From: Cambridge, MA
Member No.: 3989
Using LabVIEW Since:1999
LV:8.5 ,8.6 ,.
United States us_massachusetts Nothing Selected


I'm using an ActiveX component that crashes every once in a while (maybe once a month). When it crashes, it takes down my entire application. If I use VI server calls to launch the VI that contains the component, instead of calling the VI directly, will my application continue running even if the ActiveX component crashes (and if so, do I need to use the Run VI method instead of call by reference)? Is there an easy way to detect that the VI has crashed and I need to restart it? Unfortunately due to the infrequency of crashes, and my inability to cause them consistently, I can't test this out easily.


Tags
This content has not been tagged yet
Go to the top of the page
+Quote Post
Ad
post Jun 12 2008, 01:36 PM
Post #















Tags
This content has not been tagged yet
Go to the top of the page
Quote Post
Tim_S
post Jun 12 2008, 02:59 PM
Post #2


Very Active
***

Member
Posts: 91
Joined: 23-February 06
From: Detroit, MI USA
Member No.: 4230
Using LabVIEW Since:1994
LV:8.0.1 ,8.5.1 ,7.1
United States Nothing Selected Nothing Selected


QUOTE (ned @ Jun 12 2008, 09:36 AM) *
I'm using an ActiveX component that crashes every once in a while (maybe once a month). When it crashes, it takes down my entire application. If I use VI server calls to launch the VI that contains the component, instead of calling the VI directly, will my application continue running even if the ActiveX component crashes (and if so, do I need to use the Run VI method instead of call by reference)? Is there an easy way to detect that the VI has crashed and I need to restart it? Unfortunately due to the infrequency of crashes, and my inability to cause them consistently, I can't test this out easily.


I don't know if using VI server to run the containing VI will help; I expect you'll get the same results. As for detecting if the application has crashed, something to consider is a separate "watchdog application". This separate application regularly checks for your application or regularly receives a ping from your application (within a timeout). If the watchdog application detects your application went out to lunch, it can restart the monitored application. My VB counterparts use this to ensure that their critical RT applications stay running (funny what users will shut down when they perceive the system is running show).


Tags
This content has not been tagged yet
Go to the top of the page
+Quote Post
ned
post Jun 12 2008, 04:57 PM
Post #3


Very Active
***

Member
Posts: 110
Joined: 26-January 06
From: Cambridge, MA
Member No.: 3989
Using LabVIEW Since:1999
LV:8.5 ,8.6 ,.
United States us_massachusetts Nothing Selected


QUOTE (Tim_S @ Jun 12 2008, 10:59 AM) *
I don't know if using VI server to run the containing VI will help; I expect you'll get the same results. As for detecting if the application has crashed, something to consider is a separate "watchdog application". This separate application regularly checks for your application or regularly receives a ping from your application (within a timeout). If the watchdog application detects your application went out to lunch, it can restart the monitored application. My VB counterparts use this to ensure that their critical RT applications stay running (funny what users will shut down when they perceive the system is running show).

A watchdog isn't quite what I want here. The ActiveX component handles printing specialized labels in a dispensing system. Whenever I finish one batch (or one size), I call a VI, containing the ActiveX component, to print the next batch of labels. If it crashes, I'd like the rest of the machine to keep doing what it's supposed to be doing, and seemlessly restart the print job. I suppose I could do it the other way - write a daemon that sits and waits for print requests as a separate application, and then if the main application fails to connect to the print daemon it could restart it.


Tags
This content has not been tagged yet
Go to the top of the page
+Quote Post
rolfk
post Jun 18 2008, 08:39 AM
Post #4


Extremely Active
****

Premium Member
Posts: 955
Joined: 9-April 04
From: Rotterdam
Member No.: 349
Using LabVIEW Since:1992
LV:8.5.1 ,8.2.1 ,7.1.1
Netherlands Switzerland Nothing Selected


QUOTE (ned @ Jun 12 2008, 12:57 PM) *
A watchdog isn't quite what I want here. The ActiveX component handles printing specialized labels in a dispensing system. Whenever I finish one batch (or one size), I call a VI, containing the ActiveX component, to print the next batch of labels. If it crashes, I'd like the rest of the machine to keep doing what it's supposed to be doing, and seemlessly restart the print job. I suppose I could do it the other way - write a daemon that sits and waits for print requests as a separate application, and then if the main application fails to connect to the print daemon it could restart it.


Your last suggestion is the only real solution.

ActiveX has in theory the possibility for a library to be invoked in various modes. One is out of process invokation in which case the ActiveX object is instantiated in its own server process and communicates through RPC and a proxy library with the client. However almost no ActiveX component supports this mode and they are almost all in-process servers. This means they run inside the process that is instantiating them and therefore can affect and also take down that host process. I'm not even sure if LabVIEW does support out of process instantiation of ActiveX components. If it does it won't be a well tested scenario since there are so few ActiveX components that would even support that.

Rolf Kalbermatter


Tags
This content has not been tagged yet
Go to the top of the page
+Quote Post


Reply to this topicStart new topic

 




Time is now: 29th August 2008 - 06:51 PM