Jump to content

Bob Schor

Members
  • Content Count

    60
  • Joined

  • Last visited

Everything posted by Bob Schor

  1. SOLVED. After three months of silence, I followed up with phone calls and e-mails to JKI, and got a response. The suggestion was to download VIPM 14.2.1976 (which I had done), and install it with "Run as Administrator". On my Windows 10 (Enterprise) PC, I am in the Administrator Group (though I don't use the "defined Admin" account). I tried it both ways, after a fresh reboot. Installing without elevating my privilege gave the same Error Message. Installing with Run As Administrator did, in fact, work. Some Questions. Did JKI not know of this "requirement" with Windows 10? Had they not tested it? If they did know, why were there no "fixes" or "warnings" built into the latest Software? Why is there no information either here in the JKI Forums or on the JKI VIPM main pages? Why did it take >3 months and my "yelling" to get a response? Yes, now I do feel better. I still think that JKI are a great group of people, and will continue to support them and their products. And (best of all) I now have the Hidden Gems In VILib on my Windows 10 LabVIEW 2015 system! Bob Schor
  2. Well, it's a month later, and I'm still having problems with VIPM and Windows 10. I should mention that I am using VIPM 14.0.2, and a check says "Your software is up to date". I have several machines running Windows 7 (x64) and one running Windows 10 (x64). All my machines have LabVIEW 2014 (32-bit) and LabVIEW 2015 (32-bit). My VIPM problems are exclusively with the Windows 10 machine. I have managed to install the OpenG Toolkit and one or two other Toolkits (I think I have the Biomedical Toolkit under LabVIEW 2014). However, attempts to install the "Hidden Gems in VI.lib" on either LabVIEW 2014 or LabVIEW 2015 met with failures, and the following Error Message: Main Package Name: Hidden Gems in vi.lib v1.0.0.8 Package Name with Error: Hidden Gems in vi.lib v1.0.0.8 Error Message: VIPM could not install the package national_instruments_lib_hidden_gems_in_vi_lib-1.0.0.8 . Error Code: 8 Error Source: Open/Create/Replace File in 21C4387AAE161FADBB1B2CA3A9EA1E5B->32E4E917A65244952F75E76C7A772B37->9DD90B2ABCC05E64EEB423775FEE5AA4->0514BDAA838359D0AD33ACAFA20FBC99->F94B9712B58831359A5E0BC2B53B4AFD->OGPM Class.lvlib:AE5C17D32A658827574CE56AD11AA4E5->OGPM Class.lvlib:C43A876EE83195DB5AD53919EE545D96->04B61BB9511860B66C121A638B9449D9->VIPM Main Window.vi<APPEND> C:\ProgramData\JKI\VIPM\cache\national_instruments_lib_hidden_gems_in_vi_lib-1.0.0.8.spec =============== I would appreciate some clue as to how to proceed, as well as some understanding of the nature of the failure. Bob Schor
  3. Well, I don't get it. There's something funny in the Windows 10 "water" (I've been using it only 3 days, still learning its idiosynchrasies). So after seeing the (very) early returns from Iowa, I tried again with VIPM, LabVIEW 2014, both 2014 and 2015 ports set to 3363. And (as it has in the past 4-5 years for me), VIPM installed packages without a hitch! Not at all sure what the difference was a half hour ago (except I didn't know about the caucuses), but I'm going to leave Well Enough Alone. I've now got my most important packages installed on the two (so far) versions of LabVIEW on my new Windows 10 PC. Time to get some work done ... BS
  4. Sigh. When will I learn? VIPM/LabVIEW 2015 (the first I tested when I (re-)installed Build 1976) worked fine, loading several packages. However, a complete failure with LabVIEW 2014. Ever since I started using VIPM, I've had multiple LabVIEW versions (typically at least 4 versions), and all of them were configured identically, all using TCP/IP port 3363 (if VIPM set up up as different, I set them all back to the same port, depending on the previous observation that if I was on a VIPM 2015 page, it would (only) try to connect to 2015. Now, with VIPM 2014.0.2, build 1976, with Windows 10, LabVIEW 2014 (SP1), I've been able to install packages in 2015, but none yet in 2014. Will keep trying, but it's never been so difficult ... BS
  5. OK, problem solved! Downloaded 14.0.2 Build 1976. Two installs with LabVIEW 2015, Windows 10 were flawless, what I've come to expect. I guess when I installed the Latest OS, the Latest LabVIEW, I somehow got the "almost-latest" VIPM ... Bob Schor
  6. Followup on reboot -- same failure with LV 2015, NI GXML. So I tried OpenG Toolkit. Barely started when it stopped, red letters at the top of the Package Information page says "This package is not compatible with your operating system or any LabVIEW version installed on your computer. As I noted before, last week I successfully installed LabVIEW 2014 and 2015 on a Windows 7 (x64) PC (not new) and had no trouble loading packages with VIPM. Now I'm doing the same on a new PC built with Windows 10 (x64), same versions of LabVIEW (2014 and 2015), which seem to work fine. Is it really true that VIPM is not compatible with "my operating system", i.e. Windows 10? I find that hard to believe. After posting this note, I'll go to the Web, download it again (I probably installed from the LabVIEW disks -- the version, I think, is 14.0.1 Build 1967. Incidentally, when I clicked "submit" on the previous post, the "busy wheel" spun for perhaps 3 minutes or more ... Bob Schor (maybe it's the Iowa caucuses messing with the electrons running around inside my PC ...)
  7. Over the weekend, I installed Windows 10 (64-bit) on a new PC, and started installing software. Late yesterday, I installed LabVIEW 2014 and LabVIEW 2015, and to my surprise, did not have any installation problems (I did a similar install two weeks ago on a Windows 7 system with multiple "Service not running" bugs, since fixed). I just installed VIPM 14.0 and activated my Pro license. I successfully connected to both LabVIEW versions, downloaded packages, and then tried to install. I usually start with a single package, NI GXML, then do the OpenG Toolkit. I got bizarre errors when doing this. Nothing installed, on either 2014 or 2015. I'm going to try to paste the error message I got when trying to install GXML on LV 2015: [Oops -- can't figure out how to post a SnagIt snapshot, thought the Image menu button would work like the LabVIEW Forums and let me find the image on my disk, but it wants a URL ...] So here (I hope) is a Copy/Paste of the text ... Main Package Name: NI GXML v1.4.2.8 Package Name with Error: NI GXML v1.4.2.8 Error Message: VIPM could not install the package ni_lib_gxml-1.4.2.8 . Error Code: 8 Error Source: Open/Create/Replace File in 23163E1A41169BF347A8CCAAC0675BD9->737916C70F04A06F7315252588CFE2EA->EDC783C0EDD9EFF57211A26F185B4235->3CEEB42FDB9E41319885C763266FF802->C3E21B565FCD6F248FD8C7F70DCA4E74->OGPM Class.lvlib:F1B7AB8155DFB5A57C76E744EBF6D846->OGPM Class.lvlib:8DA808F6EDC3F497E0970966EA075B32->151384EDD6F89B08F780714EAD830768->VIPM Main Window.vi<APPEND> C:\ProgramData\JKI\VIPM\cache\ni_lib_gxml-1.4.2.8.spec =============== I'm going to try a few more times, with reboots in between. Never had VIPM flat out fail on me (I have had problems with I forgot to enable TCP/IP, but I haven't made that mistake in at least 5 years ...) Bob Schor
  8. I just tried the Read RSS Feed example for EasyXML 2.0, and failed the parse. I'm guessing that the rss cluster that "defines" the parse is very wrong. The feed is coming from http://forums.lavag.org/rss-8.html. The first few lines of the raw rss data are: <!DOCTYPE html> <html lang="en" xmlns:fb="http://www.facebook.com/2008/fbml"> <head> <meta charset="UTF-8" /> <title>LAVA</title> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <link rel="shortcut icon" href='https://lavag.org/favicon.ico'/> <link rel="image_src" href='https://lavag.org/public/style_images/master/meta_image.png'/> <script type='text/javascript'> //<![CDATA[ jsDebug = 0; /* Must come before JS includes */ DISABLE_AJAX = parseInt(0); /* Disables ajax requests where text is sent to the DB; helpful for charset issues */ inACP = false; var isRTL = false; var rtlIe = ''; var rtlFull = ''; //]]> </script> Please advise. Is there an alternate rss site that I might use to see this in action? Bob Schor
  9. OK, so a "simple install" (just click the downloaded installer) fails because "The product is already installed". Go to Control Panel, remove VIPM 2014, and try again. This time, it installs, and actually seems to run! Hooray. BS
  10. I've got a Windows 7 machine with LabVIEW 2012 and VIPM 2013 installed and running fine. I'm in the process of installing LabVIEW 2014 (from the PDS Disk Set). I installed LV2014, VIPM 2014, and a few toolkits. Everything looks OK. I also installed a few Urgent Updates suggested by NI Update. Several reboots. LabVIEW 2014 seems to be installed fine. When I click the VIPM icon, the Flash screen appears saying VIPM 2014 (Free Edition), lasts about a second, then vanishes, along with VIPM! I've just gone to the JKI Web Site and downloaded a copy of the VIPM 2014 installer. I'm going to try doing it "again", and see if it "takes" this time. I'll try to remember to report Success or Failure (well, if there's Failure, you can be pretty sure I'll report ...). Bob Schor
  11. I recently installed LabVIEW 2014 (32-bit) on a Windows 7 Pro (x64) machine that had VIPM 2014 already installed. I also have LabVIEW 2010 through 2013 installed on this same machine. I set up all of my LabVIEW versions with the same TCP/IP port, 3363, and "force" VIPM to accept this (so far, this has not been a problem). I just (for the first time) tried to install some packages (such as OpenG) on my 2014 system. To my surprise, on several installations, it would start, get about half-way done, then start the 2-minute Timer, apparently trying to connect to LabVIEW. When the timer expired, instead of an error message, I got a message "Successfully installed". And, indeed, if I stop LabVIEW and restart it, my packages show up in the palette. Why is VIPM "wasting my time" by making me wait two minutes per installation when the installation succeeds? Is this a Bug or a Feature? Bob Schor P.S. -- I'm running the Pro version of VIPM, if that makes a difference.
  12. I recently installed LabVIEW 2014 (32-bit) on a Windows 7 Pro (x64) machine that had VIPM 2014 already installed. I also have LabVIEW 2010 through 2013 installed on this same machine. I set up all of my LabVIEW versions with the same TCP/IP port, 3363, and "force" VIPM to accept this (so far, this has not been a problem). I just (for the first time) tried to install some packages (such as OpenG) on my 2014 system. To my surprise, on several installations, it would start, get about half-way done, then start the 2-minute Timer, apparently trying to connect to LabVIEW. When the timer expired, instead of an error message, I got a message "Successfully installed". And, indeed, if I stop LabVIEW and restart it, my packages show up in the palette. Why is VIPM "wasting my time" by making me wait two minutes per installation when the installation succeeds? Is this a Bug or a Feature? Bob Schor P.S. -- I'm running the Pro version of VIPM, if that makes a difference.
  13. Well, after several days of silence, I reopened my Surface and LabVIEW 2013 and "tweaked" various things that I didn't think mattered (like changing a firewall rule from "Auto" to "Allow", and enabling Scripting (which should not have mattered, I'd have thought). Maybe its the phase of the moon, but now it's installing.
  14. I'm having problems installing VIPM 13 on my Surface Pro (running Windows 8.1). This PC has LabVIEW 2012 and LabVIEW 2013 both installed. I had no trouble installing packages with LabVIEW 2012, but not with LabVIEW 2013. I have (successfully) used VIPM on multiple PCs (typically Windows 7) and multiple versions of LabVIEW (including, recently, a PC with LabVIEW 2010, 2011, 2012, and 2013). For all these machines (and the current Surface under discussion), all the versions of LabVIEW are set up identically -- TCP/IP enabled, Port 3363, all TCP options "on", localhost and 127.0.0.1 enabled, all VIs enabled. I've rebooted this PC, then opened VIPM and navigated to the "Version" option. I chose 2013, then had it "Verify". It successfully opened LabVIEW 2013, but about 2-3 seconds later, gave an error message that I'll look up right now ... Here's what happens -- I open VIPM. select 2013 under Options, right-click, and and choose "Launch LabVIEW 2013". No problems. I then open Options, choose Configure LabVIEW Versions (for LabVIEW 2013), and click Verify. LabVIEW 2013 opens, then I get the error message "VIPM could not connect to LabVIEW 2013. Please verify the VI Server ...". On this screen, LabVIEW 2013 shows the correct port (3363), and, curiously, shows a checkmark in the Verified column. However, as I just noted, I cannot Verify (with the Verify button) nor can I install any packages. While it will be a (minor) pain, I'm willing to uninstall VIPM, wipe out its folders, and start all over. However, I'll wait to see if you have any suggestions. I'll also "play around" a bit, and if I succeed, I'll post a follow-up. Bob Schor
  15. I've been using TortoiseSVN for several years to manage my LabVIEW projects. It has been working so flawlessly for so many years that I am uncertain if I did any "magic" when I first installed it (I think my original client preceded Version 1.6). I just built a new PC, and installed the latest TortoiseSVN client, Version 1.8.2. Our repositories are still running the 1.7 SVN Services. Tortoise notes that Version 1.8 represents a new format for the Working Copy that is not back-compatible with earlier WC -- as I'm the only user of my Working Copies, this didn't seem to be a serious problem for me, even if different machines I use have different versions of SVN, as I never try to merge the WCs. I just did my first Update, and saw, to my shock, that Subversion said it was merging some of my changed VIs into my Working Copy. I never saw attempts to merge in the earlier releases -- instead, I would simply get updates or, in rare cases, conflicts (if I'd forgotten to update before making my own changes). In my panic, I accidently deleted the message from Subversion saying which files were "merged", so now I'm unsure what to do. I'm hoping that someone at JKI, where you have a TortoiseSVN "tool", has looked at the 1.8 client and how it interacts with LabVIEW. Based on my so-far single experience, it appears that it might not be able to tell that LabVIEW files are binaries, hence is trying to treat them as text. It is also possible that the "merge" message is false. I'd greatly appreciate your (collective) expert opinion. I've also posted a note on the NI Discussion Forums, so if you have a Solution or Recommendation, you might consider also posting it there in response to my query. Thanks for listening. Bob Schor
  16. A "Feature" of Easy Write XML File is that it errors out if the file already exists (i.e. if you need to overwrite a file). I urge you to add an optional Operation input to allow such an Overwrite to take place. True, the user could add code to (1) test if the file exists, (2) delete it if true, and (3) then do the Easy Write, but why require additional code, particularly if "inside" the protected VI you are doing an ordinary LabVIEW Open/Create/Replace file, and only need to change the operation from "Create" (the default) to "Replace or Create" (or to "Replace or Create with Confirmation"). If you did incorporate this change, it would be perfectly legitimate to raise an error for some other Operation input, of course.
  17. Quick followup -- on logging in again (not a Reboot, merely a Log Out), I found that the files I tried to Remove from the VIPC were still there (not a total surprise, as things "got stuck" after I clicked "Remove"). Also, the problem I had with the Start Menu disappearing was my own fault -- I'd mistakenly unlocked the Task Bar, and it was hidden along the top edge (instead of the bottom edge) of my window.
  18. I just installed (part of) LabVIEW 2013, which comes with VIPM 2013, to which I applied my Pro activation (seemed to "take"). I'm working on some code (doing documentation, fixing "spelling errors") that is distributed as a VIPC, and which installs its examples and some needed "utility features" (classes for generic plugins and some X Controls used to manage menus) in the local VIPM library. I wanted to strip out just the Class utilities, as I have an up-to-date version of the actual code. I open VIPM, go to Window and "Show VIP Configuration Editor", then (in VIPC Editor) "Open an existing VIPC". When it opens, it shows me a dozen Yellow Cubes ("The entire package is stored inside the configuration file"), but I can't do anything with them. In particular, half of them are OpenG packages that are already in the VIPM window, a third are the older versions of the files I'm working with, and only 2 or three are the files I want to install in my Package Library (the list that VIPM shows me). [it's always good to write complete documentation in a Forum, especially if you "write while doing". I was just going to say that if I right-click an entry and choose "Remove", nothing happens, but this time, it popped up a dialog and said something like "There are these other dependent packages here -- do you want me to remove them too?" I said "Yes", and then the "rest of the problem" popped up -- keep reading ...]. What happened this time is that the file and its associated dependents disappeared from the VIPC Editor window. At the same time, the cursor turned into the "spinning circle" ("Wait") cursor, and the Install Package and Uninstall Package icons in the VIPM toolbar started flashing at about 2 Hz. Needless to say, I cannot now exit either VIPM or VIPC Editor, except by using Task Manager to close the programs. In particular, neither Close button (X in upper right hand corner) works. I'm running this on a Windows 7 (x64, fully upgraded and patched). This machine is fairly new (built within the past month), and has relatively little software on it. I have installed LabVIEW 2012 SP1 and LabVIEW 2013, both with LabVIEW RealTime and the Report Generator Toolkit. Just for fun, I decided to see what happens if I re-run VIPM. I can't -- when I tried to close it, it somehow made the Windows Taskbar (at the bottom, with the Start button) disappear, and double-clicking on the VIPM shortcut on the desktop does nothing. I guess it's back to Ctrl-Alt-Del and asking Task Manager to reboot me. But first I'll send this off ...
  19. Some things in LabVIEW, like file sizes, are "naturally" typed as I64 (or U64). I just tried to write out some data that contained an I64 variable using EasyXML, and got an error message to the effect that "Element named "Bytes" is a I64 data type, which is not supported by the EasyXML toolkit.". While I can understand not supporting some of the "complex" LabVIEW types, I was surprised to see that this "basic" type generated an error. I'm hoping it's "something I ate", i.e. I might have a bad or old copy of EasyXML (VIPM identifies it as 2.0-2), or am just doing something wrong. Is this, in fact, a "feature" that 64-bit integers aren't supported? Can this be included in an update or new release? Or can you suggest a work-around? Bob Schor
  20. I just noticed something that makes a startling difference, and points out my less-than-complete understanding of XML and of EasyXML. If you look at the example code I sent you that "proves" my point, you'll notice it is completely "wrong" -- I have the "Read XML" function inside the For loop, so I'm opening the file over and over again, and extracting a single element, instead of the entire array. [incidently, if I remove the For loop, read once, and pass as the Type an Array of Clusters, the read takes less time than the write!]. What led me astray is an earlier use I made of EasyXML, where I was using it to write out Header information for experiment files. What I wanted in the Header file was a complete description of the experiment, including the "global" parameters (such as the subject's name, birthday, settings of the instrument, date and time, tester's name, etc.), trial-by-trial parameters (Trial number, specifics of the stimulus, subject's response), and a summary (total number of trials, ending time, etc.). I decided to use XML for this purpose, as it was "human-readable" (hence easy to check during development), portable, "standard", and (thanks to EasyXML) fairly simple to take into and out of LabVIEW, implementing cluster and arrays nicely. Because the data were being generated throughout the experiment, I wanted to write the header "as I went". Not knowing enough about XML, the approach I adopted was to use your Flatten and Unflatten routines, and to write an ordinary text file. Although the resulting file was not, I now understand, a "legal" XML file (lacking the <?xml> tag, since I didn't "know any better", it was something that I could parse easily and "fool myself" that I had an XML file. So when, in a completely different context, I decided to write out an array of clusters (which actually represented the walking of a directory tree) so I could analyze the data later, I thought of XML, and just decided to try NI's representation. I simply grabbed "Write XML to Data" and "Read XML from Data", not realizing the subtle difference between what I was doing now and what I did previously. I now (better) realize that your code may be perfectly OK, and the problem is my lack of understanding about "How to" do XML. So now I want to ask "How to do it". Here's what I want to do: 1) Generate a legitimate XML file, but one that does not need to be written "all at once" (which, it seems to me, is not a "requirement" for XML). I think this would require, in addition to "Easy Write XML File", an "Easy Open XML File" plus an "Easy Close XML File". Once the Open is accomplished, the user could simply use Easy Generate XML for each piece of data to be written, and simply write it as though it were a text file. 2) Read back and parse the resulting (legal) XML file. I'll note that it was easy to parse my "faux" XML file that I wrote using EasyXML, since I wrote out each element to a text file, so to parse it, I simply read in a line, which had the XML Start Tag, treated it as a variable name (which it was), found the End Tag, then knowing (from the Start Tag) the name (and therefore the type) of the variable, I could pass it to Easy Parse XML to do the work for me. For this to work for a "real" XML file, I would similarly need an "Easy Open XML File" (which, I suppose, could simply open the file as a text file for reading, and skip over the initial XML header tags until getting to the LabVIEW data section). It might possibly be useful to have an "Extract Element from XML File" that duplicates what I'm currently doing, that is, read a line, see if it has a Start Tag, if so read more lines until getting the End Tag, and return the resulting array to the user, with a signal (boolean, possibly) if the </LVData> end-of-XML tag is encountered. I look forward to discussing this with you all at NI week. Bob Schor
  21. Absolutely! You are doing things completely differently than I. I'm attaching my reworking of your code that definitively demonstrates the quadratic nature of the XML reading routine, contrasting it with the linear nature of the writing routine. The issue is the number of XML "records" in the file, not how many times you write a new file! Consider a text file -- if I write a text file of a million characters, I'd expect it to take 1000 times longer than to write a file of 1000 characters. Similarly, if I read a file of a million characters, I expect it to take 1000 times as long as a file of 1000 characters -- I expect the time to be linearly proportional to the size of the file. In the case of writing XML records, this proportionality is followed. It took me 3.9 seconds to write an array of 1000 "records", and 39 seconds to do 10,000 (see attached). However, when I read these two files, the 1000-record file took 21 seconds, but the 10,000-record file took >2400 seconds, or more than 100 times longer for a ten-times-larger file. I know what's wrong, and also know "how to fix it". I'd be happy to "tweak" the Easy Read XML File, but you'll need to "unlock" it for me (I have a purchased license for it). Bob Schor P.S. -- while running the attached Test routine, I noticed a strange behavior. As you'll see, I'm using the same file name for all the files. However, when I call Easy Write XML File and the file is already present, I get a LabVIEW error. Shouldn't there be an "open" option to allow you to open a file as read/write? Does the user need to precede the call to Easy Write XML File with a VI of her own to make sure that the VI does not already exist, and to delete it if it does? What is your idea about how to handle the various possibilities when getting ready to write an XML file? Test EasyXML Write and Read.vi
  22. OK, here's the answer. I'd previously done these calculations, but hadn't included the Creation Time. I used as my "base dataset" my LabVIEW "programming" folder where most of my LabVIEW code resides. It has just under 5000 sub-folders, which will be traversed and indexed by my routine. I used three nested sub-sets of this folder -- one holding about half my code, a second (within this folder) holding my own "personal" projects, and a third holding just one of these projects. As the attached data and analysis shows, Creation and XML Write times (here I was using NI's XML routines, but JKI's EasyXML gives similar numbers) had log-log slopes near 1, meaning they were near linear in speed (note that the Write time had a slope less than one, meaning it got faster as the data set got bigger, "economies of scale"?) However, the XML Read time had a slope near 2, meaning it grew as the square of the problem size. Bob Schor XML Read vs Write Speeds.pdf
  23. What's that "smirk" doing in my post? Turns out I put "(", "b", ")" to start my second "list" element, and the Clever Forum Code made a Smiley out of it ... It didn't show in the Preview, either.
  24. I recently generated an array of data about a directory tree, and wanted to save it for later analysis. I decided to try XML because (a) it was "standard", ( had a LabVIEW (and JKI) implementation, and © potentially embedded the data description in the data, making for "portability". My data was an array of clusters. Two elements of the cluster were "string-like", a Path and a string, while the rest were numerics. I found that the time to write the data was linear with the size of the data (1000 records took 10 times longer to write than 100 records), but when the data were read (by NI's Read XML Data), the time went as the square of the size of the data (1000 records took 100 times longer to read than 100 records). I was already >5 minutes for 5000 records, and the "real project" I hoped to tackle had 100-fold more (incidently, the write time for 5000 records was < 3 seconds). Dismayed by this discovery, I repeated the test with EasyXML, and got basically the same results -- writing time grows linearly with the size of the array being written, while reading grows as the square of the array size. Why should this be? It (naively) seems to me that once you "know" that you are dealing with an array (even if it contains "variable-size" elements such as strings), you should be able to get near-linear results processing data to re-create the array. I haven't yet applied NI's "performance" metrics to my code to see "where the time goes". Another thing I'll try is to time how long it takes to produce the initial array of clusters (which I do from within a FOR loop, using the indexing output tunnel) -- if the problem involves having variable-length elements with the array (and, thus, potentially having to reshuffle and resize the array as elements are added, something that could potentially "square" the time), I should see this when creating the original array. Be back in a few minutes with the answer to this point ... Bob Schor
  25. Sorry, I tried to wait for JKI to respond, working remotely on my work PC using VPN, but something really slowed down the network so that key presses and mouse clicks were delayed a second or two. Out of frustration at not being able to "fix the one or two things wrong with my VI", I decided to go ahead and "force" VIPM to use Port 3363 when running LabVIEW 2011. It does seem to work ... There's still the question "Why, when I installed VIPM, did it pick the "wrong" port for LV2011?", as well as "What's up with the dialog box showing its underwear, I mean, HTML code?". BS
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.