Long term experiment application error

[baseball07]

Hi I am running a long term experiment where I am continuously reading in and plotting/saving Bluetooth Data, using a LabVIEW executable.  After about a day, a pop up appeared titled:

"SMessaging.exe - Application Error"

Application has generated an exception that could not be handled.

Process ID=0xe4c (3660), Thread ID=0xe7c (3708)

Click OK to terminate the application.

Click CANCEL to debug the application.

Nothing appeared in my Error Handler list, however when I cleared the pop-up error and ran the vi again, Code 1: source - ??? in btnew.vi appeared and the vi wouldn't run, I had to shut down the computer.

Is it something to do with the .exe build that I made? I am running Windows XP with the LabVIEW runtime. 

[joaopam]

EDIT 11:14 AM GMT -3:00:

So far this is useless, because the user is running an application built with LabVIEW 2010. I don't know if the 2010 version has the exactly same problem.

---

When you said that this happened about a day, I remembered something.

What version of LabVIEW are you using currently?

In LabVIEW 2012 there's a known issue that happens in the same context.

BUT, I'm not sure if the error quoted and your error are correlated, besides the execution duration (1 day).

Hope this helps you.

Regards

[baseball07]

I developed the vi in LabVIEW 2010, SP1 and built an executable which I am running off a different machine using LabVIEW Runtime engine.

[joaopam]

So please ignore my message. 😞

I will do some researches and see what I can find.

Sorry if that didn't help.

Regards

[Norbert_B]

It seems to me that the error popup is a OS dialog, a so-called "unhandled exception" dialog.

After acknowledging that dialog, are you sure the the process is shut down? (look into Windows Task Manager for this, use the "processes" tab)

If the process is killed, but the resource (Bluetooth interface) is still blocked, it indicates that a service is still accessing this device. If the service is stuck or simply running wild is something difficult to find out. Maybe you can try to reset the device using the Windows Device Manager.

You should observe memory consumption and CPU load (use PerfMon and log the data) and check if immediatly/some time before the crash something unexpected happens here.

Additionally, make sure that the PC does not go into power save or hibernate as this could interfere in the communication.

hope this helps,
Norbert

[camerond]

Since you didn't provide any code for us to examine, it'll involve some lucky guessing to solve your problem.

However, two relevant questions come to mind (having nothing to do with each other) :

1.  Does this problem happen when you are running the non-executable, i.e., the VI under LabVIEW?

2.  How much data are you getting/plotting/saving? Are you trying to build an array in memory which could use up GBytes, using all available RAM?

If the answers are "No" and "Not too much, No" then you'll probably have to provide more data about the problem.

Cameron

[baseball07]

No I have not tried to run the vi under LabVIEW, I am going to do that today.  Here is my code.  The program receives in 6 bytes of data every 4 minutes, so I am doubtful that the memory is being consumed. Could the graph only display a certain amount of  continuous data?

[crossrulz]

A couple of quick theories.

Is the Bluetooth hooked up via USB?  If so, the OS could be cutting power from the USB hub and therefore your Bluetooth messaging will have a major error.  It is a power saving feature.  This can be fixed via the Device Manger and changing the USB power settings.

Usually when tests go a long time and suddenly die it is due to a memory leak.  These memory leaks are usually from building arrays.

[camerond]

Well, two things stand out to me:

1.  Your inner loop has no timing. That means it is going to run as fast as possible, taking up 100% of the CPU until it is told to stop. And it is only told to stop when you get an error. You cannot stop it without hitting the Abort (stop sign) which screws up everything. And if anythng else comes along that wants to use CPU time, they're going to have to fight for it.

2.  Your outer loop also cannot be stopped without hitting the Abort, because you have wired the F to the stop loop terminal. Again, not good.

I have no idea how you can stop your executable without just turning it off (might even have to go into Taskmanager to do so, but you'll have to fight for CPU time).

You would be much better off putting some reasonable timing in there so you could at least stop things manually, as I assume you are going to want to stop the program sometime, unless the Bluetooth signal you're reading is actually a "5 minutes to Doomsday" signal and you want to be sure you are ready.

The comments by others about what might happen when the PC sleeps/hibernates/etc. are also relevant, unless you have disabled this.

Programs are much easier to troubleshoot before they are compiled into an executable.

Cameron

[baseball07]

Thanks for the suggestions.  I am aware of the inner loop and program stopping issue which I am working on.  I have posted about this before and got some nice help from other forum members.