Leaderboard

LabSocket enables LabVIEW applications to be easily accessed using a web browser, without the need for browser plug-ins or run-time engine on the client. The latest release of LabSocket includes support for Waveform Graphs and Charts, XY Graphs and MultiColumn ListBoxes. An option to integrate LabSocket with the Moodle CMS is available as well. A detailed User Guide and downloadable demo of this release are at: http://labsocket.com/userguide_demo.html. Below is a screenshot of a test VI (left) and its representation in a browser (right). LabSocket-RT, a special version of LabSocket for the LabVIEW Real-Time environment (eg. cRIO), is also available: http://labsocket.com/RT.html. A live demo of LabSocket-RT operating on a cRIO-9025 can be accessed at http://labsocket.com/Demo2.php, until approximately Oct 4. Other links of possible interest: Documentation on a "Remote Cascade Lab" developed by KTH Royal Institute of Technology in Sweden that uses an earlier version of LabSocket: http://www.energy.kth.se/proj/projects/Remote_labs/RL/RL_website/RCL/RCL.html Screenshots of support for MultiColumn ListBoxes: http://labsocket.com/MCLB.html Presentation to Orange County (CA) LabVIEW User Group Meeting titled "LabSocket System - Plotting Capability and Sample Applications": https://decibel.ni.com/content/docs/DOC-30313 Any questions or feedback about the system are welcome. -John Bergmans

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.

http://technet.microsoft.com/en-us/library/cc757323(v=ws.10).aspx

Hi John - I was at the BALUG presentation and was awed by what you've accomplished with this code. Also, the presentation itself was well-organized. Thank you for sharing.

Just came across this port. Sys Eng at NI is interested in zeromq and rabbitmq. We've been playing around with both and are considered making an open source library if it fits a need. One of the SEs even built it for the cRIO-9068 platform for alliance day to talk about reuse on NI Linux RT. Don't count us out yet

Reusable code is the way to go. Here's a meager example:

I've used one ES for UI, and another for dynamic events. But I usually push the dynamic ES down to a subVI.

Hello all. I have an application. This application has an installer. During the install the EXE and the INI file are installed and the EXE uses the INI and can then write to the INI any settings changed in the application. If I have a new version of the application I make a new version of the installer. The problem (if it is one) is that during the install the new INI will replace the old one and all of the old settings will be lost. On the one side this is a good thing. This means that when version 2.0 is installed it comes with an INI file that is compatible with the 2.0 of the EXE and will have known good settings. On the other side this means that if there were any custom settings they will be lost. It is possible to run a EXE after an install, so I was thinking one possible solution could be to backup the old INI (sometime before deleting it) then after the install compare the two and any keys and sections that exist in the old and new INI, to be copied so the new INI has the same settings as the old. Any thoughts on this? Is this a non-issue and installing a new EXE with the new INI is the way to go, with the understanding that old INI settings will be lost? Thanks.