Jump to content

Cat

Members
  • Posts

    815
  • Joined

  • Last visited

  • Days Won

    15

Posts posted by Cat

  1. 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.

  2. 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.

  3. 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. :-)

    • Like 1
  4. 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.

     

     

  5. 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

    • Like 1
  6. 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.

  7. Are you sure these toolkits aren't just free, and support 2014 and 2015?  I downloaded them from these links and installed in 2015 and was never prompted about a trial, and ran examples in the sparse toolkit.  I didn't run any GPU ones because I was missing the CUDA DLLs.  The package that installs them also is used for LabVIEW 2014.

     

    http://sine.ni.com/nips/cds/view/p/lang/en/nid/210829

    http://sine.ni.com/nips/cds/view/p/lang/en/nid/210525

     

    I then installed the sparse toolkit in 2014 and it worked the same.

     

    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. :-)

  8. 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...

  9. 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

    • Like 2
  10. 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

  11. I realize that this thread is nearly two years old, but there is a new development about this.  This guy (GregPayne) recently took the above mentioned .Net library and from it created a limited functionality LabVIEW library that wraps the .net assemblies.

    <SSH with LabVIEW>

     

    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...

  12. What was CAR 313508 for anyway?

     

    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)

  13. [...] you simply have different expectations than what is the reality.

     

    This very succinctly sums up the reason for most of my problems in life.  :P

     

    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.

  14. Hi all,

     

    I have a strange little problem.  I have two computers talking to each other via TCP (thru a router).  Computer A sends out a short (1200-ish bytes) message via TCP Write.vi and Computer B responds with a different short message.  This happens every 10 seconds.

     

    Here's the strange part...  If I disconnect the network cable from Computer A during the 10 second wait, the TCP Write from Computer A still "completes" without an error even though there is no physical connection to the network when the function executes.  It's not until Computer A tries to read the response from Computer B (via TCP Read.vi) that it errors out (with error 66, which is another problem).

     

    This lead me to believe there was buffering going on with the write and it just didn't know there wasn't anything out there to talk to anymore.  So, I tried disabling the Nagle algorithm (both manually via the registry and then using TCP_NoDelay.vi) but this seemed to have no affect. 

     

    Any comments on what I'm seeing?  If this is buffering, is there any other way of forcing the TCP Write to actually write (and hopefully throw an error)?

     

    Cat

×
×
  • Create New...

Important Information

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