Bob Schor

Thanks, Hooovahh. Didn't think about size. I also didn't say, but I'm running 32-bit LabVIEW 2012 on Windows 7 64-bit. I started tearing down the code that failed, got it down to two error clusters and the Fit VI function, still failed. So I went the other way, wired two error clusters to Fit VI and put a decoration on the FP, no error. Time to check panel sizes ... That was it! I never set this (don't know what my colleague was thinking), so didn't even bother to look here ... Bob (sadder but wiser) Schor

My colleagues and I use the Fit VI to Largest Decoration function in OpenG all the time, and it (usually) works like a charm. I've got a fairly small Project, a simple State Machine that takes readings from a Vernier SensorDAQ device and plots it on a graph. I'm using a Queued State Machine pattern, so I begin by creating the State Machine Queue and enqueuing the Initialize State. The first thing I do inside Initialize is Fit VI to Largest Decoration, and it throws Error 1, pointing to the final FP.PanelBounds Property node that it is setting to resize the Window. I also watched this function run with Highlight Execution turned on, and sure enough, the Error line was OK until it got to that final Write to the Property node. My initial suspicion was the SensorDAQ function, even though it hadn't been called. So I took it out, but the error persisted. I also tried making the Fit VI to Largest Decoration the first VI to be run -- same error. Ohh, an idea. The VI in question was written by a colleague, who is not big on LabVIEW style. This morning, I rewrote the entire program, keeping only the Front Panel which has, among other things, a Graph on it. This problem is so weird that it almost has to be something "unconventional" -- I'm going to leave this post here, in case anyone has other insights, but I'm then going to replace the Front Panel and will report back, especially if it fixes the problem. Bob Schor

Not only did I figure this out, but I am currently using it to reset the dates of 150,000 folders (I copied a backup of my Laptop from one Archive drive to another) -- it's not the fastest process (it does on the order of 50 folders/second), but it's "hands-off". As noted here and in the LabVIEW Discussion Forums, using the .NET calls in Windows 7 and attempting to do multiple files can lead to difficult-to-understand (and thus hard to program-around) errors. The technique that I used was to arrange things so that the only file I/O that was taking place was on the Target device whose Folders I was trying to modify. My routine requires two passes -- during the first pass, LabVIEW parses the Source Folder Tree and writes a text file containing the Folder Path and the Creation, Modification, and Accessed TimeStamps. The second pass reads (and closes!) this file, then applies all of the changes to the Target Folder Tree (assumed to mirror the Source Tree, which is the case as we used Windows to copy the Source Tree to the Target Tree).

I noted with great interest Phillip Brook's "Brown Invoke Node" to manipulate LabVIEW's .ini file. I've written some code to do this for me (I use it to clean up the "Getting Started With" list of Projects and VIs), but wouldn't mind learning how to do it this way. But I can't find the "brown node" -- any hints? Bob Schor Never mind, I figured it out, in private ... BS

I am trying to programmatically set the "Last Modified" date on a bunch of folders. I've seen three methods to do this: two use .NET calls to mscorlib.system.io.directory or .directoryinfo, and one uses the OpenG File Info function. None of these methods work for me (Windows 7 (x64) with LabVIEW 2012, 32-bit). The .NET routines generate Error 1172, "Error calling static method System.IO.Directory.SetLastAccessTime, (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. Inner Exception: System.IO.IOException: The process cannot access the file 'D:\BS\Documents\LabVIEW\Labs\B-Lab\Set Folder Dates\Test Folder' because it is being used by another process.) <append><b>System.IO.IOException</b> in Folder Write Time.vi" The OpenG File Info function doesn't give me an error, but neither do it modify the Modification Date (or the Creation Date) of a folder (though it works fine for files). Anyone have any idea what is going on, and/or how to fix this? I've attached the code I used to test this out. Bob Schor Test File Info.vi

