Cat

Yup, all my executables are in 8.x layout. I will admit the one time this has been an issue was when I used two hardware drivers that were in lvlibs, and they both had an "Init.vi". I just renamed the two vis and went on happily. I haven't seen a need to use lvlibs. I am currently on a team of one, and I only distribute exes, not source code, so the public/private aspect of lvlibs hasn't been necessary. I organize via directories. I guess I gave up on LabVIEW libraries back when one of my llbs went over 1.44MB and I couldn't fit it on one floppy anymore. :-)

Here's one most of you probably haven't thought about for a few years. I built an application for someone else, and when the exe was run on their computer, it started complaining about missing vis. I realized this probably meant the "Use LabVIEW 8.x file layout" button got unchecked somehow, so I fixed that and all was fine. Which started me thinking... Other than the issue LV 8.x and earlier builds have with vis with the same name, is there any technical reason to NOT use the LabVIEW 8.x file layout when making an executable? I don't use LVOOP, and think it's Bad Programming to have two vis with the same name in the same build (either they have slightly different functions, and therefore have different names, or it's the same vi living in my code reuse tree, or maybe it should be a polymorphic vi, etc). I'm going thru a big code cleanup push and am wondering if this is something worth the effort of "fixing" in my 2500+ vi and 25+ exe library.

Hooovahh wins! I was able to download the latest and greatest OpenG libraries to my home computer and copy them to my off-line work computer. However, it was a needlessly convoluted process. I gotta think someone out there could host these libraries somewhere that would allow a manual download that doesn't require installation of other software.

I've had this off-internet issue for ever, and have just been copying the _OpenG.lib directory from computer to computer. After several years I figured it was about time for an update... My C:\ProgramData\JKI\VIPM\cache folder doesn't have OpenG files in it (other than the top-level library I got from the NI site). I'll try installing it on my home computer and see how far I get.

And here I thought I was just imagining that long-time posters were disappearing... Personally, I have been posting less for a variety of reasons, some of which have been mentioned already. 1) As I get more gray-haired, I am being moved (pushed?) up the management chain to the point where I am doing less and less "real" work, AKA programming, and more paper-pushing. 2) There have been fewer and fewer new features in LV for me to struggle with and commiserate with you all over. 3) Also part of getting older -- I'm looking at the light at the end of the tunnel with respect to retirement and am therefore locking down much of my code set. My focus is shifting to cleaning up and documenting the code I will be leaving behind. Which will probably just be rewritten by my successor with whatever iteration of C# .NET happens to be most popular at the time... All of that being said, first info-LabVIEW and then LAVA have been an integral part of my development as a programmer. The vast majority of my time as a LabVIEW programmer has been spent working independently, and even when I was on a team, I was always the most experienced person. Having this resource of peers and much-better-than-peers has been invaluable. I certainly wouldn't want it to go away. We have a newly formed LUG here where I work. I will definitely talk LAVA up at the next meeting. Maybe a couple folks will join and put a little blip in that stats chart. :-)

I need to get the full OpenG Toolkit to a computer without internet access. The link to the NI FTP site only has the top level library and none of the dependencies. There is something called oglib_array-4.1.1.14.vip on SourceForge, which, as the name implies, seems to only be the array library. Help? Cat

I am currently running two separate applications on the same computer that are using TCP loopback to send an aggregate 132MB/sec between them. So it's definitely finally working in LV15. However, I looked thru the LV bug fix lists and couldn't find the CAR anywhere. As for other options, back when I originally had this problem, I eventually settled on writing files to a RAM disk as the communications path. It wasn't fancy, but it worked out well.

Regarding your original problem with TCP loopback, take a look at: https://lavag.org/topic/14609-issues-tcp-ing-with-a-c-program-on-the-same-computer/ I was having what sounds like a very similar problem to yours. Bottom line from NI was that there was some issue with the TCP stack in LabVIEW when running on Windows 7 and doing TCP loopback. That was in LV11. By LV13 it still wasn't fixed. It does seem to be working in LV15, however. Cat

Thanks for the info and the links. I ran into an oddball situation on one of my computers that has 5 NICs. I wasn't using the "usual" NIC to talk to a bunch of other computers, in fact the NIC I was using was the only one connected to anything, and it was taking forevvvvverrr to make connections. I found two solutions, 1) attach "usual" NIC to another network, and 2) disable "usual" NIC. But it sounds like I may have just gotten lucky with that last one. This isn't a standard way I run my systems, but it made me wonder why there's not a client side "net address" in LabVIEW.

