John Lokanis

I currently use .NET calls to read and write data to an SQL server. This works well most of the time, with rare errors from .NET that canot be explained. What I am looking for, however, is a faster way to accomplish the same tasks. LabVIEW calls to .NET have a lot of overhead. And even employing all the tricks from Brian Tyler's old blog still don't fix all the speed issues. What I am looking for is a different transport to get the data between my LabVIEW app and the server. So, has anyone else used a MS or 3rd part DLL or other interface to connect and execute SQL calls to a SQL server database? Can I bypass .NET somehow and access a lower level set of functions that are faster? I know ADO can be used (via ActiveX) but is there any reason to think it would be faster? thanks for you thoughts and experience on this issue. -John

QUOTE (Jim Kring @ Nov 17 2008, 10:52 AM) I think your 'no race condition' code still has a race condition. What is there to prevent the semaphone from being destroyed before the lower path is executed? I think you need to wire the semaphore or the error out of the release call in the lower loop to the border of the sequence with the destroy in it to 'ensure' that the destroy cannot happen untill all code paths needing the semaphone are complete. Also, the use of sequence frames and semaphores could be eliminated by instead protecting the data in a single element queue instead. This is a cleaner way to solve the problem and better coding practice, but would not demonstrate the use of the semaphone.

QUOTE (Neville D @ Nov 7 2008, 09:15 AM) Nope. You need to explicitly set this in the build script. You can to this on a folder by folder basis or a VI by VI basis (you modify the VI Properties when building). Unfortunatly, you cnanot do this on the whole project at once. FWIW, changing this reduced my EXE from 3.8MB to 3.2MB but appears to have had no effect on speed. -John BTW: I forgot to mention that after I cache the VI in memory, the following opens use the VI name as a string when opening a referece, which should be faster. My concern is how LabVIEW handels the creation and cleanup of reentrant clones of the VI and it's sub-vis and how much overhead is incurred in this process.

QUOTE (MikaelH @ Nov 5 2008, 09:21 PM) I am using Preallocate for all reentrant VIs. I tried to use the shared clone feature but discovered a bug where the garbage collection routine seems to invalidate references in some clones still in use when other leave memory. This only happens for me when running in the RTE under 8.5 and when the VIs are called dynamically. I have reported this bug to NI but it is very hard to repro. I will modify the build script to set all VIs to no debugging and give that a try.

QUOTE (Aristos Queue @ Nov 6 2008, 12:33 PM) I will give that a try. Thanks for the idea.

QUOTE (jlokanis @ Oct 16 2008, 03:02 PM) Well, changing to the pre-allocate clone method does seem to have corrected the memory corruption issue. So, beware of shared clones! Especially if you are doing a lot of dynamic launching. Now, unfortunatly, I am dealing with a speed issue. Likely caused by all that allocation each time I create a new clone of a reentrant VI. I have posted a new thread of this topic so I will see if anyone has ideas on this one. thanks for all the comments and help on this bug. I will follow up with NI to see if they can repro this and fix it in LV8.7 or whatever the next version is... -John

I am looking for ideas or best practices for speeding up the launching of VIs in a test system. Currently this is how I do it: All my test VIs are reentrant. When a test is called, I first check to see if the VI is already in memory. If not, I pass the path to a DAEMON that opens and holds onto a reference to the VI so it stays in memory. I use option 8 and I do not run this reference. It is there just to cache the VI in RAM. Then, I open a reference (using option 8) to the VI to run the test. This creates another clone of the VI in memory and then runs the test. After the test is done, the results are returned and the VI stops. I then close the reference to this clone. I have many parallel loops calling these same VIs so there can be many clones of the same VI starting, running and exiting at the same time. What I am noticing is when I start to reach ~25 of these loops running, the app slows down considerably. I think this is because each clone needs to allocate memory to run and then free it when it stops and is released. Since each loop is calling the same set of VIs over and over, there is a lot of this going on. What I am looking for is ideas on how to run this more efficiently. One thought is to use VITs instead of templates and then reuse the spawned instances of the templates within each loop. The spawned VI would stay in memory and just be started and stopped as needed. This might reduce memory allocation. Another idea might be to still use reentrant VIs but keep hold of the reference to the clone within each loop and reuse it instead of freeing it and creating a new clone with each call in the loop. The key thing is each loop needs to own its own copy of each test VI so no loop can be blocked by another. Any ideas, no matter how crazy would be appreciated! thanks, -John

