m3nth

I know this post is old and I don't have time to look at the other files posted. Just wanted to say though that I implemented the standard CRC32 routine in LabVIEW awhile ago, which is the one used in WinZIP type archivers (if you open up the CRC column for the files in the options menu). It is also used in tcp/ip networking I believe... it may be the CCITT flavor but I can't remember, just that it was THE CRC standard that everything used. I don't have the file available at the moment but wanted to post that if you'd like a copy of my code you can message me.

Thanks go out to... Big thanks to PJM labview for his utility to clean up all wires on the block diagram... I couldn't have made this utility without slight modifications to that code (mostly upgrading it to v7.1 which has a few minor differences with the MultiFrameStructure objects). I've left everything here unlocked for anyone else to look at and modify. Purpose of this utility... This utility is designed to be dropped into your LabVIEW 7.1\project directory. It will build a tree of all Express VI instances in memory and their owning VIs. Double clicking an item on the tree will highlight and select it just like the LabVIEW Find utility. Hopefully the next version of LabVIEW will incorporate finding Express VI instances but I needed this now. Actually I needed the ability to re-tag embedded Express VI Instances with a new configuration path, so that's an option too (use at your own risk!). Other comments on using it... - I had issues trying to back-convert to v7.0. It shouldn't be that difficult to do but I just don't have the time for it at the moment. I had problems with obtaining the instance VI's in memory, with the Events working right (possibly problems with LabVIEW in v7.0) and undoing the changes I made from PJM's code. Hopefully most of the people who got v7.0 however will have also gotten the upgrade. - When lots of VI's are in memory it can take awhile to load. I put status messages in to make it a little more bearable. - When you double-click the tree to find an Instance on your block diagram and the owning VI is large, it can be awhile before it finds all references to all subVI's for the entire owning VI. That's because of the recursive nature that is used to find diagrams (see PJM's code). - All in all, I had to bang this out quickly so it's not the nicest looking code I've ever made, but then again it's just a tool. I'm sure there are probably optimizations that can be made for it too. If you have questions on how it works or possible optimizations to make it faster let me know! Download File:post-360-1113414919.llb

I have a comment for this post even though it's a little old. I think when you upgrade the performance will drop because more stuff is included in the LabVIEW program as a whole. Like most major programs, they add more stuff that gets loaded into memory, but your computing power gets better with time, so that usually makes up for it. On the topic of express VI's however, they are perhaps a little bulkier, but their operation lends them to producing more streamlined code (if they're written well). The configuration part of the express VI is not included in a build of the application... it operates independently of the code that actually runs. That means it doesn't get loaded into memory unless you're developing your program. Using scripting in the configuration part of the express VI also means that actual source code can be added in or taken out depending on what options are selected. NI uses this in the NI-Scope express VI for example. Instead of having all code in the block diagram and selecting some of it to run and some of it not to run (using cases with boolean run=true/false selections), the code itself is removed. pretty spiffy. Well written express VI's should not only make it easier on the newbie, but also increase performance. Sometimes I don't think some of them have a chance if you're looking for a sleek, streamlined specific implementation, but my opinion is that overall they work pretty well.

Maybe this isn't related to scripting really--at the moment I don't have much time to care or to figure it out personally--but I didn't see any posts on here about it either which I thought was curious. Has anyone looked at this?

When searching for all instances of a VI and several hundred VI's loaded, a lot of them are lower-level password-protected functions. I obviously don't need to access or search through those, but I have to wait for an indefinite number of popups asking me for a password each time it runs into one that's locked. An option to Cancel ALL and be done with any VI's that are password-protected would be nice.

Actually I was referring to the PC hyperthreading--not LabVIEW--but looks like you got it working so great...

After getting what I needed working, I didn't look into the mystery of express VI's. After examining differently configured instances of NI-Scope Express, I realized that the express VI's that NI makes are probably heavily scripted and rely on VI's such as the one you discovered. I have no idea on it's functionality however--good luck.

Down with passwords. Thanks Jim.

I looked at doing this but goop library is passworded... my second option then has been to do the modifications to each class after I make it--is this what you're referring to? Or is there a way to make it actually generate the customized files you want in the first place?

I'm a little confused. After using GOOP, the data clusters that are generated are strictly typedefed, but can't be opened directly from the right click menu. I can use Advanced > Customize... as usual, but normally for my strict typedef controls, the Update from Typedef and Open Typedef options are enabled on the right click menu. What is the reason or idea behind these menu options being disabled and is there a way to enable them without interfering with the reason I'm guessing they are probably like that in the first place?

I'm setting out to make a stripped down version of the NI Scope Soft Front Panel (SFP) and to use these same core acquisition routines for acquiring high-speed digitized data and displaying to the user in other screens. Basically I want to make the acquisition run in the background and to modify it's behavior easily with a select number of functions. Right now a little test setup includes starting a re-entrant VI once in the background and having it update the FP waveform display via reference. I'm wondering if this is really the best way, seeing how re-entrant VI's are difficult to debug. I need a set of functions to work also, such as: Starting the background process Stopping the background process Stopping for a configuration change, performing that change, then re-starting Changing the reference of the FP waveform so a different graph is updated I would need the ability to do that without unloading it from memory of course. I'm looking for advice on the best way to have this kind of process, be able to debug it, and be able to communicate with it--any ideas?

I thought I tried this as one of several things and couldn't get it working, but it works now... thanks. I was also wondering if it might be helpful to have a list of directory functionality for LabVIEW in the FAQ (since I was looking for something of the sort and couldn't find it). Like put a VI here, it shows up on the Tools menu, put a VI here, it shows up on the FP palette, BD palette, etc.

Since I don't have a 'Projects' folder ('project' ?) and the 'Tools' menu is very unlike the VI palettes that can have icons added to them, what exactly is this in reference to?

First... I'll definitely check out SQL logging... SQL is good but I've not looked into what I need to use it with LabVIEW. Remote logging could be extremely helpful. Second... I haven't benchmarked file logging necessarily but every time I profile by the amount of time spent, Close File.vi (which is used in "Write Characters to File.vi"), always racks up the most time (or is high up on the list). I haven't looked at it recently... maybe I'll try and run some tests.

I am looking for suggestions on how to log status messages efficiently to disk without losing them and without having to open and close an entire log file to make sure it saves. Currently I have a subvi that prints the message both to a message window and also saves it to a file using the 'Write Characters to File.vi' with the "Append?" flag set True. This uses a lot of resources when closing the file once it gets big, because the file is opened and closed for each message. With lots of messages right in a row, this subvi gets banged quite a bit during program execution I was wondering if using a queue and an external logging loop would be helpful, so disk saving would not be a serial event in the chronological execution of the program, and also if that would be lossy if the program crashed--Which I think revolves around what type of loop you're using to write things to disk, and whether the file remains open. I am under the impression that if you don't close the file and you're writing to it, that it might be cached and then you would lose status messages that should have been saved to disk, if the machine were to go down. I think that my routines for logging messages work ok, but that they could also be made much more efficient. I'm just wondering if that efficiency would come at a cost to reliability, and if anyone else has had experience in this arena.

I use case-selectors with a strict-typed enum Mode control to leverage subVI functionality. For some VI's that get called a lot (such as an LV2 global), there may be many many instances of the VI. Currently, there are two ways to find a specific function call that uses the VI and a moding constant: Search for the VI, then look through every instance until you find the right one Search for the enum constant, then look through every instance until you find the right one Where this lacks heavily is finding a particular enumerated function--both methods above find all functions. For example say I have a VI with three modes: Load References Save Values Get Values If I want to find the one instance where I load the references, I may have to search through a dozen or so instances of "Save Values" or "Get Values" before finding the one enum constant designating a "Load References Call". And actually in my case, the statistics are worse than that as to how many I have to look through. The short of it: It would be nice to have a method to search not only for an instance of an enum constant, but for the instance of a particular value of an enum... like being able to select the object in the Find box and then also being able to get a dropdown list of values to select from (or an all encompassing "All Values", similiar to property nodes.)

Very cool! Thanks for the info. :thumbup:

I am developing a large scale application using a central event handler for UI events and calling other code via user events. This has worked fine so far until I ran into a problem documented here: See Sample VI at the End of This Post Basically in the event handler, the front panel is locked out on user and dynamic events. Unlike other static events (such as a boolean value change), there is not an option to keep the front panel from locking. Apparently there is no simple workaround for this without changing the structure of the program to not make a process call that needs FP input inside an event handler. (You could use a popup dialog box for input but in my case that's not desirable) In the post above, there is a link to another article written by one of our very own moderators--actually of interest is a specific section of that article dealing with a consumer/producer architecture: Archictecture Design Patterns--Producer Consumer with Event Structure and Queues After reading this, I now have a few questions based on the current design of my program, which is solely event/user-event driven and is not based on the consumer/producer model. This has worked great to date, except now the one instance where I want a process to run in a user event that cannot receive button clicks from front panel (such as the user wanting to cancel that process). The obvious Pros I see in switching to a consumer/producer would be: Fix for the above problem--Ability to process front panel activity inside a working process since it won't be called from the event structure Removal of the current user-event declarations, which are numerous in my case, cumbersome at best, and require the use of local variables. The Cons I can see would be: Reworking lots of events into the new architecture--but that might not be so hard since the old archictecture could remain functional and be phased out slowly NOT being able to lock the front panel on events called inside of the consumer de-queue loop, which is the default opposite that occurs inside an event loop (I'm just not sure how many problems this might or might not cause). I'm looking for input on suggestions--whether it would be a good idea to try and switch over and whether I'm missing any possible ramifications. Since a lot of the program is already designed, not thinking things through might have not-so-great consequences.

Interesting. As stated in the posts you linked to, the workaround is just to update that terminal last... Download File:post-360-1096313878.vi

I believe the question was in reference to running a compiled LabVIEW app, not LabVIEW itself. And if you have to start mapping drives to have more than one copy run that doesn't strike me as very 'clean'. Personally, I have run into this problem before, however in my situation I had to ensure that only one instance could open--hence no problems. I would be interested in knowing how to spawn multiple instances of the same app also.

Just thought I'd post this for general knowledge... I ran into it awhile ago and NI knows it exists. If: There's an ActiveX container on a tab control The tab with the ActiveX container is selected (ie, the ActiveX container is visible) The Tab control visibility is set from True to False ...then the ActiveX container will remain visible instead of disappearing with the tab control. If: The tab control visibility is then set from False back to True The user changes to a different tab (ie, the ActiveX container is not visible) The tab control visibility is set from True to False ...then the ActiveX container will remain not visible. Possible workarounds include: Programmatically changing the active tab to a different page than the one with the ActiveX container before setting the tab visibility to false Setting the ActiveX container visibility to True/False in conjunction with the Tab control visibility

This is correct. The program won't compile if there is an uncompileable subVI listed in the Disable structure. Since LabVIEW partially doesn't 'see' the subVI though, there are no errors in the error box that comes up when you try and run... just a blank box and a broken arrow until you remove the offending subVI or get it working so it can be compiled. Otherwise, you can place all the non-compileable code you want in a Disable structure and the program will run, just so long as it doesn't contain non-working subVI's.

Saved in LV7.0 format: Download File:post-360-1095974185.vi

I am wondering if this is a bug in the tab control and/or if there's a way to get it to work right that I don't know about. Download File:post-360-1095971018.vi

Out of curiousity, do you have hyper-threading, and if so, have you tried to disable it and see if you still get errors?