I have created two vi's in LabVIEW: one to acquire serial data and another to plot the acquired data on an XY graph.
The second VI gets called when a Value Change event occurs on a button in the first VI. But the problem is that when the second VI is called the first VI suspends its operation, hence the values don't get updated.
Is there any solution for this?
First VI block diagram:
First VI front panel:
Second VI (ALL DATA) block diagram:
Well, you are doing some nasty stuff with global variables. This works but is not considered as good practice. (Have a look at queues and notifiers). Further, I don't see how your data gets written to those variables...
In any case, put your 2nd VI in a separate while-loop and schedule it to about 100ms (that is usually enough to update front panels or to interact with users. I'm not sure if your button-event is the right way to go. That is exactly because, the second VI waits for the callback. Just use a simple button and a true-false case to let the second VI keep running (this should even be the solution if you don't want to move the case to a second VI). Just make sure that you change the mechanics of the button to be a switch because you're checking its value not at infinite speed and you want to ensure that it gets caught every time, you click it;)
You will need to use the VI Server functionality. The exact method has changed over the years, but I believe the current recommended implementation is to use 'Start Asynchronous Call'
There is an example that you can view using the example finder. To open the example finder navigate to Help>Find Examples. Then select the 'Search' tab and search for 'asynchronous'. Finally select the VI called 'Asynchronous Call and Forget.vi'
There are other variations for asynchronous implementations, but this is probably a good place to start.
Related
first, I cannot attach my vi files, sorry. I'm not allowed, but I can attach snippets.
I've got a vi that opens and executes functions from a script file, and I'd like to be able to continuously click a button to reload the script file without having to restart the program. Currently the script file commands sit outside my main while loop and and uses a case statement to put the system in idle mode (manual control) when the button is not depressed before launching the program, or if it is, it will instantly open a dialog box looking for a script file upon program launch. I'd like to be able to open a script file numerous times during the execution of my program, but don't fully understand how, and this may be my own misunderstanding of what's going on with the code if I move it inside the main while loop. how is this best accomplished?
If you put your code outside of the loop, it is only executed once (very important: "dataflow"). You need to put the code into a loop to execute it multiple times.
You can insert the vi-snippet into your vi by drag&drop.
My vi contains two different options. You can change the vi as you need it, my vi is incomplete. I inserted a simple 2D-Array because I'm not sure if the vi you use after building the path is selfmade or given by LabVIEW.
For both options you should let the code run in some kind of state machine and use an Event Structure (I think you already implemented your program this way since you wrote about a main loop).
Version 1:
Everytime you click the button, the event is triggered and the code inside the event structure is executed.
Version 2:
Here you set a boolean if the button is pressed and handle the event with that value.
Since you wrote that you already have a main while loop, this option might be better four you. The first loop would be your main-loop, second one would be the loop in Version 2. You just need to add another case for the script to be loaded in.
VI:
I hope this is helpful for your problem.
Feel free to ask if you need more help or if you have any questions :)
so i have got a problem programming micro:bit. I code it in internet page, then download the hex file and transfer it into the micro:bit. On the internet simulator everything works. Apparently when i transfer it to micro:bit code is not working. The code is really simple, it looks something like this.
animation repeats while variable is 0 (this part works perfectly)
A button makes the variable 1, B makes it 2 (this part works)
when variable is not 0, it breaks first animation loop. (this part also works)
then goes to second loop which repeats while variable is NOT 0 (it will never be a 0 because there is no button which makes variable 0) so it repeats for ever (this works)
in second loop, there are 2 more loops. First repeats when the variable is 1, second when the variable is 2. That makes me able to switch between these 2 loops any time i want. (Problem appears here: i am in loop 2 for example, i cant switch to first loop and otherwise.)
All these errors occurs in micro:bit robot, when code is transferred. In internet simulator code works perfectly. Is it possible to do that code in micro:bit, have i reached limit? Or is robot defective? Thanks for answers and inform me if something is not clear.
This is of course very hard to debug without seeing any blocks/code as I don't know how you are detecting the buttons being pressed when in the second loop.
However, this may be a scheduling issue due to the way you are changing the variable upon a button being pressed. Perhaps consider restructuring your blocks such that they are more event driven, utilising blocks such as on button A Pressed a bit better, infinite while loops are always best to avoid. Also, maybe consider putting a pause(100) in the while loops.
Hope this helps ;)
Edit:
OP confirmed that the pause(100) worked (see comments of this answer), demonstrating that it was a scheduling problem!
For those who are interested ;)...this is because the CPU is busy executing the while loop and doesn't have time to think about the buttons being pressed. The pause(100) allows the CPU to rest for a bit and not think about the while loop, giving it the time needed to deal with the button press. This is known as Cooperative Scheduling!
You can find out more about Cooperative Scheduling at:
https://www.microbit.co.uk/device/reactive
If your code looks like this, you will never be able to change your state variable. You'll get stuck in one of the inner loops, with no option to change the control variable.:
while (unset):
Animate
Check for button
While (set): // Intend to be stuck in this loop forever
While (one):
Do first
While (two):
Do Second
What you need is to be able to update your state:
...
While (one):
Do First
if (button_b.was_pressed()):
state = two
...
This still isn't perfect, you might want to think about what happens if the buttons are pressed in 'unusual' sequences. The simulator should be identical, but there might be something unusual about the way that button presses are handled and your code that have broken the simulator. If the simulator really is broken, you'll need to share a testcase with the micro:bit team.
I have to display a popup for a legend like in STMS transaction
I know how to write this tab with WRITE statement, but how can I display it in a popup?
You can achieve this by using CALL SCREEN ... STARTING AT ..., then using SUPPRESS DIALOG in the PBO processing to bypass the screen (dynpro) processor. Then, in the PAI processing, use LEAVE TO LIST-PROCESSING followed by the WRITE statements. You can follow this in the function module TMS_UI_POPUP_LEGENDE that shows the popup you mentioned as a reference. The procedure is documented in the online help as well.
In an ABAP dialog application, you're either working with screens or with (interactive) lists. To get a popup window, you have to create and CALL a custom screen (dynpro). Inside that screen, you hand over control to the list processor. That's the component responsible for taking what ever you WRITE and place it somewhere on the screen. For some - probably mostly historical - reason, the command to do so is LEAVE TO LIST-PROCESSING. I suppose that at some point, the intended flow between screens and lists was different from what it has become today, and that was the reason for naming the command this way. From a modern point of view and especially in your use case, the LEAVE aspect does not make any sense, so just take it as it is and use it.
Also note that it's LEAVETOLIST PROCESSING - LEAVE LIST-PROCESSING without TO is the opposite statement!
What is the best way to understand a complex LabView VI that controls a motor?
My goal is to control the motor from a joystick.
The wiring diagram shown below allows a LabView user to control the motor from the LabView GUI: move a slider up and down either increasing or decreasing the desired velocity. As the slider's value changes, it is fed into a bunch of math controls and eventually gets converted into a command string for the motor to interpret. This command string, if I understand correctly, is bunch of bytes that get written to the serial port.
Instead of using the LabView GUI to control the motor, I would like to use the joystick.
What is the best way to approach this?
The joystick has pitch,yaw,roll,and throttle. Which one relates best to the velocity of a motor?
The answer to your title "What is the most efficient way to quickly understand how a complex LabView VI works?" is probably to do some combination of the following:
Look at the VI's inputs and outputs to try and understand what they are there for. The label and caption of controls and indicators may be helpful, also right-click to check the description and tip.
As well as controls and indicators, look for other I/O: queues, notifiers, global variables, file read/writes, instrument communications, and for any data storage that persists between calls such as an uninitialised shift register.
Look at the overall structure of the VI to see how it executes, e.g. is it a one-off operation, does it execute different cases depending on some input, does it loop until a certain condition happens, does it use a state machine structure, etc
Break down the VI's structure into smaller pieces that you can understand. You could print the diagram out and annotate it by hand, or add frame decorations and text comments to the diagram to record what you deduce. If the diagram is cluttered or poorly laid out, rearrange it as you go along (use Ctrl-click and drag on the diagram background to add blank space where you need it).
Set probes on key wires and watch them while the VI runs to see what happens
If possible, manually set the VI's controls to example values and run it to see what happens (this may not work if the VI depends on other parts of a program running at the same time)
Write a test wrapper VI that calls the complex VI and supplies it with example data or inputs to see what happens.
To address your specific question about the VI diagram you've posted, I can see various controls for quantities such as Velocity, Position, Amplitude, Max A (amplitude?), Frequency and so on. You need to decide which of these quantities should be controlled by which axis or output of your joystick. Then you need to add code that reads those values from your joystick, and modify the existing code so that the parameters you want to control are supplied by the joystick values instead of the front panel controls. You could probably just put the joystick reading code inside the existing loop, wire the joystick outputs to join up with the wires from the front panel controls you want to replace, and then change the relevant front panel controls to indicators from the right-click menu so that they will show the values you are getting from the joystick.
The best way is to write one from scratch. But you could analyse the code by clicking the Highlight Execution button to display an animation of the block diagram execution when you run the VI, and use probes to check intermediate values. And you probably should also do an on-line course, e.g. LabVIEW Training: Learn LabVIEW in Three or Six Hours
My answer to your third question is "throttle.".
Sometimes when I am using less within a screen tab, the arrow keys display ^[OA, ^[OB, ^[OC, and ^[OD instead of doing what I want them to do. Is there something I can do to fix this and gain control of less again?
enter !reset at the less prompt
I have found that reset from within screen does not solve the problem sometimes, as it's the outer client/shell whose state is actually confused and screen captures the control characters from reset and prevents them from reaching the outer client. In this situation, I have to detach my session (Ctrl+a, d), run reset, then attach to the session again (screen -r).
If it happens from time to time, it seems, that some application (e.g. cat or less a binary file) shatters your console by sending it control characters. You need to run reset command from command line to recover.
Otherwise you have to trick your terminal application. I suggest you to use CryptoTerm which allows you to define custom key mappings.
Another thing to check is your TERM variable. In my case I ssh into a Linux box and run less inside screen - the TERM variable was set to 'screen' - which breaks arrow keys. It works perfectly if I run less this way:
TERM=xterm less <file>