I came here three years later following a post in the NI LabVIEW forums. I also had developed a set of ActiveX routines to "do things" in Excel, but found it tedious to get the documentation for the ActiveX functions, particularly with Windows 7 and LabVIEW 2012 (looks like Microsoft is moving away from ActiveX, anyway). I "bit the bullet" and tried using the newer LabVIEW Report Objects, and life got much easier. [Oops, can't figure out how to paste snippet in here, so I'll try to Attach my VI]. Hope this is helpful. BS EXCEL Delete WorkSheet.vi UTIL Ask Sheet Exists.vi

I'm working on a Real-Time project and wanted a way to programmatically update the Version Number in the Build Specs for both the Host and Remote targets. A Web search led me here for the solution. My code differs a little, as I'm doing this from within the Project -- in addition, the names of the Version Tags seem to have changed (in LabVIEW 2012). I tried to post snippets of my VIs here, but couldn't figure out how to do so! I'm using Chrome (if that matters). I'm guessing I should use the "Image" button, but don't know what to put in for URL (the PNG images are on my desktop machine). Bob Schor

I'm trying to view some forums and material posted here. Any time I do, I get a page that says Lavag.org Driver Error, suggests I "reload" (doesn't work) or Notify Administrator (this message). I've tried getting in using IE and Chrome, same errors. I'm kind of surprised I was able to Post a New Topic ...

Bon jour, François. I just downloaded UI Tools 1.3.059 from the LabVIEW Tools Network. The series of VIs that you have provided look really nice, and I can believe that they will solve many "annoying" problems I'm having with UIs (I've got one application, for example, where I need to create a TouchScreen interface using, at various times, round Boolean controls, square Boolean controls, etc., and need to both "right-size" them and place them "nicely" (like evenly spaced, at 1/3 in from the left and 1/3 in from the right for two buttons). Painful, messy code that mostly works (except when it doesn't, and then it's a nightmare to debug). So your routines sound like "just what the doctor ordered". What I could not find is clear documentation and a manual laying out the "how to use these VIs to solve your problems" steps to take. I did find the examples in the NI Example Finder after I installed the code, but they were a little terse. I'm pretty sure that I can follow (most of) what you've done, but this certainly isn't something I'd want to hand to one of my students, trying to build a more user-friendly application, and say "Here, these will help with your UI efforts" ... Is there more complete documentation and/or a manual or a "How To" paper on these VIs? If not, would you be willing to work with me to develop such things? Bob Schor University of Rochester Rochester, NY