Is there some way to tell LabVIEW to open a TCP connection from a specific IP address (or NIC) on the client computer -- something like the "net address" field in "TCP Create Listener" on the server side? Cat

They may very well be free with 2014, I can't tell from the download pages. Thanks for checking them out in that version. However, I *have* downloaded the 2013 versions of both and they require activation. So, the local Navy AE is getting me serial#s/activation codes for both of them on 2013 for a 1-yr "evaluation period". But if it works with 2014, then that means I could install LV2014 SP1... But now that I've almost gotten myself convinced to go for 2015, that seems like the coward's way out. :-)

Thanks, hooovahh. The toolkits I need are the LabVIEW GPU Analysis Toolkit and LabVIEW Multicore Analysis and Sparse Matrix Toolkit. I don't think they've been added to LV as much as the download for the real 2015 version is now free. Of course, they could be on the shrink-wrapped set of NI Developer Suite 2015 DVDs currently sitting on my desk, and I wouldn't even know...

NI, in it's generosity, has made two toolkits I suddenly have a need for -- free. Unfortunately, they are only free in the 2015 version of LabVIEW. You still have to pay for the old versions (I'm using LV2013). As a result of this, I'm pondering actually... it's hard to even type it... upgrade to the actual current version. This flies in the face of many years of (sometimes justified) paranoia regarding not at least waiting for the SP1 version of a new release of LV. However, if I wait until February (historical SP release time), that puts me smack dab in the middle of a bunch of Big Tests, whereas if I do it now, I actually have a couple months of relative peace and quiet to make sure my 3500+ vis are all still working correctly. So, those of you who have already upgraded to LV2015, how's it going? Any problems/issues/etc.? Cat

Thanks for the response, Rolf. About the time I was directing questions like that towards the project manager, he sent me an email telling me the project had lost all its funding. Looks like I dodged that bullet.

I've been asked to write a data simulator where in essence all I have to do is create a bunch of simple waveforms and output them. The problem is that the communications to the receiving computer is via ATM. That's Asynchronous Transfer Mode, not the cash machine. 　 There's a dearth of information about LabVIEW&ATM (other than posts about LV certification exams). Anything on topic is over a decade old with titles like, "Keeping up with the Latest in Windows NT". So, anyone out there have any experience with this? Or has anyone who did ATM long since retired? Cat

Hopefully you've found an answer by now, but if not, contact their tech support (support@labwerx.net). They have been fairly responsive to me in the past.

Thanks to ShaunR and a lot of RTFM-ing, I pretty much ended up with something that looks like the first example in the article. Not ideal for my purpose, but better than nothing. I'll take a look at the LV wrapper. Thanks for posting about it. Considering I'm still oop-allergic, I'll check this out. Thanks, Phillip! TimVargo's post reminded me I needed to send out my yearly query to Labwerx regarding the timeframe (if ever) of a 64-bit version of their LabSSH software. Here was the reply: "I really want to get it done by the end of the year, as that's the only thing we really get requests for from our customers." So there's hope...

Thanks. I've cross-posted.

CAR 313508 I was attempting to do something similar last week, didn't work, couldn't figure out why, was going to post here, and then realized I was probably running into the same problem I had 4 years ago. Which I had completely forgotten about. It's hell getting old. :-) (cross-posted to NI)

Does anyone know how to find out the status of an orphan CAR? I have one from a few years ago (313508) and the same issue is biting me in the backside, again. So it looks like it wasn't fixed. Cat

Oh goodness, no need to feel like an idiot. You're not the first long time user to ask a question like that, and won't be the last. You could have just replied that you were actually testing to see if any of us (here in the States) were awake yet this morning.

If Enable Cell led is an indicator, it can not be set manually while in run mode.

Gak! You're making me read C. I hate it when you do that! Very funny joke, BTW. I certainly haven't bothered to ask the Linux guys (Computer B) what's happening on their side during all of this.

This very succinctly sums up the reason for most of my problems in life. Thanks for the link, it was very interesting. So it sounds like even tho I'm setting TCP_NODELAY, and (assuming it's working) the message is being sent out immediately, thanks to the TCP protocol, it's still getting stuck in the system regardless of whether or not there's a physical connection anymore. What if I sent the message via UDP -- would it error out faster? Not that that's really an option with the current system, but I'm just curious.

You are correct -- after Computer A is disconnected, and the TCP Write executes with no error, if I plug the network cable back in again within a few seconds, Computer B sends the response and Computer A receives it correctly. I tried the 0 byte TCP Read after the write, but it did not throw an error. Thanks for the suggestion, though. Cat