Does anyone know how to use the VI profiler to collect data on VIs that are dynamically called and are reentrant? When I run it now, the data for a given VI disappears/resets everytime it leaves memeory. I want to sum up all the calls to each instance of a VI and see where the slow code is. thanks, -John

QUOTE (Daklu @ Oct 28 2008, 11:31 AM) I use the OGB namespace feature to build .LLB files for sets of plug-in VIs. The LLB contains all the top level plug-ins and all of their sub vis, namespaced to the name of the LLB. This way, I can call plug-ins from more than one LLB at the same time, each with different revisions of a common sub-vi and be sure that the plugin loads with the version of the sub-vi it was tested and released with. I do not think you can do this with LVLIB files. I don't think this is what they were intended to do. A source file on disk cannot be a member of two different LVLIB files. In my case, i want to build my LLBs from the same set of source sub-vis but lock down the version I built with so I don't have conflicts when using multiple versions from my app. It does add an extra step to my build process (first need to build the LLBs with OGB and then build an installer for the LLBs with LV). Finally, I am not aware of a means to build an LLB from a set of files and remove the diagrams and typedefs within LV. Even if you could do this, they don't offer a way to namespace them like OGB does. Hope that helps explain the value of OGB to your coworkers. -John

QUOTE (pdc @ Oct 27 2008, 06:43 AM) Thanks for clearing that up!

I have come across a very strange thing. If my app is consuming ~100M of memory according to the task manager and then I minimise the window the memory consumption drops to ~5M. If I restore the window, the memory climbs to ~7M and then will creep back up as I continue to use the application. What is going on? Does LabVIEW wait to do a bunch of garbage collection until you minimise the window? The only controls are a list box and some buttons so it is not like I have a huge graphic or charts or anything on the front panel. :question: -John (note: LabVIEW built EXE running under 8.5 RTE)

QUOTE (Michael_Aivaliotis @ Oct 16 2008, 03:53 PM) Yes, that is a good point. I actually saw a big improvement when I moved to 8.5 from 8.2. The application seems to speed up dramatically on multi core machines. I also changed all the VIs to shared mode because it seemed to make more sense from a memory allocation perspective. I have converted the whole app back to preallocate and it does not seem to do any harm so far. I will need to run it through the test release process and deply it to production for a while before I know if the problem is gone. I just wish someone at NI could give me a 'warm fuzzy' about this by saying 'yes, there are some bugs in the garbage collection routines in the 8.5 RTE'. It would be even nicer if they also said this was fixed in 8.5.1 or 8.6. I have seen my share of LV bugs going back to version 3.1. Some critical and some just annoying. This one is the most bizzare, however because it is so hard to reproduce. I will post the results after a few days of testing... -JOhn

QUOTE (Michael_Aivaliotis @ Oct 15 2008, 10:26 PM) Thanks for the tip, but can you tell me why that is a red flag? Is there something about the shared clone vs. preallocated clone that is bad? I was under the impression that shared clones were good when you used a lot of reentrant VIs because they reduced the memory footprint. As long as you avoided FuncGlob types of VIs where previous states mattered, they should work the same, right? I will give this a try but I would like to know more about the difference so I can educate myself. thanks, -John

QUOTE (crelf @ Oct 15 2008, 05:51 PM) I am seeing this on multiple machines and we have taken the machines of line and run full memory diagnostics. I think the LV 8.5 RTE is just plain buggy. At this point, I have done everything I can in the code. I now need to take the leap and just upgrade to 8.6 and cross my fingers...