Jon, Thanks for looking into the code. I've tried to duplicate the "bug" a few times, but it is in the nature of things that when you are looking for errors, they "run and hide". The best evidence, although indirect at best, that there's a real problem is that (a) I've done a few dozen installations of LabVIEW 7.0 on WinXP systems and have successfully built executables (meaning the missing Librarian file isn't "missing"), (b) since about a year ago I've done several more installs, all following the same pattern, and most (but not all!) of these are missing the Librarian file, and hence give me 1003 errors when I build an executable, and © one of my students did an independent install of LabVIEW 7.0, and while he has not (yet) tried to build an executable, I've looked and he is also missing the Librarian file. In addition, we all have been installing the OpenG packages the same way -- install/open VIPM, select all of the appropriate packages, and do an en masse install. On those systems that I've checked, the "missing file" or 1003 error is also associated with VIPM showing the two bug-fix patches are not installed, and there are some entries in the VIPM "error" Application folder. It seems very unlikely to me that this could be a "permissions" thing, as everything is being installed in the "correct" directories, and everything else works. I can well-believe that a "careful" installation of the OpenG packages can successfully install the Librarian patch, thereby allowing the user to build executables without encountering an obscure 1003 error. My point in posting this is that it is much easier to "install in a logical manner" and discover, maybe months later, that something went awry. I'm hoping that someone is able to deduce what went wrong, and post a better notification than my somewhat vague description of the symptom of what I think is a problem, but meanwhile, those LabVIEW 7.0 (and later? can't say) users who also use OpenG should check their systems (if you don't want to poke around inside vi.lib, try to build an executable out of anything, even a While Loop surrounding a Stop button -- if it works, you're OK). BS

I think there may be a bug in the OpenG utility "ogpatch_librarian_bugfix-1.0-1". I believe this is intended to rename the VI "Copy From Folder to Folder" in vi.lib\Utilities\libraryn.llb (by adding the suffix "__buggy") and replace it with a VI of the same name that corrects a race condition issue. I've got more than half-a-dozen Windows XP machines (some "real", some VMs running on Windows 7 PCs) that are running LabVIEW 7.0, and using VIPM 3.0 or VIPM 2010 to install the OpenG packages. In most cases, the installations are a year old (or older), and haven't been updated (i.e. no new packages have been added). In all but two cases, it appears that an error occurred during the package installation (and either not noticed or simply ignored, as VIPM didn't "complain loudly"), the net result being that Copy From Folder to Folder was simply deleted from libraryn.llb, and not replaced. In a number of cases, this "missing file" was not noticed, and the user was none-the-wiser. However, when I attempted to use the Application Builder to create an executable (from any code, even from a simple While Loop with a Stop button inside), I would get an Error 1003 with a message referring to a protected file in the App Builder. It turned out, however, that the real error was the missing Copy From Folder to Folder VI (another example of a misleading error message!). I've tried to duplicate this bug by taking an existing VM, cloning it, removing LabVIEW 7.0, VIPM, and OpenG, and then reinstalling them as I usually do. I was not able to reproduce the error -- the Librarian Bugfix Patch worked, replacing and renaming the VI in libraryn.llb. So I don't have a "smoking gun" proving that this patch is, itself, buggy, but the fact that most of the LabVIEW 7.0/OpenG installations I've examined have (a) a missing file in libraryn.llb, (b) an indication that VIPM has installed all the OpenG patches except the Librarian BugFix (and the Notifier BugFix -- hmm, maybe the problem is in the Notifier Bugfix ...), and © there is an Error log with cryptic messages saying that VIPM failed during an installation (though the message doesn't clearly identify what package was being installed). I have left extensive documentation of this issue on the JKI Support Site. I'm following up here in case other LabVIEW 7.0 users might have this "silent" problem. To see if you are affected, simply open the libraryn LLB and see if you have the file Copy From Folder to Folder. If you have 1 copy, then the OpenG patch was never applied. If you have two copies (one with the suffix __buggy), the patch was applied successfully. If you have no copies, the patch failed to install, and may have "clobbered" this VI. A fix is to replace the libraryn.llb file with a "good" copy. Bob Schor

I posted a variant of this bug a month ago (I found it in "Get Default Data from TD"). As has been noted above here, the underlying problem is that the OpenG "Get Header from TD" returns a Waveform Type for both Waveforms and TimeStamps. The OpenG Type Definition Enum doesn't seem to include TimeStamps (as LabVIEW now does), so the "patch" is to add code specificly for Waveforms, then test to see if the number of elements is 6, whence you treat it as a TimeStamp. It would be really nice to have these fixes added to the current OpenG Variant library, so they would be "automatically pushed" to those of us using OpenG. If the patch was to simply recognize the "special case" of a Waveform that really is a TimeStamp, then it shouldn't "break" existing code (since anyone who used it with a TimeStamp type would have already gotten an error, hence if you didn't have an error before, you shouldn't have one now). Alternatively, coming out with "Version 2" of these routines that use a Type Definition Enum that is consistent with the current LabVIEW enum (which has a separate entry for Waveform and TimeStamp), and making the OpenG code return the "correct" value, would also be a way to go, though this would potentially be a "bigger" change, and could potentially "break" existing code. Maybe rename the VIs and use slightly different icons? Bob Schor

<Admin>Post Merged into this Topic</Admin> I recently tried the OpenG routine "Get Default Data from TD", hoping to be able to parse a cluster all of whose elements were "simple types" (numerics, strings, paths, booleans, timestamps). I discovered that presenting a timestamp to this routine resulted in an error 1, with the message complaining about a "waveform type". I originally thought this was a "bug", but now realize that it is a "missing feature". I had considered a Timestamp as a simple type, not realizing that LabVIEW considered it as a sub-type of Waveform. While I didn't want to implement code to handle "real" Waveforms (which are definitely composite types), I decided to add an "exception" to properly handle Timestamps. The fix is simple -- add a "Timestamp" case, test the cluster element "# Elements" (which is really "Sub-Type") for 6 = Timestamp. If it is a Timestamp, handle it as with any of the other simple types. If not, generate an error message (I changed the message to refer to "Unsupported Waveform"). My code now works with this modified version of the OpenG routine. Bob Schor

I have found a "variant" of this bug myself, and was about to post it (I have not yet figured out a solution ...). I was using Get Array Element Default Data and passed in an array of clusters. If the cluster included a TimeStamp, the OpenG routine would fail (actually, the failure was in the sub-VI Get Default Data from TD), also indicating "(Unexpected Datatype <Waveform>) Get Default Data from TD_ogtk.vi:2 in Get Default Data from TD_ogtk:vi:1->Get Array Element Default Data_ogtk.vi->TEST OpenG Problem.vi" (the last was my test routine). If I eliminated the timestamp from the cluster, the error disappeared. I think this is a "bug", not a "feature" (or if it is a feature, it is certainly an un-documented one). The problem seems to be the TimeStamp not being handled/recognized by the OpenG routine. Bob Schor

I'm having the same symptom, but have some further clues on its origin. I've been developing a real-time data acquisition project using Project in LabVIEW 8.5. I'm still at an early stage of development, so my code is not yet "full-blown". My basic model uses state machines, both on the Host (PC) and on the Remote (PXI, eventually), with communication between them using Shared Variables. Because I'm trying to develop a "generic" code base that will be used for various lab projects, I have two Host VIs, a top-level VI that mainly handles the real-time communication with the Remote, and a called Host VI that contains the specific Host code for the particular experiment (i.e. it has a user-specified Front Panel, displays, etc.). Top-level Host calls "user-specific Host", which, in turn, starts the Remote VI. At the present time, all three VIs (and their dependencies) run on the PC -- I have not yet "dragged" the Remote folder to my RT Target (I'm simulating data acquisition for now, just trying to get the basic architecture worked out). When I run Host VI, it invokes "User-Host" VI, which starts "Remote VI", and everything works fine. Over the weekend, I upgraded all(!) of my three development PCs to LabVIEW 8.5.1. The LabVIEW code that I've been developing hasn't changed (I know, because it is under Source Control, and I've checked the revision level). The difference is that now I'm getting the error message described here! One scenario that provokes the message is the following: (1) Start LabVIEW 8.5.1 [i'm going to do this in parallel with writing this message, so bear with me ...]. (2) Open the Project, and load the Host VI. (3) Run the Host VI. What I notice is that I see it "deploying" its shared variables, but then I get a dialog box with the text Failed to auto-save "PROJECT S-Lab.lvproj" for recovery. On at least one machine (the present one) that I tried this, after clicking "OK", the code seemed to run all right. On a hunch, I tried disabling part of the code in my top-level Host VI, specifically the call to the "User-Host" VI that also calls the Remote VI. There was still code left that attempted to initialize the Shared Variables, and I again saw a dialog box that I think talked about Deploying, and I again got the "Failed to auto-save" message. So I'm going to guess that this particular "feature" (which, to re-emphasize, does NOT appear in LabVIEW 8.5, but DOES appear in LabVIEW 8.5.1) may have to do specifically with Shared Variables. Oops, might not be that simple! I just disabled more of my Top Level Host VI, including all of its calls to VIs using the Shared Variables. It now does almost nothing (and, specifically, I don't see dialog boxes talking about deploying things), but I now immediately get the Failed to auto-save message! Well, it's getting late, and I want to post this. However, I may try tomorrow to make a copy of this Project, throw out large sections of it, and see if I can't get down to a "simple" system that exhibits this particular flaw. If so, I'll post it (or pictures of it) and we can see if NI can figure this out. I suppose I could also try to "downgrade" one of my PCs back to LabVIEW 8.5 and see if the problem goes away ... Bob Schor