11-18-2014 10:16 PM
I was wondering if anyone has been able to use the "prompt user for input" block successfully with myRIO. Apparently, I am unable to use the block with myRIO, even though it works fine without myRIO. If anyone has used any other custom VI to do the similar function with myRIO, please let me know. Thanks!
11-19-2014 03:16 PM
Hello saif_huq,
Could you clarify a little bit more what you are using the VI for? You should definitely be able to call this function from the VIs your PC. However, you cannot call the Prompt User for Input express VI from a target without a user interface, such as the myRIO. What I would recommend instead is use network shared variables to pass information to and from the PC and target. You can have one shared variable that is updated by the myRIO when it is ready to receive user input and have the PC wait for this value to change. Then you can have a second shared variable which communicates the user input from the PC to the myRIO. Is that a reasonable workaround?
11-19-2014 10:27 PM
What is it you're trying to do, big picture?
If you're looking to prompt for user input, you generally stop the program until you get that input. The myRIO uses a Real Time Operating System. Real Time means you're guaranteed to have the process complete within a certain time period. How can you make that guarantee when you are waiting for user input?
Keep in mind there is a world of difference between reacting to user input and prompting(waiting) for user input. Does your project need the first or the second?
11-24-2014 10:03 AM
Thanks for your responses guys! Please note that I am an entirely new user for myRIO or even LabVIEW. I did look up the concept of network shared variable after seeing your comments, but that's not quite what I am after, it's rather simpler that that. The interface I'm working on is very simple, it should prompt the user to input few parameters (real numbers) right at the beginning and then enter into the main loop. Once it's in the main loop, there's no more interruption whatsoever. So basically, I was trying flat sequence structure with the "prompt user for input" block within a while loop in the box prior to the box where the main while loop is placed. If I place a "display message to user" block (which is very similar to the "prompt user for input" block) instead of the "prompt user for input" block, it works perfectly fine and displays the desired message on the screen and enters the main loop in the next flat sequencing box once OK is clicked. But if the "prompt user for input" block is placed, the entire VI enters right into an error state immediately, once the run button is clicked. Any idea what might be going on?
12-02-2014 01:03 PM
Hello saif_huq,
Real-time VIs are meant to be deterministic, meaning that you have to be certain when something will execute. The Prompt User for Input function requires the program to stop and wait for user input, which could happen at any time. As natasftw said, you can't use a function that will wait an indefinite amount of time to complete in a program that requires strict deadlines. As a result, you see an error when you use the Prompt User for Input function.
As we discussed earlier, however, you can always use the function on the host computer and communicate that data back to the real-time VI.
12-07-2014 04:15 PM
@saif_huq wrote:
If I place a "display message to user" block (which is very similar to the "prompt user for input" block) instead of the "prompt user for input" block, it works perfectly fine and displays the desired message on the screen and enters the main loop in the next flat sequencing box once OK is clicked. But if the "prompt user for input" block is placed, the entire VI enters right into an error state immediately, once the run button is clicked. Any idea what might be going on?
This shows a fundamental misunderstanding of what is taking place.
With the "display message to user," the VI really doesn't care about your OK. It's not waiting for you to hit OK. The program keeps chugging along.
With the "prompt user for input," the VI REQUIRES you to respond before it can continue on. What is the period of your timed loop? Let's say it's something extraordinarly large, like 2 seconds. Explain to me how you can GUARANTEE the user will respond within two seconds. If you can't do that, you have a failed desigin for your architecture. As you obviously cannot do this, you need to take a step back and understand the system you're working with. You say it's "much easier" than that. But, you really don't understand what you're doing to the system.
Here's what you really need to take the time to determine: Do you only want to set the values once or do you want them to be able to be changed dynamically as the program runs? If the first is your desire, there are several ways to accomplish this. One easy way is still the shared variable. Start watching the log after you've made this change. If you want to change it dynamically, you'll definitely want to use the shared variable. If you're dead set on the excessive "prompt user for input" style, do this on your host VI. Once you get the input, set a flag using a boolean shared variable and set the shared variables with the data. Now, when the myRIO reads these variables, the flag will tell it to process and the others will tell it which parameters the user selected. None of this breaks the determinism. It's not as "simple" as you describe. What you describe destroys everything about the OS you're working in. That's usually the opposite of simple.