Jump to content

Search the Community

Showing results for tags 'remote'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Software & Hardware Discussions
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • OpenG
    • GCentral
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help

Categories

  • *Uncertified*
  • LabVIEW Tools Network Certified
  • LabVIEW API
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
  • LabVIEW IDE
    • Custom Probes
  • LabVIEW OOP
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Company Website


Twitter Name


LinkedIn Profile


Facebook Page


Location


Interests

Found 7 results

  1. 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
  2. ShaunR's recent topic on Security reminded me of a situation we explored in the summer and need to revisit at some point. We were looking for a method to protect the communication with a cRIO. The situation is that we need to communicate between a cRIO and a host on an unsecured network (manufacturing environment.) We concluded that we needed some form of encryption as well as a standard login mechanism but identified that having a single symmetrical key would not provide enough protection (for various reasons and specific use cases.) Therefore, we looked into SSL and LabVIEW Web Services because it already includes that library and all the security features that we need. We figured out that it would definitely offer the protection required but that would mean rewriting most of existing code to use Web Service instead or establish some for of communication through a new Web Service. Considering the amount of unknown and risks associated with modifying our code, we looked into an alternative and came up with the following scheme: In short, we would use a Web Service for the initial login and create a new symmetrical key which would be passed to the host and to the main application on the target (cRIO) and would be used to encrypt/decrypt all data during the session. This way, we could still program all of our code in LabVIEW and easily download/deploy the services and applications to the Target using NI standard tools but benefit from proper security and only have to add fairly simple wrappers to some sections of our existing code. I wonder if anyone else has already gone down that route to add protection to an existing application. Would you suggest a different implementation method or an easier path to a similar result? Is there some obvious pitfalls in this approach that we do not see?
  3. Wezarp allows a software application to be controlled by a remote device such as a tablet, a smartphone or a computer. The first release of our website www.wezarp.com is now online !!! Wezarp for NI LabVIEW is available... Don't hesitate to download and try the 30-day free trial version ! Here is a video demonstration on how to use Wezarp with NI LabVIEW
  4. 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.
  5. I have developed VI using data socket for 2 PC communication.It runs fine if both VI are on same PC .But not run when both VI are in different PC.. Look at my attached VI and data socket server manager setting... Defaulreader = everyhost Defaultwriters =everyhost creators =everyhost Untitled 1.vi Untitled 2.vi
  6. Hypothetically, if one created a LabVIEW executable that used a remote application reference to interact with the LabVIEW IDE, how much of the scripting function set would work? I've already discovered "New VI" doesn't work, but what about the non-creative functions, such as programmatically showing a block diagram, traversing the block diagram, inspecting nodes and other objects etc.? It seems to me that it should be ok to perform inspection, just not manufacture, right? So why are a load (if not all) of the scripting methods denied when attempted from a remote interface?
  7. Hi..my name is Sarat Paluri..did anyone work on doing remote access of experiments.I am presently working on the stress analysis of a cantilever beam.Can anyone please help me if they have worked before on this.
×
×
  • Create New...

Important Information

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