Jump to content

Cat

Members
  • Content Count

    805
  • Joined

  • Last visited

  • Days Won

    15

Cat last won the day on May 12 2017

Cat had the most liked content!

Community Reputation

67

About Cat

  • Rank
    The 500 club
  • Birthday October 28

Profile Information

  • Gender
    Female
  • Location
    Maryland, USA

LabVIEW Information

  • Version
    LabVIEW 2015
  • Since
    1994

Recent Profile Visitors

5,143 profile views
  1. I use ini files. If I have complex data types, or large amounts of data required, the ini points to files where that data is stored. Also, LabVIEW annoyingly creates an ini file for every executable, so I figure I might as well use it. Cat
  2. Crud. I replied to this, but it never showed up in the feed. Huh. Anyway, yes, I'm turning this over to one of our C folks to deal with. I'm not sure if I can get the .NET version past our Information Assurance zealots, but a regular old dll I can call with a CIN will be fine.
  3. I just discovered that my latest needs-to-be-done-yesterday project requires communications via an Apache Qpid broker (v0.4 and AMQP 0-10). Since I didn't even know what AMQP was before yesterday, I'm a bit behind the curve on this. I have downloaded LabbitMQ, but I'm assuming that won't work with Apache Qpid? I was hoping that the whole open standard thing meant that different implementations of AMQP should be able to talk with each other, but the following link regarding interoperability between the two seems to say that this often isn't the case. There is a Native AMQP client for LabVIEW on GitHub, but it is missing all the vis (at least from what I can tell), so isn't much help. I posted an "Issue" to the Repository, but don't know when/if I'll ever get a response. Any thoughts/comments/suggestions? Cat
  4. Thanks for the process walk-thru. Unfortunately when I first read it I didn't know enough for it to help. Now it make perfect sense!
  5. Grrr. Yeah, the schedule change messed up my plans there. Hopefully next year I'll be there and can buy you a belated round.
  6. Wow. So after a day or so of flailing around I finally got this working. I think I only ended up making 2 changes to the Example.vi, the rest of the time I was trying to figure out all the networking stuff to make it actually work. Some of that time was spent combing thu this link for little hints. Some was spent figuring out what firewall setting I needed to turn off. Along the way I learned about symbolic links and how to configure an Apache web server. It was fun! Thanks hooovahh! And thanks to everyone else who contributed to this code.
  7. Maybe it's because it's Monday and I haven't recovered from either Cinco de Mayo (tequila) or the Kentucky Derby (bourbon) yet, but this one is twisting my little brain. After years of managing to avoid LabView and the Interwebs, somebody got the great idea of running some of my code via a web browser. Sure! I say, LabVIEW's got stuff to do that! Three hours later and it just ain't working right. I've read all sorts of things like: http://zone.ni.com/reference/en-XX/help/371361M-01/lvconcepts/ws_distributing/ http://zone.ni.com/reference/en-XX/help/371361L-01/lvhowto/enabling_the_web_server_in/ http://zone.ni.com/reference/en-XX/help/371361M-01/lvconcepts/ws_web_server/ http://zone.ni.com/reference/en-XX/help/371361M-01/lvhowto/build_web_service/ etc., etc. They just don't seem to be fully addressing my situation. Unfortunately there doesn't seem to be document that goes thru it all from start to finish. Here's my setup: Computer A: Running a LabVIEW application -- call it TestWeb.exe Computer B: Running Explorer/Chrome/Firefox. No software can be loaded or installed on this computer, including any NI software. Is there something I can do to be able to view/control TestWeb.exe, via a web browser, from Computer B? I've gotten it to work wonderfully -- using source code, but even tho I think I'm doing what the various docs say, it isn't working with an executable. Are there more complete directions somewhere someone can point me to? Cat
  8. I used to do Approach 2, then a user moved an exe to a different computer -- that of course didn't have the dependencies installed for that exe. Now I do Approach 1 which works best if you don't always jump on every LV yearly upgrade and SP. I tend to upgrade every other year, so can go for a long time without needing the "Full" installer. Approach 3 is fine -- unless of course you aren't tied to a network, or don't have the concept of a "server" in your network...
  9. Cat

    Wait. What?

    Well crud. I was actually starting to schedule some stuff around NIWeek -- in August. I've been telling the Big Boss if they send me, I might consider not retiring next year. But May would be hard to work in. I have to agree about the heat, tho. Austin in August is, umm, toasty.
  10. Cat

    Wait. What?

    Am I the last person on Earth to realize that NIWeek is moving to May in 2017?!? Clueless Cat
  11. A tangential issue when using Ethernet conversion dongles... We use the USB to Ethernet variety. A problem I ran into recently was when we had to communicate with other NICs that used jumbo frames, and the dongles we had didn't support that. Just something to keep in mind. (I found a USB to Ethernet dongle from Anker that does jumbo frames) Cat
  12. According to the calendar, I'm eligible to retire in 1 year, 1 month, and 1 day. I'm doing the code cleanup for my (so far hypothetical) replacement. Or I just retire, and come back the next day as a contractor for twice what I'm making now. :-)
  13. Ah, the good ole days... I only use the S&V toolkit, which I purchased long before OOP was a gleam in NI's eye, and never had a need to upgrade. Other than that, I use very little code that I didn't write (instrument drivers and OpenG being the major exceptions). This means, of course, that a lot easier ways to do things have probably been developed over the years, and I'm just too unaware/lazy/stubborn to switch over. hooovahh, I think you've convinced me to at least build a few of my exe's with that 8.x box unchecked and see how horrible it's going to be to "fix" it. Or I can just leave it as an exercise for my replacement...
  14. 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. :-)
  15. 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.
×
×
  • Create New...

Important Information

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