cowen

No - I have been using LabVIEW for about 11 years and have learnt these things the hard way!! - I am absolutely positive that the path is correct. :-) I can't provide my whole project, its much too big, however maybe I can prepare a small functional example demonstrating the problem. Is the following explanation any better? If not I prepare an example. My EXE contains many VI's including VI_A and VI_B. These 2 VI's are called often by the external VI's. VI_A is also called by the EXE but VI_B is not. Both VI_A and VI_B are compiled into the EXE due to configuration of the build script. My external VI (VI_X) is written to call VI_A. When VI_X is dynamically called from the EXE it loads without issue. I modify VI_X to now call VI_B. Now when VI_X is called dynamically the EXE informs me that the VI is broken.

Hi Guys, I have a minor problem that I can work around, but I would like to better understand why the problems exists. To explain... I have an application that relys very heavily on external steps and drivers (by external I mean LV code external to the EXE). I also have some code inside the EXE that is actually not used by the EXE but is needed by the external VI's (lets call these VI's 'LibA'). I have modified the build script to ensure that LibA is included inside the EXE and I can see the EXE size increases after configuration and so I am sure this is correct. So the problem - if I try to dynamically launch an external VI that uses a VI from LibA, we get an error and the VI cannot be launched. Of course, if I call the VI's in LibA in the EXE (in a disabled case structure), then the external VI'S can also call VI's in LibA. I do this and it solves my problem. However, in this instance, if I have told the build script to include LibA, and I am sure LibA is compiled in the EXE, why can I not call the Vi's contained within? My best guess is that although the VI's are inside, until they are actually called, the EXE does not have an internal link to them. However, knowing that the EXE is compiled using the folder structure of the project, this is a little curious. Again not a major problem, I can work around it, I only would like to understand. LV2013! Gruß

I had a project where I wanted to distribute a second EXE for a small update function with my main application and I needed to be sure the second EXE was compatible with the first. I handled this by compiling the second EXE and then importing the EXE as binary text and storing in a string control. When I needed the external EXE to run, I wrote it our to disk and then called it. The second EXE was very small and not run so often and so this was an OK but maybe crazy solution. This works but is not without problems (i.e. if the second EXE needed to be updated, I had to resample the EXE and then recompile the first application). I don't really recommend this as a solution, it really depends what you are trying to do.

A small update to this. Our project contains 2000+ VI's. With trial and error I have tracked down that it is one specific VI that has been causing our delay in the project. The VI in question uses Hash functionality as shown here: http://lavag.org/index.php?app=core&module=attach&section=attach&attach_rel_module=post&attach_id=2583 Deleting this code from the VI fixes all problems in my project. I have passed this information to NI. Interestingly, commenting out the code is not enough, it really does have to be deleted.

Thanks for all your opinions guys. We have a project that began in LV2012 and is now under development in LV2013. We have the problems I orginally described (slow VI open and close, LV crashing). Given that your feedback is so positive, I have to wonder what is wrong in our case. I will create a new project file and see what effect this has. Of course a mass compile was done when we moved to LV2013. As a general rule we do not upgrade to the latest LV versions each time they are release. LV8.2.1 was used for several years and only last year did we switch to LV2011. With us developing a new project, we decided to develop with the latest LV version. Once the first EXE is released, the LV version will be fixed for several years (unless there is a good reason to upgrade).

Hi Guys, I am just wondering what the impression of developers is regarding the LabVIEW 2013 release? We have been developing a large application and have found it to be very unreliable and buggy. All of our developers have several crashes per week (sometimes per day). In addition, as the project has grown we have found that opening or closing a VI in our project results in a 1-2 second delay. Strangely though if we switch from project view to file view, the delay does not occur. I am in communication with NI regarding the delay, but a response of ""since this delay is not that long, I do not think there is something that can make the delay shorter" is very disappointing. Imagine working on your project and hitting this 1-2 second delay every time you open or close a VI. This delay also occurs if you add a project subVI to the VI under development. :-( OK, I am just interested if our perception of LV2013 matches that of others. Cheers

Sorry, an extra comment. I have just found the following paragraph.... "One parameter that you probably want to pass the clone is the new clone’s own VI reference — the one created using the Open VI Reference function. This is a very special reference, because (unlike an implicit VI Reference ) closing it will cause the clone to stop executing immediately — killing the VI dead in its tracks. Generally, you will want to pass this to the clone, so that the clone can be in charge of closing it, when it completes execution." Found here: http://thinkinging.com/2007/03/29/reentrant-vi-clone-name/ OK this is an old document and discusses LV8.2.1 mainly, but does anyone do this? Do you really pass a clone VI its own reference as a parameter and then set the VI to close its own reference?

