Labview 8.5.1 Newer not better?

[JSInc]

I also have bad experience with Labview 8.5.1.

It crashes so often when I save my vi, then I lost all my changes.

Even I reinstalled Labview, it still happens the same.

I am considering installing the 8.5.0 now.

[CarlaU]

Hi JSInc,

I'm sorry you are having so many crashes. Are you getting a cpp error and if so, do you keep getting the same one? Do you think you could post the VI that is causing the problem and the steps taken to reproduce it?

[RTSLVU]

Sorry it took so long to get back to this, but here is my source code. At least I hope everything was included, but without identical hardware I am not surehow you will run it anyway.

This version seems to run fine since I have disabled the webserver and stopped using remote panels through Internet Explorer to access it.

We are using tight VNC to do a remote desktop now for monitoring.

Message Edited by RTSLVU on 05-02-2008 12:24 PM

[JSInc]

Hi CarlaU,

Unfortunately I can not post the VI at this moment.

After so many crashes I move to a PC with LabView 8.5 and NI DAQmx 8.6.0f6 to do the modification. I use the DAQmx to simulate PXI 6123 and PXI 6221, they are used by the VI.

Then I open the VI on the second PC with Labview 8.5.1 and NI DAQmx 8.6.1f0, still simulate PXI 6123 and PXI 6221, it runs fine.

But when I try to open the VI on the third PC with LabView 8.5.1, NI DAQmx 8.7.1f3, simulated PXI 6123 and PXI 6221, LabView crashes before the VI completely loaded. It occurs every time when I try to open the VI.

Please see the attachment for the screenshot.

JSInc

[JSInc]

After upgrading the NI DAQmx on my second PC to version 8.7.1f3 , the same VI now crashes Labview 8.5.1 every time I open it.

I will try to post a modified VI at a later time which can crash Labview 8.5.1 & NI DAQmx 8.7.1f3 combination.

Message Edited by JSInc on 05-03-2008 12:04 AM

[CarlaU]

Hi JSInc,

Thanks for the information. The VI that is causing the crash would definitely help (or at least a screen shot of the block diagram). I would say that for the meantime, lets still to using 8.5.1 with DAQmx 8.6 until we can figure out the cause of the crash. Do you also have a screen shot of what the error looks like?

[JSInc]

CarlaU,

Attachment in message 14th was the screenshot I got.

Even with 8.5.1 and DAQmx 8.6.1, there is still very good chance I can not build my application sucessfully. Therefore I have to work under 8.5.0 and DAQmx 8.6.1 now. Since I don't know how to uninstall the runtime engine 8.5.1, it is still showed in the MAX. And the built application seems work on my PXI box with runtime engine 8.5.1 and DAQmx 8.6.1.

Regards,

JSInc

[The Specialist]

Personally I find 8.5.1 to be more stable.  To track down the issue is there an error log we can look at on your cRIO controller (you get it through MAX I believe). How does the crash occur?  Is it just the program stops running after a certain amount of time?  Maybe there is a certain peice of code that runs before the problem.  Is there anything else related to the problem.

Also, DAQdude, do you have another post, because your problem does not seem to be connected. 

[The_Seeker]

To follow up on my previous posting, I haven't had a chance to track down the source of the memory leak in my PXI test application yet -- other priorities have taken me off that project for the time being. However, I can offer some additional insight based on an installation I put in last week.

Originally, we had planned to install the new system with 8.5.0. The one nagging problem with 8.5.0 build was the time it sometimes took for the the shared variables to bind during the start-up cycle. Typically, we would fire up the PXI RT application first, then run the PC HMI (Windows) application. The start-up cycle could take anywhere from 25 seconds to a couple of minutes. The time difference appeared to be mainly due to the time it took the PC to locate the PXI on the network and bind to the shared variables. Another problem was that occassionally, we would see an empty shared variable or two. The status in the variable manager window was always "Good", but when you attempted to write and read the variable there was no value in it. Numeric values were always 0.00, and strings were zero-length. A posting elsewhere in the forums led me to believe that others had also been having intermittent troubles with the shared vaiables in 8.5.0.

So last Wednesday, I decided to bite the bullet and try the 8.5.1 upgrade as a possible solution to these problems. (At this point, the apparent memory leak that had surfaced during my initial experiments with 8.5.1 was front and center in my mind. However, based on the comments of others in this thread, I decided to plow forward.)   

I would just like to say that I'm glad I decided to proceed with the upgrade. The start-up cycle is quicker now, and the overall response of the HMI app seems somehow better -- crisper, in a way. We have seen a few spurious shared variable errors appear in our application's error log window, but these appear to sort themselves out after a few loop cycles. 

We did have one system lock-up yesterday, but I suspect this could have been a queue error that wasn't trapped properly (an oversight on my part). For right now, I'm just going to watch and wait... but for the time being at least, it seems like 8.5.1 is a better option than 8.5.0 for our application.     

-- D.

[JimSchwendeman]

I'm also having an issue with semi-regular crashes, and not fully sure as to what's going on...  A couple of things that are happening on 8.5.1 that I've not experienced before.

1.)  I get a prompt saying Labview experienced an error, would I like to continue or stop.

2.)  Labview will crash and completely close all instances of Labview?  But here's the funky thing, it typically does not occur until the last sequence runs (the disable and email notification).

Thoughts?

.jim