Jump to content

Bryan

Members
  • Posts

    390
  • Joined

  • Last visited

  • Days Won

    16

Everything posted by Bryan

  1. Glad I was able to help! Actually, I think it was mutual as I think I learned something too. So 255.255.255.255 is only a good address for localhost-type UDP communication then?
  2. I'm not 100% familiar with UDP, but I'm wondering about the IP address your client is writing to and whether you're wanting to write to a multicast address (224.0.0.0 to 239.255.255.255). I don't think that 255.255.255.255 (FFFFFFFF) is a legitimate address to write to for either TCP or UDP. Or, is that just for your example? If you do multicast, both will need to subscribe to that address (in the range cited above) as Read, Write or ReadWrite.
  3. I've been registered on these forums for a long time, but don't get on here much (I hope to change that). Last flurry of posts I made was probably when I got my CLD back in 2008 (I've been maintaining it). I've since taken the classes to help with taking a CLA test (Advanced Architectures and Managing Software Engineering in LabVIEW), but haven't had the opportunity to apply the knowledge I gained from those classes, so I haven't taken the CLA exam yet. I've wanted to go to NI Week since... well... forever, but every year, my company won't approve budget for me to attend.
  4. Are there any prerequisites to obtaining a CPI? I thought you had to be a CLA before being able to be an instructor.
  5. I haven't received my certificate in the mail yet, but just recently found out that I passed the CLD exam, surprisingly with a much higher score than I received on the CLAD exam. Woo hoo! I just thought I would share that with you all. After a couple of years more of experience and studying up, I may try for a CLA certification.
  6. Thanks guys! Hopefully the CLD will come next year once my company has the budget to send me to take it along with the Advanced course. My ambition is to one day have the CLA certification.
  7. I know it's off topic for this thread, but since I mentioned it in here, I figured I'd post an update. I just got notification that I passed the CLAD exam! Woo hoo! I've been using LV since '99, so I should have been looking at CLD, but I took the free CLAD exam at a nearby seminar. I'm just happy that I finally have a bona-fide certification after wanting one for so long.
  8. Sorry guys... I've been out of the loop for a while. On a personal note, I just recently completed Advanced I and II training and am awaiting my results on the CLAD (free at a NI seminar) and will hopefully be taking the CLD before next year.
  9. Thanks for the reply. I did find the VIs you were talking about... however, I was looking for one for LV 7.1. I'm able to save it for a previous version though. Thanks!
  10. I thought I had some encoding/decoding VIs at one time, but can't seem to find them now. I've done countless internet searches of LAVA and other sites and all I found were links that led to nowhere. Does anybody have any base64 encoding/decoding VIs that they would like to share, or could point me to? I'm also looking for some various checksum VIs, but I haven't searched for them yet as they may be more readily available. For some reason I can't get my OpenG commander to work on my work desktop. I don't know if our IT department has locked down programs from accessing the internet or FTP anymore. It used to work, but when I tried to use it today, it wouldn't work.
  11. Well, just as an update, I was able to get the RTE to install and work by using the "ldconfig" command after I installed it to update the shared library links. However, my only problem now is figuring out how to create an image that includes the RTE.
  12. Hello again. I know I've dropped off of the face of the planet for a while. Sorry about that. I'm working on something for a project and have successfully been able to install LabVIEW 7.1 development environment for Linux on a machine running PuppyLinux 3.01. My only problem is that I can't get the RTE to work, although there were no reported errors when I installed it. When I try to run my application from a command prompt, like ./myLinuxLabviewApp . I get the following error: Can't load LabVIEW runtime library /usr/lib/liblvrt.so.7.1 libLVMesaGL.so.3: cannot open shared object file: No such file or directory The files are all there under the /usr/local/lib/LabVIEW-7.1 directory with symbolic links in the /usr/local/lib directory. I don't know enough about linux to find out where it's trying to look for this file.
  13. Well, here's what I've got:I have 3 copies of Developer's Suite (one with Auto Test, the other with Ind. Monitoring/FPGA/RT and a Dev Suite core only) each with their own SN and with 5 "permissions" for each. I also have 1 seat of LV full development. I've been our VLA for almost 3 years now and I never had any training in it and have no idea what I'm doing. I'm trying to create "network installers" as I'm now finding out that I distributed the software incorrectly before. Now, I'm trying to do it correctly, creating network installers for people to use to access their permissions and what not... but I'm confused as to how I'm supposed to distribute them easily. I know how to create an installer, it's straightforward, but since I have 3 copies of Dev Suite, each under their own SN, do I have to create a new installer for EACH software component under their specific SNs? I.e. LabVIEW installer for A12B4567, C89D0123 and E45F6789 (I made up those SNs) and for each copy of LabWindows, etc? Then create file structures with shortcuts that point to each "correct one"? I don't know if any of the above made sense as it's late and I'm tired...I've looked at the online literature and examples and they don't cover the Dev Suites in the VLM very well, let alone multiple Dev Suites in a VLM. Forgot to mention... all of my permissions are computer based.
  14. Is there a section on LAVA for VLM-Related Stuff? I'm currently the NI VLM Admin for our site and I'm just getting around to working on getting things working "properly". I've come up with a lot of questions though since I never had any formal training in VLM Administration and some of the online stuff on the NI website doesn't cover things to the level I'd like. Is there a place in here for this type of stuff (I couldn't find a section that "fit" except maybe LabVIEW General), so I put this in here.
  15. Bryan

    It's a girl

    Congrats! Makes me think back to when my son was born. He turned 2 a couple of weeks ago and it's just been a blessing all around. It is too bad that they don't come with instruction manuals. The scariest day of my life was when we strapped him in his car seat for the first time and the nurse waved "bye-bye". My wife and I are actually kicking around the idea of trying again for another one this spring. We're going to shoot for a girl, but of course will be happy with either gender so long as he/she is happy and healthy. Again, congrats and welcome to the toughest job you'll ever love!
  16. QUOTE(TobyD @ Sep 10 2007, 01:35 PM) Makes sense for recruiters, but not for potential candidates where location plays a huge role in whether they're willing to relocate for a job... unless someone's desperately looking for work.
  17. Would you be able to tell us the city/state of this position or any additional details?
  18. Yes, I have that, but I'm one of those "double-click anywhere and start typing"-type person. I guess I'm looking to save myself some mouse clicks.
  19. I'd like to change the font/colors/etc properties of the font text box so that it stands out a little more. Right now, I have to do this by manually changing its properties with the color tool/etc and then copy/paste it wherever I want to add a comment. I'm wondering if there is a config or something in the LabVIEW INI file that will allow me to change the comment properties so that I don't have to manually do it myself everytime I want to add a comment. Anybody know?
  20. If that's the case, than I'm the LabVIEW Architect for my company... and (have been told) the guru. Quite frankly, that scares the chit out of me since compared to most seasoned people in here, I'm pretty much a little ankle-biter.
  21. So, if I understand you correctly, if the other application sets the serial settings and accesses the port, the command line method will then contain the values used/set by the application? Interesting. I'll have to give it a try. UPDATE: You're right! Now the command line returns the correct values. All I need to do is write a function to parse out all of the information. Thanks!
  22. I just tried using the command line approach and the values returned to me don't match the configuration in device manager. i.e. Device Manager = 9600,8,n,1. command line = 1200,7,e,1. I only have one com port on my current machine, so I'm sure I'm accessing the correct one.
  23. Yeah, I've thought of that. I haven't been able to get LabVIEW and other support applications I need to all install on DSL and run in RAM. I have 62+ machines that I'd like to have up and running the same application all at the same time. I don't really want to have to buy 62+ USB sticks to accomplish that task. I'd really just like to get something up so that I can run a LabVIEW executable and install GE's "vmisft" software onto it (since my LabVIEW application depends on it to access the VME bus). Inasmuch as I would like to do this in LabVIEW, I'm afraid I may have to go an alternative route and get some sort of linux-only solution where I have a linux C-application that does the features I'd need, which is essentially to receive, parse, execute and respond to commands I send to the computer over the network. Unfortunately, with my little knowledge of c-programming in Linux, I may have to consult one of our resident Linux gurus for help with this.
  24. I thought this would be an easy one? Nobody has any insight? I can provide add'l information if anybody needs it.
  25. This is in LV8 BTW. It seemed like a simple enough task to do, but it doesn't work how I envisioned. I haven't beat my head over this too much as I have other things going on, but maybe you guys can tell me what I'm missing. We have a computer that has it's serial settings applied by a completely different application (non LV or NI). What I want to do is read those serial settings into LabVIEW for use in one of our verification applications. Sounds simple enough, right? When I look at say, the COM1 settings under device manager, I see certain settings. When I try to read those settings into LabVIEW using the NI VISA resource name and property node, I get the typical default values (9600,8,N,1). Then, I'll open MAX and it will show a port settings conflict. I'm not a VISA guru by any means and this is the only way I currently know of to access a serial port in LabVIEW and it's always worked fine for me, but I've never used it in this manner before. Is it possible to see the "Windows" settings from NI VISA to read into LabVIEW, or do I have to look at a different route? For those curious, our LabVIEW application runs a hardware verification on the system and checks for communication over the serial ports. The other application that's supposed to run on the system sets the values, which are different per system (and we have 60+ systems to check). Whenever we wrote our verification application,we weren't told what the settings were SUPPOSED to be, so our application has always used the defaults just to check for communication. But, when we run our application, it changes the settings in VISA and seems to be affecting the windows settings to the point where when we finish our verification and start the other application, it generates errors. At least, I THINK that this is what's causing the errors. I just figured it better (and the easiest way to remedy the problem) to just read in what the other application set the com port settings to, then use that for our verification so that we don't see the problem anymore. Maybe this is something easy and I'm missing something simple. I've been working 8pm to 6am for the past couple of weeks and my brain isn't running at peak performance.
×
×
  • Create New...

Important Information

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