This just gets more interesting. I have now trapped another 'impossible' error. The reference to my top level VI became invalid inside a sub-vi. I cannot think of any way this could happen. I derive the reference in the top VI via the 'This VI' static reference node and then pass it to the sub-vi. The error I get (very rarely even though this sub-vi is called 1000's of times a day by this top level VI) is: Error 1055 occurred at Property Node in <this VI's Path> Possible reason(s): LabVIEW: Object reference is invalid. How is this even possible? The reference input to the sub-vi is a required input. And I have traced the code to ensure that it is not being closed somewhere else or passed through a non-iterating for loop. If the sub-vi is running, how could it's caller's ref go bad??? See the attached VI for an example of the code. Download File:post-2411-1224117137.vi -John

QUOTE (nighteagle @ Oct 15 2008, 04:52 AM) No, we do not use any timed loops. Only the standard producer-consumer while loop structures. We do a lot of dynamic launching of reentrant VIs, however. I really think this is a memory corruption issue. We see this happen sporatically and it is always a reference to a queue or notifier or user event reference that has gone bad. I am still on 8.5, not 8.5.1. I only see this in deployed apps running under the RTE. Our next plans are to upgrade to 8.6 and see if the problem goes away.

QUOTE (TobyD @ Oct 8 2008, 11:27 AM) Unfortunatly, [^0-9] does not account for the decimal point. Do you know if a regular expression can be written that says "not 0-9 AND not ." ?? I would prefer to use a regular expression if possible because that should be faster, but the native LV code above looks like it would work too. -John QUOTE (jlokanis @ Oct 8 2008, 01:58 PM) Unfortunatly, [^0-9] does not account for the decimal point. Do you know if a regular expression can be written that says "not 0-9 AND not ." ?? Ah, but [^0-9.] does work! WooHoo! I really need to get a good book on regular expression writting...

I am trying to create a function that will test a string to see if it contains non-numeric chars. So, I need to output a TRUE if the string only contains the characters 0 through 9 and . Whitespace should be ignored. 1.23 = TRUE 123-456 = FALSE 1.23A = FALSE A123 = FALSE 123 = TRUE etc... Is there an easy way to do this or do I need some complex code with loops and match extpression calls for each char in the string? thanks, -John

QUOTE (normandinf @ Oct 1 2008, 05:46 PM) Thanks! That did the trick! Maybe they will incorporate this into the next LV release as an ini setting. -John

Does anyone know if there is an ini setting somewhere that will allow me to change the recent file list in the getting started window? Under the 'Open' section, it lists recent projects and files. This list matches the file..recent projects/file menu. The problem is, it only lists the two most recent projects. Since the majority of my day-to-day work revolves around several projects, I would like to change this so it lists more projects and less files. Two is just not enough and I end up using the drop down menu instead most of the time. I know this is a minor inconvienence, but it just bugs me after awhile. There should be some why to change this... thanks for the help, -John

QUOTE (ned @ Sep 24 2008, 06:35 AM) That fixed it! I posted the update in the CRID. Updated! Search Text Control

QUOTE (jlokanis @ Sep 21 2008, 11:29 PM) 1. Speed fixed. Uses binary search. One caveat: it will only work with single font string controls. So, no mixing fonts or adding modifiers (bold, etc). If you can find a way around this, please let me know. 2. By setting it to float and always visable (do not hide when LV not active), I was able to make it be the top window when it is activated. 3. Still no improvment here. 4. Needed to set the button to both toggle and grab focus when <CR> pressed. This way, the data being entered into the combo box becomes 'active'. Thanks to everyone who helped improve this code. If you have any other ideas or suggestions, please post them and I will see if I can improve it more. -John http://lavag.org/old_files/post-2411-1222277716.zip'>Download File:post-2411-1222277716.zip

QUOTE (bazookazuz @ Sep 23 2008, 03:15 PM) Yes. Just modify the example, changing 'Private Bytes' to the proper counter name you want. Good luck finding it! Microsoft makes this so incredibly hard to understand and find in MSDN that you will want to scream :headbang: Try looking here for starters: http://technet.microsoft.com/en-us/library/cc780836.aspx -John Here is a VI that monitors all CPU usage. You might be able to modifiy this to give you the % of a specific process. -John Download File:post-2411-1222216009.vi

QUOTE (Aristos Queue @ Sep 23 2008, 03:06 PM) I think this is one area of LV where it fails the 'general purpose' language test badly. We really should have text display controls that allow rich text, html rendering and support cut and paste of data that contains multiple fonts. And don't get me started on the fact that the string control scroll bar does not respond to the mouse wheel! :headbang: As it currently stands, I can find no way to solve this issue. You simply cannot clone a string controls data EXACTLY to another string control. Oh well, it works well for my use case (single font with no special formatting). I guess that is the state of the art for now... On to the other issues: 1. Anyone know how to solve the highlighting issue? Can you have text highlighted in a stirng indicator when it is not in the frontmost VI? 2. How can I have the combo box 'see' the new entry when the user presses <CR> when it is bound to the find button? thanks, -John

QUOTE (PaulG. @ Sep 23 2008, 07:52 AM) All politics aside, you can't judge something you have never seen. Kinda like trying to ban a book you have never read. You certainly don't have to watch a movie or read a book if you don't want to, but you don't have any standing to make comments about the contents without seeing for yourself. Many people make the mistake of letting others tell them what to think. If you expose yourself to all point of view (both those you agree with and those you don't) then you will form a much better picture of the world around you. :thumbup: Sorry for the excessive smileys..