Leaderboard

As LabVIEW programmers we are all fairly used to find ways to get around limitations in the development environment and G as a language, however at times those limitations and bugs are just so fundamental that it gets depressing. The graph axis bug that was introduced in LabVIEW 2009 was one such case: if you wanted to use graphs and upgrade to LV2009 you had to rewrite all your code so the scale markers would show up correcly, or wait for months to get the first revised version of LabVIEW (because even fundamental errors like that are not patched instantly....). The good thing about that example though was the fact that you could actually make a fix yourself. Well, now I'm depressed again, and this time the problem is much worse. There are ways to come around this one too, but man - it should not be necessary. I'm a bit surprised it has not been commented before, because it is not really anything new - but once you run into its consequences it is extremely frustrating... The problem: The run method (and related methods like set control value e.g.) runs in the user interface thread - and that thread is blocked if e.g. the user opens a contextual menu somewhere in your application . The consequences: In short, LabVIEW is unable to reliably start an asynchronous background process on demand. - You can try to dynamically scale your software by instatiating a VI and run it with the run method (with Wait until done set to false), but if you need it to always happen within a reasonable time your application cannot have a user interface. It can not, because if it does then the run method might be stuck indefinetly if the user happens to e.g. open a contextual menu... So when does this actually become a problem? Well, in my case its most painful impact is that all client-server interfaces I have in my applications are unreliable because they, in order to allow an undefined number of simultaneous clients, create session handlers dynamically. A client might do a transaction that takes a lot of time, and with multiple simultaneous clients even quick transactions would add up so handling the client transactions in sequence is not possible. Hence the use of dynamically created parallell running session handlers. This works fine, but if the local user of the server should happen to open a contextual menu my server(s) effectively become unavailable to any new connections. One minute my servers are there...the next they are practically off-line to all new clients because the local user happened to open a menu...and if we're really unlucky he might leave the PC in that condition and never return! An unacceptable situation, plain and simple. So how do we get around this? Well, either we stop making software that both has to scale to outside requests, and have a user interface...or we predefine a maximum number of parallell processes and instatiate them in an idle condition at startup. Neither one of these make me proud or happy. PS. When I first noticed this I posted two ideas to the idea exchange (here and here). They do not have any illustrations that catch people's attention, and as it turns out neither of them are very precise, so perhaps a new one should be formulated and illustrated - but it's kind of depressing too that so few people realise their impact.

Hi Last November I took part in the UK NI Days as a guest presenter, to present alongside David Fuller of NI in a session about "What's New in LabVIEW 2010". I did a small section about why we were upgrading to LabVIEW 2010, basically about the Separation of Source and Compiled Code and covered a little bit about our Software peer review process. The presentation Video has now been put up on the Web, so I thought in the spirit of giving something back I would post the link up here in case anyone is interested. Whats' New In LabVIEW 2010 NI Days 2010 <table> <tr> <td style="vertical-align: top; width: 80px;"><img style="border-right: 3px solid #333;" alt="" src="http://scpro.streamu...images/0104.jpg" width="75"></td> <td style="vertical-align: top; padding-left: 10px; font-family: Arial,Helvetica,sans-serif; font-size: 11px; line-height: 1.6em;"> <p style="margin-top: 0px; margin-bottom: 0px; font-family: Arial,Helvetica,sans-serif; font-size: 11px; line-height: 1.6em; font-weight: bold; color: #333; width: 300px;">NIDays 2010: What's new in LabVIEW 2010</p> <p style="margin-top: 0px; margin-bottom: 0px; font-family: Arial,Helvetica,sans-serif; font-size: 11px; line-height: 1.6em;">David Fuller, Director, NI Danny Thomson, Motorola</p> <p style="margin-top: 0px; margin-bottom: 0px; font-family: Arial,Helvetica,sans-serif; font-size: 11px; line-height: 1.6em;"><p>From: NIDays, London, 9 November 2010. Software and Data Acquisition session. Learn how you can improve performance, and find out how solutions-based on NI products can save you time and money without sacrificing flexibility and longevity.<br /></p><br> <p style="margin-top: 0px; margin-bottom: 0px; font-family: Arial,Helvetica,sans-serif; font-size: 11px; line-height: 1.6em;">2010-11-09 00:00:00.0 National Instruments Channel</p> <p style="margin-top: 0px; margin-bottom: 4px; font-family: Arial,Helvetica,sans-serif; font-size: 10px; line-height: 1.6em; font-weight: normal;"><a href="http://tv.theiet.org/channels/ni/9985.cfm[url=http://tv.theiet.org/channels/ni/9985.cfm][/url]" style="padding-right: 1.5em; text-decoration: none; color: rgb(119, 125, 128);" target="_blank">>> go to webcast</a></p> </td> </tr> </table> Please excuse the odd tripping over my works, it is my first time presenting. I must say it was quite fun thought I did not think so at the time :-) cheers Dannyt

