Jump to content

Search the Community

Showing results for tags 'network'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Software & Hardware Discussions
    • LabVIEW Community Edition
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • GCentral
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
    • OpenG
  • 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 10 results

  1. Name: Transport.lvlib Submitter: ShaunR Submitted: 27 Aug 2011 Category: Remote Control, Monitoring and the Internet LabVIEW Version: 2009License Type: Other (included with download) Transport.lvlib is a LabView API to simplify and accelerate networked communication development. It simplifies development by abstracting TCPIP, UDP and Bluetooth and TLS interfaces into a single polymorphic vi which is a thin wrapper around the conventional open, read, write, close and listener VIs for all the network interfaces. Features: Supports TCP/IP, Bluetooth, UDP (p2p, broadcast and mul
  2. I am running into an issue where my VI Server connection goes stale after a few hours. Looking for a fast way to detect this and recover. Currently here is what I am doing: On first call, open the application reference and then open the VI reference. Cache both of these. Use the VI reference to call the remote VI. On subsequent calls, test the cached references to verify they are still valid and then call the remote VI. What appears to be happening is the references still appear to be valid in the caller but the connection is broken so the remote call fails. Then I det
  3. Attached is my VI for writing a tiny HTML file to a intranet network directory. This is on Windows for writing to a file path like \\foo\bar\wtf.html (fictional!). But when the network is slow (quite often) the file write will fail. I've got a patch in there so survive the error and just wait till next time. But what really I need is a way to tell the write to hang in there longer and not give up just because there's no reply yet. My temporary work-around is to open a Windows file browser to that path, the twiddle my thumbs until the file list populates. Then, the path being establishe
  4. Hi, I'm wondering whether there is a way to monitor the SVE (or single processes/variables) on a per-client basis. The purpose of this would be network diagnostics or access control. I know the DSC module allows logging of data and events for shared variables, such as the very handy "value changed" event, but they contain no client-related information (to my knowledge), such as the client name or IP address. Are there any other shared variable events besides the value changed notification (e.g. "variable accessed"), which I have missed? Anyway, the SVE seems to be aware of clients, bec
  5. I need to find a transport for message objects that allows two way communication without polling but is limited to server side connections only. So, the client can connect to the server but the server cannot connect to the client. First some context: My application communicates over the network using VI Server. My client app (the UI) opens a ref to a VI in my server app (the engine) and sends a message object containing the client app’s machine name and VI server port. The server app then opens a ref to a VI in my client and sends a message object with the reply data. I now have a two wa
  6. Has anyone used LapDog to pass messages across a network? In my case I'm thinking of an RT system controlled from a Windows computer. The only similar feature I've seen is in the Asynchronous Message Communication Reference Library - has anyone already added something like that to LapDog? I just didn't want to spend too much time developing something that's already available. I haven't used either AMC or LapDog extensively before, but my impression is that LapDog gives a little more control and flexibility. (And the Actor framework perhaps a little too much, as a poor reason for not going
  7. I have been working on an architecture that uses VI Server to send messages between application instances, both local and across the network. One of the problems I have run into is the fact that VI Server calls are blocked by activity in the root loop (sometimes referred to as the UI Thread). There are several things that can cause this: other VI server calls, system dialogs (calls to the one and two button dialog functions), if the user drops down a menu but does not make a selection... (I'm sure there are more...) Since this is a pretty normal way of communicating between applications, I
  8. I am designing a method for multiple application instances to coordinate an action across a network. I have previously implemented this using queues for coordination of asynchronous VIs within a single application instance. I now need to make this work across a local network. I have been looking at network shared variables, network streams, TCP/IP, UDP. I would like to know if anyone else has accomplished this and what you learned along the way. The basic requirements are: N number of independent applications need to coordinate some action (essentially a rendezvous). No one application
  9. Hi everyone, I'm wanting to open up the floor for your opinions and past experiences with designing a network communications architecture. - There will be one server, written in LabVIEW on a Windows based PC. - There will be multiple remote clients programmed in LabVIEW on cRIOs. - All devices will be connected via a wireless network, and all cRIO clients should have good throughput to the server. - It should be designed for bidirectional data flow, however the clients will do most of the talking. - Data sent will be, status packets, images, PDF documents, and other information. - Clien
  10. Hello everyone, My project: We have 2 PXI-RT communicated by 2 connections: a fiber optics connection (not Ethernet), and an Ethernet connection. The FO connection is the main connection used to wsend a receive data. The Ethernet connection is only use when the FO connection is lost, in order to check if the "mute PXI" has lost the FO connection but is still on, or if the PXI has been switched off. The problem: Originally we used the "RT Ping controllers.vi" on the "Real-Time Utilities", but unluckily we changed the PXI controller and the new one is not supported by the library. The main
×
×
  • Create New...

Important Information

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