Jump to content

Search the Community

Showing results for tags 'message'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • 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


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

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Personal Website

Company Website

Twitter Name

LinkedIn Profile

Facebook Page



Found 5 results

  1. I'm looking for a Node Map tool to document my applications using my messaging architecture. I want to write some code that can extract relationships between classes (some being processes and some being messages) and then feed that data into a tool to visualize the relationships in my application. The end goal would be something like the http://www.visualthesaurus.com/. Unfortunately, the software behind that tool starts at $5k. I am hoping to find something a bit less expensive. Has anyone found a solution they like? thanks, -John
  2. 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 way communication channel via VI server and can pass any message object back and forth without polling. I learned today that our IT department plans to block all incoming connections to all non-server machines in the future. So, my client would still be able to connect to the server app within the network, but the server would not be able to connect to the client app because of this rule. This will completely break my networked messaging system. I do not know a way for LabVIEW to setup VI Server so only one end can connect to the other but allow two way communication without polling. Does anyone use a message system that would work in my situation? I would prefer to continue to use VI Server but I am willing to look at other solutions, as long as they were very robust and had low latency. thanks in advance for you help. -John
  3. 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 that route!).
  4. I am trying to solve a bit of a chicken-egg issue with my message system. Since I think this would apply to any message system, I would like to hear how others have addressed this issue. In my message system, each parallel process has a message handler loop that receives and executes messages. A process can also have code that runs in parallel with the message handler to implement additional functionality, such as a UI loop that handles events. If an error occurs in this UI loop, it sends the error to its message handler. The message handler then executes the message with the error information, outputting the error as if it happened within the message loop. This then propagates to an error handler that executes specific error handling code for that process and then sends the error info to an error logger process. I also have implemented a broadcast message to shutdown the application. This sends the shutdown message to all processes at the same time. The problem I am running into occurs if an error is generated in the UI loop when it tries to send the shutdown message. That error is not getting handled. This is because the message handler gets the shutdown message before the UI loop has a chance to send the error data. So, there is nothing listening to the error message. And even if it was still listening, the error logger process has also already shutdown so the error would not be logged either. So, any ideas on how to solve this? How do you deal with this in your messaging systems? thanks for the feedback, -John
  5. 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 was wondering if anyone had any ideas for a work around. Here is a basic description of my architecture: Message is created and sent to local VI that sends to outside application instance. Local sending VI opens VI server connection to remote instance. It then calls a VI in the remote instance that takes the message as input. This remote VI them places the message in the appropriate queue on the remote instance so it gets handled. If the remote instance root loop is blocked, the sending VI on the local machine is also blocked. I could try to eliminate all system dialogs from the remote application, but that only partially addresses the issue. I really wish a future version of LabVIEW would eliminate this problem with the root loop and VI Server all together. BTW: using LV2012 but this issue exists in all versions. -John
  • Create New...

Important Information

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