Jump to content

Wire Warrior

Members
  • Posts

    226
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Wire Warrior

  1. You might try looking at the examples that shipped with LabVIEW.
  2. Excellent yet another peice of code to taunt the text based programmers at the office with! Jason
  3. I feel better now. I'm not the only one who wondered about the logo. I won't say I lay awake at night. It's usually more of a drive time commute thought process at the end of the day. Jason
  4. Remember, chicks dig giant robots. Jason
  5. Hmmm...The menu suggestion makes me wonder. Does the menu have to be shown on the front panel to generate events using hot keys? My gut feel is yes but I really don't know. Jason
  6. Congratulations to all three of you! And welcome to your son. Jason
  7. It sounds like what you want to do is create a source code distribution. There are options in the build specification for including information in the user.lib and vi.lib. This article on NI's Developer Zone might help you Distributing Applications with the LabVIEW Application Builder. Hope this helps. Jason
  8. Well, to start with your going to need some type of analog input/digital output hardware as part of your system. I would imagine the best place to start is with some of the examples which ship with LabVIEW. If you look under the Help tab on the menu, you will see the "Find Examples..." option. This will bring up a dialog that will allow you to look at a variety of solutions to some of the basic problems. You would probably find lots of help looking at the Digital Output examples and the Analog Input examples. Jason
  9. I have solved the problem I think (at least as far as testing to this point has revealed). After I added in the ability to log the states passed to the QDSM's, I was able to determine that the program was "crashing" after I dynamically closed the front panel of the launcher. My program was designed to close the front panel of the launcher then pop-up the front panel of the main UI. My EXE is built on to contain the launcher with my other QDSM files being maintained externally in specific directories. What appeared to be happening is that when the launcher closed its front panel and before the UI opened up the run-time engine would decide since there were no windows open it would close itself down. This is my supposition about what may be happening any way. I modified my code to changed the launcher window to hidden and delay for 1/2 a second to give the main UI a chance to start fully running. This fixed the problem, or at least worked around it. If someone out there can explain to me exactly what is happening I sure would appreciate it. Thanks for all the help those of you who responded. Your advice was very beneficial and certainly led me to a resolution faster. Jason
  10. Thanks for the suggestion...I downloaded the f2 patch and recompiled yesterday. Didn't help the problem. Jason Thanks for the suggestion, I have some error logging in place but having the state machines log behavior I had not thought of. Jason
  11. I have a compiled program created with LabVIEW 2009 that on the first run after the computer is re-booted will work fine but after shutting down the program it will not run properly. The program uses a compiled launcher to dynamically activate a set of VI's containing Queue Driven State Machines (QDSM). On subsequent program starts the launcher module comes up fine and its progress bar shows that it is launching each of the VI's. Once the launcher is complete it removes itself from memory leaving the dynamically launched VI's running. The subsequent launches which fail the main user interface VI pops up barely long enough for the observer to see (if at all) then shuts down. The program is then gone from memory as far as I can tell. There are no processes in memory or anything. Additionally, the when I try to run the installed version of the exe on a computer that has the 2009 development environment installed I get this behavior consistently with a successful run even once. In both cases my program does not throw any errors (which are logged) nor does the runtime engine generate any that I can see. Also, when I run my program in the development environment the program does not behave this way. It has no problems at all. I have used this style of architecture before in LV8.6 with out any problems. Can anyone suggest some possible solutions or even some debugging tips? I have never had a problem that I could not duplicate in the development environment so I am unsure how begin attacking my issue. Thanks for any help. Jason
  12. Okay, so what's RTB for us acronym poor folks? Jason
  13. Don't ruin my dream man! Writing games is what got me started programming....okay so I was like twelve and didn't know what I was doing on my Commodore64. Still, I have considered writing a game now and then in LabVIEW to prove I can. Jason
  14. Hooovaah, Are you suggesting that multiple UI's be created as unique VI's and then launched at "run time" with a dynamic launcing scheme? If not I don't think I under stand how to do this. Interesting way to solve the problem though. Thanks Jason
  15. Great, another LabVIEW thing that keeps me from doing productive work. "No really boss, this isn't a game it's a learning tool." Jason
  16. That's cool. I would love to have one of those. Jason
  17. I am hoping that one of you out there can help me find a paper that I found on NI.com the other day. It was one the topic of more efficient ways of coding string selection routines. I read through it on a saturday and now of course I would like use one of the recommended techniques but I can't find it or clearly remember the information. Is there any chance any one here knows the paper I am speaking of? If so a name or link would be great. It's beginning to bug me now. Thanks Jason
  18. Thanks for the info! Now I need to post more. And one more to up the count.....Bwah-ha-ha-ha!
  19. I'll also chime in and say Nancy's classes rock! Matter of fact the Advanced class she taught is how I found LAVA and much other LabVIEW goodness on the internet.
  20. Okay, here's my issue. We have an in house piece of test software which we are working on a new release for. Some of the new features require the use of the PortMon program (serial port monitor) for use during the verification/validation process of the software. These are not needed during the normal operation. We would like to have the NI LabVIEW application builder automatically include the installer for PortMon on the distribution CD but not run it during the install, preferrably to not even install it on the target machine (Windows XP OS FYI). We are concerned with later releases not having the required support software installed if we simply trust it to human action. Has anyone done this with the NI App Builder? Know of an article? Anything? I have tried searching the NI site and LAVA but I have not been able to find the right information. I would appreciate any help any one could give. Thanks Jason
  21. QUOTE (crelf @ Mar 3 2009, 02:14 PM) It took that long to get to the 'crelf on LAVAG said' part of the description. :laugh:
  22. So if we chant Darren 3 times will he come answer this? Let's see.....Darren, Darren, Darren...
  23. Just remember guys....all those really bad software QA folks have to come from somewhere. You know the ones...they have a computer science degree or some such but some how managed to miss the concept of how a computer works? I would think its the ones like this who get us to "help" with there problem. Do I need to mention that we are dealing with out of house QA folks this week? Jason
×
×
  • Create New...

Important Information

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