Re: XY Graph question
Hmmm... It looks to me like you should be able to as if you'll look under XY Graph Properties->Plots, each plot has a drop-down list of items specifying the Y-Scale and X-Scale that the current plot is using. The only problem is, each list only contains a single item - either the current X-Scale or Y-Scale, and under the scales tab (unless I'm blind), I can't see any options that might allow you to create new scales... As a stop-gap, just write your own VI that will scale the second plot's Y values to correspond to the first plot's Y scale - should take you maybe 5 minutes, and then you can always take it out later if you find a new way. Sorry I'm not much more help than that.
How accurate is the wait function when using really long waits?
Howdy all, There was a similar earlier post asking about wait accuracy over small periods: http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=5065000800D4A2&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=Accuracy+of+Wait+Function&USEARCHCONTEXT_QUESTION_S=0 but I'm interested in the behaviour of the wait function over long periods. If I tell the wait function to wait 19 minutes (so 19*60*1000 = 1140 ms) assuming average system use (ie, system resources are consistently available, not many programs running in the background), what sort of accuracy can I expect? Or will it end up being entirely system dependent? If NOTHING is going on in the background, can I expect the function to terminate after approximately 19 minutes? (if it's within 30 seconds, I'd be happy) Any better ideas for handling long waits? Any comments, ideas, etc. are appreciated
Re: I can't open my VI
Hi Alex, Sorry, but I can't open that VI either. I had exactly the same problem yesterday involving three very important VIs to a large project at work. The project has a vision component that I was testing yesterday. We're short on hardware, so I was given a crappy IMAQ framegrabber card that everyone told me didn't work. It worked for me for some reason, but after using it all morning, my computer started crashing whenever I quit LabVIEW (I don't know enough to blame it on the card, but I'm fairly certain the card caused all the crashes). After one reboot, loading my project, LabVIEW did the same thing to me saying for a couple VIs, even though it hadn't been moved or altered. Since this is a very large project, we back-up daily, so I just restored the files I had been using yesterday (which seemed identical to me, as I hadn't modified those files since yesterday) - and LabVIEW recognized the restored files like there was no problem. I hadn't had that problem before then, and I don't know what causes it, but I'd be very interested if anyone did. When was the last time you were able to open it? Did anything out of the ordinary happen between the last time you were able to open it and when you couldn't open it? (like did your computer crash?) What version of LabVIEW are you working with? (I'm working with LabVIEW 7.0) If that's a very key VI for your applications, and it hasn't been backed up, I'm sure the folks at NI would be able to do SOMETHING to your file to restore at least some of the work. Hope someone else can fill in more details than I.
Re: How can I communicate betwen parallel asynchronous VIs?
Yup, I've reworked my VIs and it works exactly as I wanted. I feel pretty dumb... my new golden rule: keep it simple stupid. thanks again
Re: How can I communicate betwen parallel asynchronous VIs?
and I guess I should come up with a new expression other than "frustratingly lacking at times", since I used that one already...
Re: How can I communicate betwen parallel asynchronous VIs?
tmh, No, I'm pretty sure you understand perfectly, as that's exactly what I wanted to do. I knew that if you had two loops on a block diagram, they would execute in parallel, but I assumed that if you had a loop and a SubVI on a block diagram, that whichever one started executing first would have to terminate first. I was making the problem much more difficult then it needs to be, as that method would allow me to use notifiers to achieve the intended effect. As far as notifiers 'not working with the VI Server' as I must have put it, I got that straight from the LabVIEW help files. Under the topic "Notifier Operation Functions" I read that "You cannot use notifiers to communicate with VIs on other computers. For example, you cannot use notifiers to communicate across a network or the VI Server." Originally, I was using a named notifier. So, my "master" vi would create a notifier to send commands with, then it would launch the "slave" vi asynchronously with an invoke node, and send commands when necessary. The Slave obtained the notifier by using the "Obtain Notifier" vi, supplying the same name as the Master did for the name parameter. This worked fine when I was testing - however once I built my program to be an executable, the Slave created a new notifier, rather than obtaining the same one being used by the Master. (I'm not 100% sure that's the exact reason - it may just not have received commands [it was a while ago that I was playing with that approach]. But I do know that that method works fine in an uncompiled program, but once it's compiled, it stops working. Who knows - there may exist actual ways to pass the notifier, like a global variable or something like that). According to the *fabulous* LabVIEW documentation, Queues don't have this limitation, so I rewrote my VI to use a queue of length one, rather than the notifier. -sidebar (does anyone find that the LabVIEW documentation can be frustratingly lacking at times? Like, why can't I use notifiers across the VI server? And why can I use queues? I'm not asking for them to show me the guts of LabVIEW, I just think that it would give developpers more control and confidence when coding that they know what's going on, and have at least a general idea of how things work) --end of sidebar However, somewhere in my switch between Queues and Notifiers, I must have messed up something, as after that worked fine during the testing phase, after a compilation, I received an error (1013 I believe) whenever I tried to load my slave saying "Front Panel Heap Dump" - which is strange because the front panel of my slave should not have been loading, and was supposed to have been removed from the executable. Not that that last bit is super relevent to the original topic of discussion, but it might be useful to someone later on. In any event, thank you for your help. I suspect that that will be the perfect solution for my needs, and when I get back to that chunk I was working on and get it working, I'll let you know. Thanks again.
Re: How can I communicate betwen parallel asynchronous VIs?
Hi Rob, Thanks for your suggestion. I had seen that method of changing the value of some panel's control before, but it hadn't occured to me to use in that manner. I thnk that's actually a pretty clever, and could be quite useful. Unfortunately, this method wouldn't really work the way I want. My task is an iterative one, being run in a while loop. Between iterations of the loop, there is a set delay time. In certain situations, this can be quite substantial. I was attracted to using notifiers because of the "Wait on Notification" function. This would allow me to track the amount of time spent waiting, but I could break out of the wait period instantly when I received a command. If I used the "Wait" function and specified a certain length of time, I can do nothing until that time has elapsed. So if the delay is 10 seconds, my VI won't terminate for 10 seconds. I could break the wait down into several sections to reduce the time between sending the command and receiving it, but this would amount to polling a variable and I don't want to do that. In any case, sincere thanks for your suggestion. Victrick
Re: Calculating statistics from an array with intervals
Sander, I'm 100% sure I could help you... if I knew what you were trying to do. The more I read your description, the less I understand, and since I don't really know what you're trying to do, I can't do much with your code. It seems to me like your real problem is your ability to partition the original array into smaller arrays to do calculations on. If you can describe to me EXACTLY how the arrays are supposed to be partitioned, then I can help you out, even write you a VI that will do the trick, but I'm fuzzy on what's supposed to be happening. Here's my understanding so far: Everytime an element in the first column satisfies some value, it corresponding value in the second column is set aside to be used later. Help me help you.
How can I communicate betwen parallel asynchronous VIs?
Howdy all, Here's my situation: - I have some task that needs to be executed in parallel to the currently running VI. In fact, this task needs to executed in parallel to a number of VIs, so I've decided to build a sub-vi to handle this task. - This task involves performing some processes every X number of milliseconds (usually in multiples of 1000). This task will be performed until it receives a stop-command (the user generates this signal - so I have no way of knowing when it will be) - I still need to be able to handle user interaction with this main VI while the task is executing, so my task must execute asynchronously. - I want to be able to send a termination command to my asynchronously executing task, and have it respond IMMEDIATELY (polling a global variable is unnacceptable). --- The only way that I am aware of running a VI asynchronously is to start it with the VI Server (either the Call by Reference Node, or the Invoke Node). Originally I planned on using notifiers to send commands to the asynchronous VI. Notifiers would have been perfect, because I could break out of the waiting portion of the task as soon as I received the command (this isn't really possible when polling a global). Later I found out that notifiers are not supposed to work with VIs loaded with the VI Server. My notifier approach worked fine during testing, but wouldn't work when I compiled the program as an executable (which is what the end product will be, so I need a new solution). I'm about to change my implementation to use Queues instead of notifiers, because I think I can achieve the same "Wait on Notification" functionality with a queue, except I don't think there is a restriction on using a Queue across the VI Server. My Questions are: Is there another way to get VIs to execute asynchronously OTHER than the VI Server? Is there a better way to communicate between them? (I considered using a User Event control, and generating the commands using that, however I can't poll the status of the User Event without an Event structure, preventing me from terminating my task once the user generates the "end-task" request. Does anybody else find the LabVIEW documentation to be frustratingly lacking at times? Any help, comments, or stories of similar situations would be appreciated.
Re: Shift register or Local Any differences in performance?
>From what I understand, using local variables is frowned upon unless they are ABSOLUTELY necessary. In my mind, there is no debate and I would take the shift register. Here are my reasons. 1. I believe that each local variable you have on your block diagram takes up the same amount of space as the original object itself (I'm 99% sure this is correct, can anyone confirm this?). So if you have an numeric indicator that displays a double, and you have 6 local variables linked to that indicator, in terms of memory, you might as well have 7 indicators. If you have one shift register that stores a double value, no matter how many states of your state machine assign values to that shift register, you will only ever have one copy of the data, and only one double 2. Local variables access the data stored in a front-panel control. Depending on what you are using the state-machine for, I think it would be rather unlikely that you want your user knowing what state the machine is currently in. Even if you did, you could wire a front-panel indicator to the shift-register inside the loop to achieve the same effect. I think using a local variable in this situation greatly compromises readability because (likely, again this will depend on the particular state machine) there is no logical association between the state of the machine and the object to which that local variable leads. In other words, the state of the state machine is a property of the block diagram. It doesn't make sense (to me) to use a front-panel object to store a property that will only be read and modified on the block diagram. I'm talking about state machines in general. These reasons may not apply, depending on your specific application of the state machine (for example, I've often used a tab control in a dialog to simulate a wizard program, guiding the user through some complicated process one step at a time. Each tab of the control corresponded to a different state in a state machine running on the block diagram. In this case, you want the user to know which state they're at. However, that is special case of state-machine) A general tip is: as tempting as it may be, you never should be using local variable because you want to avoid long wires. Hope that's helpful
Re: How can I design my LabVIEW app to behave differently based on installed components?
Andr=E9 and James, Thanks for your help. Right now, I'm using the "SHGetSpecialFolderLocation" and "SHGetPathFromIDList" functions of the shell32.dll to get the windows system directory.
How can I design my LabVIEW app to behave differently based on installed components?
Howdy all, I've got a program that is complete, and offers some basic service. Advanced users will have the option of additional functionality. When users decide to use this program, they decide what capabilities they want - whether it provides just the base functionality, or if it has the advanced functionalities. The additional functionality relies on the installation of an additional LabVIEW component. In this case, the base package requires simply the LabVIEW(7) runtime engine. However the additional functionalities are vision related and require the installation of the IMAQ Vision 7 Development Module. I would like my program to detect the installation of the vision module on the user's computer, and give the user access to these vision functions ONLY if the vision pack is installed. (ie, I don't want to have two versions of the program - the user only installs one complete version, but some components will be hidden if they don't have the vision module) Currently, this program checks the Window's system32 directory for the presence of the imaq.dll and the nivision.dll. Right now, this system *sort of* works on most computers, but if the user has their windows installed in a non-standard windows directory (say they installed windows to "windoze" or something other than the standards like "Windows" and "Winnt") Does anyone know of a way to programmatically detect the installation of the Vision module? What I'm doing right now would work in 95% of the cases (I think) if I could nail down the root windows directory (which I'm pretty sure is stored in the registry for all Windows versions, but the name of the key depends on the version of windows, and I would rather not go down that road) Any help, stories about similar situations, etc., would be appreciated.
Re: Labview 7 Application Builder
H... A few more details might be a little more helpful... If you could write a scaled down version of your program that demonstrates the problem, that would be helpful for anyone trying to solve your problem. I wish I could help you as I'm also doing some stuff with the HTTP server, but I'm just starting and don't have much experience with it. One that comes to my mind is: When is the webserver activated? You can programatically engage the webserver once your dynamic http vi is run, and disengage it when that VI is shut. (This may have been the first thing you've tried and be thinking "thank you captain obvious" - in which case I apologize. Sometimes it's hard to judge the level of experience of the user from their posts. I reiterate that if you provide a sample VI that can reproduce the problem, it could go a long way towards solving your problem)
Re: Freezing Tab Control/State Machine
The event handling is divided amongst multiple loops for the sake of encapsulating the related code - in the actual program, there are lots of controls on each tab and lots of events to handle. Lumping all the events together in a single event structure makes the code less readable then I would like. The two tabs are supposed to behave like entirely separate dialogs - because in my situation it's not desirable to have to load another VI. (This tabbed dialog resides in the subpanel of a main frame. I don't want to programmatically load a different sub-panel, as these two tabs are enough alike to warrant being grouped together). Plus, each tab has it's own intialization and shut-down sequence - just like a top-level VI might have, which further complicates the one event structure approach. Thanks for trying to help me out, and I appreciate the code snippet, but it wasn't quite the reply I was looking for. Maybe I should have more clearly stated my request. Any ideas as to the cause of the freezing? To my (perhaps untrained) eyes, there seems to be no logic problems in my original diagram. This is what I see - the inner loop terminates, and the tab control is reset. The front panel is locked until the event completes, and as soon as the panel unlocks, the tabs should be switched so there is no way that the button should register the double-click. I was wondering if I could get some etails as to the true cause of the freeze. If anyone had some more information about tab controls, etc., it would be appreciated.