Grrrrrrrrr - here we go again. So allowing LV to close the references means I no longer see the resetting VI message. I think this message was appearing when I was trying to close the reference to the test step. Mostly the references were being closed normally, but occasionally, it was not possible. However, now the application runs reliably, I don't see the resetting VI message, but when I try to close the application, it hangs. Preseumeably because LV also was unable to release the references to some steps and the application needs this memory released before closing.. So in short, I think I have masked the problem and not fixed it and actually I really need to find the underlying cause. Surely this is a LV issue and not my application since now, LV should be releasing all references. The steps have completed there actions as the sequence continues. Any ideas?

OK, to answer questions and give some more information. Once the resetting VI message appears, its game over. Do not pass Go, do not collect $200 and in this case, since production completely stops, go straight to jail (ok the job centre - but you get what I mean). The reason for managing the references ourselves was from some very early experiences with LV6.1 where it appeared that LV was not releasing references. This experience from many years ago has caused me to be a little cautious and really ensure references where being closed and memory was released. I am sure LV2011 is a phenomenal jump though with regard to how things like this are managed and this is just unnecessary paranoia. So as per my post, I modified the code so that LabVIEW now handles closing the step VI references itself. Hey presto, the resetting message has not been seen since. Previously the error occurred every 4-6 hours. Now after 30 hours, no problem. So I have a solution, but to be honest, I don't fully understand why the problem existed, but production runs reliably again. Thanks as ever to everyone for their comments and support. ;-)

Hi Guys, I apologise if this is repeated somewhere... I have an application that runs several external re-entrant test steps dynamically (external being - outside of the EXE). This is pretty typical I think. This worked very reliably with LV8.2.1 and there was never a problem. We have recently compiled with LV2011 and here is where the fun starts. During normal execution, we occasionally see a message 'Resetting VI: <step name>'. Debugging is very difficult. The message appears randomly. Occasionally once a week, occasionally once a month! After some reading I found many suggestions that this could be attributed to VI references not being closed. However, having checked the code repeatedly, I am confident that all references are being closed. Currently I launch the VI's with the 'Run VI' invoke node. Wait Until Done = False, Auto dispose ref= False. I am wondering whether the problem would be solved simply by allowing LV to manage reference disposal?? I doubt you can tell me the problem, but any ideas of what to look at would be welcomed. I have checked everything I can think of.

In other application I have a VI for initialising the Queue only (to ensure name and datatype) - this seems sensible. However, in this application there are many functional globals for sharing of data, and I think I just created this functional global for the queue without thinking so clearly (probably late one sunday evening with a bottle of Bud close by!!).

Hi Guys, Not a newby to LabVIEW. but this feels like a newby question!! I have a Functional Global VI with the following functions.... - Init - opens a queue reference and stores the reference in a shift register - Deinit - destroys the queue - GetQ - passes out the queue reference - Send - places data on the queue This was written in kind of auto-pilot. Just wanting to make sure all application VI's initialise the queue correctly with the same name and the same datatype. Everywhere I need to send data via the queue, I call this VI and attach the data to the input and the stored Q reference is used by everything. My question is, is this fundamentally wrong? Of course I understand that I can open new references to the same Q, send data and then close that reference instance. Are there any known advantages/disadvantages?

Hey Asbo, not this time. ;-) We have 16 - 20 PC'S of one specification and this crash does not occur. Thex have been working reliably for many months. We had 1 PC that started crashing. We uninstalled and then reinstalled LabVIEW but the crash still occurred. We then restaged the PC back to its 'as supplied' status and reinstalled LabVIEW. Again LabVIEW crashed. Finally we noticed the different mainboard number. So we took a couple of PC's from stock with this new mainboard and installed LabVIEW. The same trial was performed and LabVIEW crashed on them all. Take away the silver control and all work well.

I have no information that they have escalated the issue. In this case I assume nothing has been done. I will contact them and ask the question. I can live without the silver controls, but is this highlighting a bigger issue behind???? I have no idea. It is a valid statement that maybe this issue is with the industrial PC. I am in discussions with the PC manufacturer regarding this problem, however, this occurs only if a specific function in LabVIEW is used!! I am not sure how much luck I will have convincing them!

Thanks asbo. I should have perhaps mentioned these VI's are saved using LV2011SP1. I think our problem is hardware related and not linked to operating system. However, it is good to know the operating system is OK. We have essentially identical PC's running windows XP. The crash only occurs on PC's with the latest motherboard revision (although of course the bios could also have been updated).