Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/29/2014 in all areas

  1. I found the solution! I tried to delete the topic, but I cannot. Anyway the problem was associated with Streams Names, which should be unique. Till you are using streams in LabView there is no need to build "Stream Name" as full URL, "ni.dex://host_name:context_name/endpoint_name". Context_name is optional when Streams works in LabView, but it's necessary to have this name when you are building exe files. The context_name is the name that identifies which application context the endpoint resides in. If somebody need more info, everything is here: http://www.ni.com/white-paper/12267/en/
    1 point
  2. Hi all, one way to avoid rotating the buffer and still be able to use the Array Subset Node is the following: allocate a buffer twice the size the user requested apply writes to buffer also to buffer[usersize + i] use Array Subset Node to return any contiguous part of the buffer very efficiently as a contiguous subarray Another interesting possibilty is to calculate certain figures like average or standard deviation directly when inserting/deleting elements instead of fetching the whole buffer everytime you need that figure. Regards, Sebastian
    1 point
  3. I don't have a lot of details to share, but in the past i have specifically looked at the 0MQ labview driver for interfacing labview components with Nodejs. Since both languages are currently supported, it provided an easy, turn key method for passing data without having to develop the communication protocol from scratch. However, given the that labview implementation of ZeroMQ does not currently support VxWorks this was a dead end for me as i was really hoping to use NodeJS and the browser as the front end for my CRIO interfaces. If the 0MQ library could be updated to support VxWorks i thi
    1 point
  4. Been there, done that. I have G implementations of ZMTP (at least most bits I need) and AMQP (0.9.1 not the 1.0 trainwreck). I tend to use AMQP most often since my code is more complete (and there was more adoption of it when I wrote it), but they are both great. The brokerless nature of ZMQ can be great when you need it, turns out most times I was implementing a de facto broker and could have stuck to AMQP. Unfortunately the specs are really laid out seductively in terms of classes and methods so I gummed up the works by using a bit too much LVOOP (not to mention busted my carpal tunne
    1 point
  5. I'm particularly looking into this (I'm also known as MattP on the NI forums, I work in the SE group like GoGators). From my perspective, it fills a gap that was partially filled by the AMC library (using same API for inter-loop and inter-node communication), network streams (automatic reconnect in background abstracted from the read/write, good performance), and shared variables (the pub-sub use case). What it handles better, IMHO, is that it handles not just the reconnect, but also the initial connect and intermediate send/receive queues entirely asynchronously. It also easily handles
    1 point
  6. ØMQ is on my radar, and a few other's (we can talk about it offline, but I'm not ready to endorse it publicly). I can say, I'm eyeballing ØMQ as a particularly intriguing solution for actor-oriented design (and generally, distributed messaging) both in LV and between LV and the rest of the world.
    1 point


×
×
  • Create New...

Important Information

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