LabVIEW Task Manager v1.10.0 (for LV2013+)
This code is Open-Source, and free of charge
Authors: Ravi Beniwal, Tim Vargo
LabVIEW Versions Supported:
LabVIEW Versions Tested on:
GPower Error & Warning = 220.127.116.11 lava_lib_tree_control_api >= 1.0.1-1 NI SmartBalloon = 18.104.22.168 OpenG Application Control Library >= 22.214.171.124 OpenG Comparison Library >= 126.96.36.199 OpenG Array Library >= 188.8.131.52 OpenG Error Library >= 184.108.40.206 OpenG File Library >= 220.127.116.11 OpenG LabVIEW Data Library >= 18.104.22.168 OpenG String Library >= 22.214.171.124 LAVA Palette >= 126.96.36.199 Description:
LabVIEW Task Manager is a debugging tool for use during LabVIEW code development. An expandable/collapsible tree diagram displays detailed information (both static and dynamic) on all VIs in memory, belonging to a selected project/target. It allows for interacting with single or multiple selected VIs at a time, and includes the following major features:
Selection of project/target Lists all VIs in memory, grouped by class/library or disk folder, or a flat list Searches for and enumerates clones in memory DropIn VI for including dynamically referenced clones (Clone Beacon) 'Refresh Now' (F5) re-reads all VIs in memory and adds new ones to the tree Displays VI name, owning class/library, state, path, data size & code size Displays VI FP Behavior, Reentrant?, Reentrancy Type, Paused? & Highlight? Group by Class/Library or Folder, or display a Flat List Sort by any column, ascending or descending Filter out item types vi, ctl, and vit/ctt Filter out vi.lib and global VIs Filter out items from being displayed, per folder paths. Tracking of, and ability to toggle, execution highlighting on multiple selected VIs Tracking of paused VIs with ability to Pause/Resume/TogglePause multiple selected VIs DropIn VI for pausing only while debugging If a clone initiates a pause, a different pause symbol is used for all clones of that same reentrant original VI Select multiple VIs and open or close their FPs or BDs Double Click a VI from the tree to bring the BD (first choice) or FP to front, if already open Select multiple top-level VIs and Abort them Remotely close any VI's Front Panel Installation and instructions:
Cannot abort SubVIs launched from remote VI Server or local Asynch Call By Ref
Hello to all.
I am deploying an executable (not installer) in a target PC with the same programs (labview and toolkits) installed than the development machine.
When I create executable I uncheck the option "enable debugging" (see image below):
** In the image "enable debugging" is checked but I uncheck in my application.
Then I am trying to debug in run time and of course I can not.
I do this to make me sure that the user can not get my block diagram.
But now I realized that in .ini file that Labview creates with executable there are these options:
So if user writes "true" in these options, can they debug in real time and because of that get my block diagram?
Thanks a lot!
I would like to program some little extra functionality to the Blockdiagram Editor. In detail I want to write a tool, that allows me to drag a node over a wire and then automatically inserts it to the wire if it fits (e.g. drag a subVI into an error-wire). I guess I know/can figure out how to write that functionality using VI scripting, but I'm not sure how to implement it to run whenever I edit a VI.
My first approach is to write a simple scripting-VI, that I will run whenever I need the functionality (or just place the exe in autostart). This VI will obtain the reference to the currently active blockdiagram and then uses scripting to move the node into the wire, whenever I drag a node.
But this seems very inefficient, though I know that controlling a drag-operation via VI-Server is inefficient anyway.
My basic question is:
Is there a way in LabVIEW to implement LabVIEW-Written functionality to the whole editor?
So I don't want to activate anything via Right-Click- or Quickdrop-Plugins. It should be a background VI running constantly, or maybe a solution using internal LabVIEW-Events such as starting a drag-operation on the blockdiagram.
It would be great, if anyone can give me hints or maybe even examples for how to solve this. I would be happy about any different ways on implementing the functionality from my first sentence, but basically its not about the functionality itself and more about curiosity on if there is a way to solve it all using LabVIEW. Maybe I want to write different tools as well then.
Thanks for any replies in advance!!
Long time reader, first time poster. I have learned a lot from lavag, and really appreciate what you all do here.
I am building an LVOOP architecture that sort of straddles the line between AMC and AF. One of the most frustrating things I have run across (as with most AF type architectures) is debugging shared clones. I've run into some behavior that I did not expect and wanted to see if anyone knew what was going on. First some definitions:
Behavior A: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the original, "uncloned" VI, reserved for execution. Behavior B: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the active, running clone VI, which is capable of being debugged. I once thought that behavior A was how LabVIEW worked, however in developing this framework, I have found that some subVIs show behavior B. Behavior A and B seem to correlate to dynamic and static dispatch methods respectively, but I can't make sense of why. If I create a simple example without OOP (see attached), I get behavior A.
Has anyone ever seen this behavior, and if so, am I missing something really obvious?
Secondly, does anyone have any tricks or best practices for getting into active clones to debug? My only idea at this point is to include some sort of notifier/queue/etc to active a Front Panel Open Method.
Thanks in advance!
I'm developing an application that uses some PCIe hardware. My daily developing computer is a laptop docked to a dock station. Now, I would like to develop testing my subVIs in the remote desktop that has installed the PCIe hardware. I know I can enable remote debugging, compile and transfer the executable, then execute and connect from my laptop, but this is very inefficient and slow process to test subVIs.
I could install the full development environment in the remote desktop, develop in this machine with remote connection (or even directly on this computer, as it's next to my laptop), but this is not the way I would like to work with every similar project.
Do you have any better approach to debug remote desktop applications? I have heard something about using VI server and executing remote panels or similar, but I have never done such a thing.
Any comment is welcomed.