I have a VI that communicates via USB to a machine in my laboratory; one of its VI main features the Event Structure, that only talks to the machine when a given command has its values changed.
I'd like to use this as a subVI in another task. Nonetheless, I couldn't find a way to make the two VIs talk to each other: only changes in the machine's main VI produces an output.
How can one control the Event Structure from a different subVI?
To use an event in a subVI you need to input a reference to your control from you main VI and from that reference register to the event generated by that control.
A more detailed explanation can be found here: Detecting an Event in a Subvi from a Top Level VI
As a side point: From a design point of view, I don't think this is a handy way to go. Re-writing your machine subVi that it will take commands as input instead of events is probably not that much more work but will be more re-usable, extendable and maintainable in the future.
Related
I am trying to create a synchronized usrp source block in gnu radio consisting of multiple B210 USRP devices. Lang: C++.
From what I have found I need to:
Instantiate multiple multi_usrp_sptr as each B210 requires one and multiple B210 devices cannot be addressed by using single sptr
Use external frequency and PPS sources - an option that can be selected from block or set programmatically
Synchronize re/tuning to achieve repeatable phase offset between nodes - this can be achieved using timed commands API https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
Synchronize sample streams using time_spec property issue_stream cmd
The problem is how should I insert these timed commands and set time_spec of stream in GNU radio block or gr-uhd libs?
I looked into the gr-uhd folder where the sink/source code resided and found functions that could be altered.
Unfortunately I don't know how to copy or export this library to do these modifications and later compile to insert my custom blocks to GNU Radio, because gr-uhd seems to be built in and compiled at GR installation.
I attempted coping and then making the lib but that's not the way - it didn't succeed. Should I add my own source block via gr_modtool and insert only the commands I need?
Compatibility with uhd and its functions apart from just adding a few lines would be advantageous not to write the source from scratch.
Please advise
Edit
Experimental flowchart, based on Marcus Müller suggestion:
Experimental usrp synchronization flow
The problem is how should I insert these timed commands and set time_spec of stream in GNU radio block or gr-uhd libs?
For a USRP sink: add tags containing dictionaries with the correct command times to the streams. The GNU Radio API docs have information on how these dictionaries need to look like. The time field is what you need to set with an appropriate value.
For a USRP source: Use the set_start_time on the uhd_usrp_source block; use the same dictionaries described above to issue commands like tuning, gain setting at a coordinated time.
I was trying to find a proper way of synchronizing the USRPs via tags.
There are a few issues I came across in this approach:
Timed commands require the knowledge of the current moment in time, which is done via usrp.get_time_now(), even though I would request the USRP to give the time through tags I would have to somehow extract it from the output. (make some kind of loop and proper triggering) (source: https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD) or maybe plan everything not in a relative way - using absolute values instead of offsets. I have seen an approach to regularly reset the sense of time each PPS (set it to 0.0) and maybe then setting time of commands within range of 0.0-1.0 would be acceptable. Then the loop for reading and inserting time into commands would also be redundant.
I didn't found a way to create dicts in GR via blocks to make the solution scalable (without writing a few lines of code in textbox) or writing OOT block
In the end there is so little information to tell what kind of solution is most appropriate (PDU, events, are tags still relevant in GR
?), and the docs are so very scarce, that after some mailing I decided to add a simple class that inherits from the main top_bock.py and after instantiation of top_block it calls a few functions to synchronize the devices. This kind of solution is not the most flexible one, and the parent class top_block.py has to be called through the inheriting one, but it enables an easy programming interface.
Soon I will add an example of the code used in inheriting class just in case.
If there is any more neat, dynamic or scalable solution please let me know or point me to sources.
I have a large amount (about 50) of SubVIs including beyond some usage specific code a small number of GUI elements (mostly about 2: input and output).
My goal is to reuse those VIs without creating a huge mess in a new ('main') VI and collect all GUI elements on a GUI common pane a user shall finally interact with.
I tried to use the Open VI Function, 'VI Reference' and 'Run SubVi' like in the examples to create references for subpanels, but the subpanel ui is only shown when the program is run and the amount of additional blocks is mostly bigger than the code in the respective SubVI.
The SubVIs should be loaded only once to construct the main User Interface.
In addition: In this tutorial they create a subVI and recreate GUI elements that are already defined in the subVI.
I assume this behaves like passing arguments as in a text based programming languages like the snippet:
def main_vi(x, y, z): # inputs x, y, z
s = sub_vi(x, y, z)
return s # output s
Is this necessary, or can the subvi's GUI controls directly be reused from outside?
Is it possible to use the subVIs inside of an "main" VI that includes everything and maps everything to a common UI using tabs?
Or is it better to copy everything to the main VI, i.e. no code reuse at all?
Thanks in advance!
Depending on the functionality you are going for, yo may want o look into XControls. This would allow you to encapsulate your functionality into a reusable control that could be used on a main panel without making the main panel very messy.
Large UI's can be a pain (pun with pane not intended), especially if there are a lot of controls and indicators. There are some useful ways to break UIs into modular components. XControls are one of those but I don't recommend them due to their unpredictable behaviors. Instead look into working with Sub Panels. There is a great toolkit for this from a company called Moore Good Ideas (or MGI). More info can be found on their website here.
There is also a better alternative to XControls, called QControls. More info on them can be found here.
In general, though, you might want to look into a more modular framework. More info on Frameworks can be found here.
I would like to create a wxPython app such that:
If I run a second instance of that app (e.g., call the Python script from the shell a second time), no new instance should be created.
Instead, the toplevel frame of the already running instance should be raised and focussed.
The first point can be easily implemented by wx.SingleInstanceChecker (see the example code there), but at least the example code only gives a way for making the second instance of the app abort, but not raise the existing app's main frame.
I am using wxPython-Phoenix with Python 3.
Claritication: I would much prefer an out-of-the-box solution like wx.SingleInstanceChecker (that is, not implement my own locking and IPC solution).
You can use any kind of IPC to send a message asking the other program to do whatever needs to be done (just raise its top level window or maybe handle the command line options passed to the second instance). In C++ there are wxConnection and the related wxServer and wxClient classes that can be used for this, but I'm not sure if they're wrapped by wxPython -- however you could use any Python IPC module instead, if they aren't.
As has been pointed out, the "correct" way to do this is IPC because you have a new process that is supposed to affect a change (raise and focus) in another process.
What you seem to want is to take advantage of the IPC channel that wx.SingleInstanceChecker is already using to do your work. Unfortunately, you can't. That class is implemented in the wxWidgets c++ code and therefore there are no Python bindings to the internal workings of the class.
However, you can probably abuse wx.SingleInstanceChecker to do what you want. In your program, you can set up a timer at some rapid interval (say, 250ms) that will constantly check IsAnotherRunning() from your main process. Therefore, when your second process starts up, the first will notice and can raise itself to the front. You would just have to wait for a little bit in the secondary process before it exits, to give the first time to notice.
I wrote a rather complicated piece of code in Labview (with many loops and other sequences). Therefore I want to create many subVIs to make my code more clear.
When I have a loop in the code I want to have in a subVI, the icon of the newly created subVI appears far away form my original piece of code, causing my Block Diagram to expand.
Why does it happen and how can I avoid it?
The piece of code I want to turn into a subVI:
The same fragment of my Block Diagram after I created the subVI:
And here is my newly created subVI - approximately 1 m to the right at 1 m down in comparison with the first piece of code:
Thanks for adding images -- that is quite an inflation of the block diagram.
I don't know why LabVIEW is behaving that way, but my guess is that the control and indicator references are contributing.
As for ways to prevent it from happening, aside from refactoring the code (which is likely necessary anyway), you can try turning off automatic wire routing: Tools » Options » Block Diagram » Uncheck 'Enable automatic wire routing'.
Avoid creating subVIs that contain terminals in a structure
However, to move the block diagram's complexity into a sub VI will require some refactoring because you want to include a while loop that changes behavior based on front panel input (like the stop abs 2 boolean button). Otherwise, whatever value stop abs 2 has when the new sub VI executes will not change while it's running.
The LabVIEW Help reiterates this point: "Because the terminal remains on the original block diagram and the terminal is wired to the new subVI, the subVI does not update the value of the terminal on every iteration of the loop inside the subVI."
Here is an illustration.
Communicating with running subVIs
To send input and receive output from a sub VI while it is executing requires some data synchronization like queues or notifiers. Typical design patterns for this include:
Producer/Consumer on the targeted and simple side, to
Queued Message Handler in the middle, to
Actor Framework on the general and complex side.
I have a small application that needs to update GUI elements if some event occurs in lower levels, say, socket goes off-line, or something like that.
In Windows, I could use PostMessage which would be sent through the chain to all Windows, and the required ones could update accordingly.
How can I achieve something similar in wxWidgets? I cannot use OnUpdateUI, or something like that, because some controls doesn't seem to handle that at all.
The target window could be one or multiple, they could be frames or controls, so I'm confused a little here.
Does anyone have a suggestion?
First, all controls do receive EVT_UPDATE_UI so you could use it for this and it's a very simple of doing it -- but also the most inefficient, so definitely not recommended for something like socket event processing (it's fine for checking whether the socket is connected or not though).
Second, the exact equivalent of Windows ::PostMessage() is wxQueueEvent() (which used to be called as wxPostEvent() actually but the new version is preferable). wxQueueEvent() is thread-safe in the sense that it can be used from a secondary thread to post an event to a GUI control managed by the main thread.
You can use the same approach as in Win32 apps. You can create the custom event class and send it to windows using wxPostEvent function. There are some docs regarding this.
Not sure what you mean about wxUpdateUIEvent - from my experience it works pretty fine. What controls do not receive it? Did you add EVT_UPDATE_UI() macro to event table?