You should identify data stored in DLL with some kind of key or handle. Usually just data pointer casted to integer serves well for this purpose (but it may be also an index within some internal array, key-string within associative array or sth like this). So for example: when function in DLL is asked to store some data it allocates memory for it, put the data there and returns a pointer to that area (as an integer). Calling function must keep that pointer and refer to it each time it wants to do something with stored data. In more advanced case DLL stores a list of pointers it created to keep the track. It gives more control over stored data and helps in fighting with memory leaks.

I don't know how the JKI install works, but you are right. You only need to compile the hierarchy from the top level VI (which is what your VI tree is doing) rather than compile every VI.. I scan all VI's and see if they have any parents (lone VI's - these will be the top level VIs) then compile "Entire Hierarchy" only for those VIs and just save all the dependants. Opening a reference is quick, but compiling isn't. The advantage of this method is that you don't need a VI Tree VI (so it's more generic) and, for a couple of hundred VI's you only end up compiling a small subset and the compilation process is smart enough that shared VI's that are already compiled and/or saved are skipped (or so it seems) It's no really an issue in 2009 because it's all very quick. But 2010 is such a slug (installing SQLite API in 2009 takes about 20 seconds. In 2010 it's about 1 minute i.e 3x slower)

Jon's LVOOP Assistant renames Front Panel objects.

Because if we did not then surely nothing would happen? The two options you mention are nicely formulated. In the long run I hope NI will implement the first one, but the second one would be fine too. As part of the first option you mentioned a third one, that's my straw of hope here: Perhaps there is an option where another type of method is developed, one that would have limitations in other respects, but which would solve this particular problem preliminarily (until a more fundamental rewrite has become inevitable, one that also allows for an optimal solution to this issue).

I don't know the details of your application, but is it necessary to run all your code together in the same application? Sure it would be nice if LabVIEW were re-architected to make this all work, but it shouldn't be necessary. You can run a separate instance of LabVIEW (copy the EXE to LabVIEW2.exe) and run your servers there, or just build them into a separate application. In the real world, your client/server should running as a service. We use FireDaemon to accomplish this for our client/server system which can accept an unlimited number of connections. Services generally don't provide a user interface directly, so it's not unreasonable for NI not to have planned for this. You have a manager or client app which uses files or a database or TCP/IP on the localhost to pass events and data to the server. In general this should make your application more robust. Edit: OK, I just read your posts over on the dark side. You already know all the stuff I wrote, and AQ told you that this is not going to change anytime soon. Why are we having this discussion?

I wonder if this issue can be tracked back to the OS and virtual memory. From what I understand (other jump and fix my errors please) LV force a page fail on all of the code when it loads a VI to avoid pagefail waits while running. While the OS is handling the page faults and mapping virtual memory for the app, it is running in kernal mode (show kernal times in the task manager) to do the memory managemnt work. While in kernal none of the normal tasks are even concidered unti lthe memory mapping is correct and complete. Loading other code (i.e. opening Excel) while LV is running has always had this affect. SO that all makes senes to me. THe only hole I see for LV to escape thru is "in what thread do the menus run?" and there maybe some hook keeping menus in the UI thread. The above is a lot of speculating on my part. Take it with a grain of salt. Ben

Ok, I cleaned up the spam (should I call it spam? ...some content was very interesting... ) Anyways, I formally vote for OpenG as a sub-forum of LAVA. Respectfully, -JG

Thanks for bringing this to my attention! I played around a bit and generated a nutshell project in LV 2010 to demonstrate this problem. You can see cleary that the Run VI method does not start while any menu is open (this may be a context menu or a VI window's menu). The Get/Set Control Value methods are executed correctly even while a menu is open. I think if this is reported to NI, the first answer will be "Expected behaviour", which is of course correct. But it doesn't change the fact that this is a very bad trap to run into. It can really render a very powerful design pattern unusable. So, what can be done about this? I think there are two options how NI could improve this in future versions of LV: The Run VI method could be improved so that it may be executed even while the UI thread is busy (or there might be a new method to do this). The code that handles the menu could be improved so that it does not block the UI thread all the time (it's not doing much anyway, so why does it have to block this thread?). But even if we manage to convince NI of this, we will still have to wait a while unitl a LV version becomes available that fixes this. So let's think about what we can use as a workaround until then. My idea : Put the asynchronous VI together with it's startup code (especially the Run VI invoke node) into a DLL and call this DLL in your application. I haven't tested this yet, but I think this should work, because the DLL is running in another application instance. Test_UILock.zip

QUOTE(jared @ Jan 11 2008, 05:00 AM) Hi Jared, By Changing the Constant(0x07),. any Integer file can be accessed. But, before changing the constant, create that particular file in the PLC and configure it as integer. also configure the number of registers in that file as required. Accessing Bool File directly is a bit tough. Instaed of accessing a Bool File., You can keep some registers in the N7 and access it. In plc side, keep a logic to read from the integer file register and update the bool file. Use one of the these values for this field. Do not use any othervalues; doing so may result in unpredictable results. Admin Note: Content removed because it was messing up the RSS feed. Please don't use nonprintable characters in posts. Next time use an image of the content.