Jump to content

Recommended Posts

Hello,

 

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.

Thank you.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By TimVargo
      View File LabVIEW Task Manager (LVTM)
      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:
      Dependencies:
      GPower Error & Warning = 1.2.0.14 lava_lib_tree_control_api >= 1.0.1-1 NI SmartBalloon = 2.0.0.2 OpenG Application Control Library >= 4.1.0.7 OpenG Comparison Library >= 4.0.0.3 OpenG Array Library >= 4.1.1.14 OpenG Error Library >= 4.2.0.23 OpenG File Library >= 4.0.1.22 OpenG LabVIEW Data Library >= 4.2.0.21 OpenG String Library >= 4.1.0.12 LAVA Palette >= 1.0.0.1 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: 
      Install this tool by using the VI Package Manager to install its associated package file (.vip). Installation requires VIPM 2014 or higher, which is available for free from jki.net (http://jki.net/vipm). Invoke the LVTM tool from your dev environment menu: Tools > LAVA > LabVIEW Task Manager Known Issues:
      Cannot abort SubVIs launched from remote VI Server or local Asynch Call By Ref Submitter TimVargo Submitted 07/01/2014 Category LabVIEW IDE LabVIEW Version    
    • By TimVargo
      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:
      Dependencies:
      GPower Error & Warning = 1.2.0.14 lava_lib_tree_control_api >= 1.0.1-1 NI SmartBalloon = 2.0.0.2 OpenG Application Control Library >= 4.1.0.7 OpenG Comparison Library >= 4.0.0.3 OpenG Array Library >= 4.1.1.14 OpenG Error Library >= 4.2.0.23 OpenG File Library >= 4.0.1.22 OpenG LabVIEW Data Library >= 4.2.0.21 OpenG String Library >= 4.1.0.12 LAVA Palette >= 1.0.0.1 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:
      Known Issues:
      Cannot abort SubVIs launched from remote VI Server or local Asynch Call By Ref
    • By ASalcedo
      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:
      DebugServerEnabled=False
      DebugServerWaitOnLaunch=False
       
      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!
       
       
    • By parth
      hello all,
      Firstly I am very new to labview so i apologise in advance if i ask some stupid questions.
      i am running a vi on my rio ( simple analog in/out express vi s) and another vi on my PC. i am communicating between them through shared variable and it works perfectly, only thing is i have to manually run both vi s.
      my question is, is there a simple way to start the vi on myrio from the vi on my PC? 
      PS:- i tried to work with vi server but i failed because of my limited knowledge. 
      any help will be much aprreciated.
      Thanks & Regards,
      Parth
    • By dterry
      Hello All, 
       
      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!
       
      Drew T.
      CLA, CTA
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.