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).

Ah - and now the attachment!! crashtest.zip

Guys, I would like to ask for a favour from other engineers. We have a problem that is causing LabVIEW to crash. After a lot of effort, we found the exact functions causing the crash and have prepared some simple test VI's (attached). I would like to ask other LabVIEW developers to test these VI's according to the procedure below. 1. Close LabVIEW – this is important!! 2. Open LabVIEW and open ‘test_8.2.1.vi’. You do not need to run it – opening it is enough. 3. Open and Run ‘test_2011.vi’. 4. Click the silver button (called ‘Boolean’). 5. On our newest industrial PC's, this crashes immediately. On older models there is no problem. The crash only occurs with the silver button. Interestingly, if you open and run test_2011.vi first and click the button. you can then load the other VI and start and stop the VI's in any order and the crash does not occur. That is until you stop LabVIEW and start the process above again. The response from NI is that the problem must be with our industrial PC's and "Don't use the Silver Controls". Not using the silver controls is no problem of course, but I am interested how common this problem is.

Further on this topic. I have spoken with NI and they are escalating this to their R&D in the States. Hopefully I will have an explanation soon. The suspicion from NI in the UK is that there was a conscious decision to change the support of this functionality in a compiled EXE with later LabVIEW versions. Not nice!

Where to insert the debugging code? I have checked all path issues with regard to my external VI and this is correct. If I replace this external VI with a simple VI that provides a 'Hello' pop-up, this works perfectly. If I replace this with a version of the file that calls a VI from inside the EXE (but not called by an EXE VI), the external VI can not launch. It should. Aristos Queue, all paths that I have control of are correct using the standard functions!! The problem is that the EXE does not know the path to a VI within itself. The external dynamic VI's are working and being called from the correct location. The internal files are not being called dynamically but directly.

Hi, Thanks for your response and you are correct. Clicking the '8.x' format check box allows everything to work again. So the problem is related to path. It has nothing to do with the 'File Config' function, the problem is only that the path to the VI appears wrong if the main VI (or other internal VI) does not call this included function. The easy fix is to click this box and everything works for now. However, if I then start to use classes in this application and use dynamic despatching, I will have VI's with identical names and the compiled code becomes horrible with additional folders being created for files with duplicated names. This is not really the solution I would like to use. But at least we know a little more now.

Hi Guys, I have an EXE that was working well when compiled with LV8.2.1. I have now upgraded to LV2011SP1 and compiled a new EXE. The code is mostly unchanged with only some small modifications to correct dynamic paths. Generally this works well with one exception. My application calls an external dynamic VI that in turn calls functions located inside and outside of the EXE. My build script is configured to 'Always Include' all VI's in a specific directory (my library). This works well with all functions I have tested except one. I have an internal VI called 'find_file.vi'. This VI calls the 'File Dialog' function in the 'Advanced File Functions' pallette. If my external VI calls this function, then launching of the external VI fails. The 'find_file.vi' is only used by external functions, however, it is located in my 'Always Include' directory. If I call the 'find_file.vi' from my main.vi (in a case structure) and recompile the EXE, my external VI works well. So, I have a work around solution but I hate 'work-arounds'!! Any idea why in LV8.2.1 the file was correctly included in the EXE, but in the LV2011 build it appears to be excluded (or there is a path problem or...)? I hope the above makes sense. Any help would be appreciated. Regards

Hi Guys, I have a problem with a Labview application. Maybe you guys will have some ideas. OK, so I have a single LabView application that launches 1 or more dynamic VI's to control production processes. In some cases 30 processes are managed independently. As each process runs, it collects result data. Once the process is finished, this data is written to a mysql database. Each of the 30 processes can connect, write and disconnect from the database indpendently at any time. It is possible therefore that we multiple database connections from this application. The problem, whilst this runs reliably 90% of the time, occasionally we have an error in that a process can not connect to the database. The database is MySQL and we are using the NI Database Toolkit. The database is installed on the same PC as the application. MySQL has been set to support a high number of connections, much more than needed. I logged data from mySQL and this does not show an error when LabView reports that a connection attempt failed. So I am wondering if this is due to a limitation of LabVIEW or of windows. I have read that there is a limit to the number of tcpip connections that can be opened in 1 second in Windows. BUT, do connections to a local database via odbc still require a tcpip port? And would this fail the connection, or just delay it? I have started modifying the software to allow a single connection to be opened and this then shared between the various processes to see if this helps. But, even if this solves the problem, I would prefer to understand the problem. Any thoughts guys would be of interest.