Leaderboard

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/

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

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 think that would fill a gap for interfacing NI hardware with other software options. I had not yet looked at RabbitMQ as this was a quick side project. As a side note, i have been able to use low level TCP functions to facilitate nodejs to labview communication but as i mentioned it wasn't implemented as well as the ZeroMq library.

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 tunnels). Performance is ok, but as I de-LVOOP it is finding another gear. I create worker pools consisting of simple LV workers and similar C++, Java, or Python workers and see what share each worker does. LV is behind, but getting up there with the big boys. The LV9 to LV12 performance kick was also welcome here. The AMQP implementation gave rise to one of my new mantras: No LVOOP in a loop.

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 N:1 or 1:N using several different transports. It's not so much the base set of patterns that are useful, but the combinations of them that perrmit complex problems to be solved with very small quantities of efficient code. Me likey. Currently I don't see support for ZMQ on VxWorks, which makes usage on cRIO rather tricky, and I know it hasn't been tested on Pharlap but 'appears to work.' I'm contemplating either liberally borrowing the design philosophy of ZMQ for my own comms framework (which would not be easily usable with non-NI tools but would permit NI-specific transports such as FPGA DMA FIFOs), attempting to port and test the C source over to VxWorks, or possibly to attempt a full ZMQ implementation in native LV code.

Ø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.