Bob Edwards

Yes, I'm having another go, I've come back to 0mq after a break away from it. The Labview-zmq package is worth another look, the author has revised the interface quite a bit and I suspect this is more stable than it was - less likely to crash the labview development system. Can be found at http://labview-zmq.sourceforge.net/ One of the changes made is the use of labview objects which the author claims has simplified the wrapper between labview and 0mq.

Good to know that NI have been looking at 0MQ et al. Given the useful features M_P describes above and the apparent popularity it seemed a pity that Martijn Jasperse's labview-zmq was languishing. I think he'd enjoy a little fresh input - he's not much time to spare from his day job. Things I like about it for my purpose: well documented api, serverless solution for master - multiple slave, messages not streams, any data you like, fault tolerance, small memory requirement, simple installation of final apps - just two dlls, Ascii based Identities when using the Router socket (for naming slaves) I'd second that 0MQ would make a good open source labview library, especially if alternative (better) binding techniques are possible as the labview language developer. (e.g. event support / development system recovery after 0mq error) Keep the library simple to keep it flexible, with plenty of examples to illustrate the extras 0MQ brings and fire the imagination. Examples make or break adoption I think, especially as 0MQ docs are on the whole good, but lengthy.

Network streams and your dispatcher look good - nice simple apis. Network streams seems to be only 1:1 - isn't a problem. Slave instrument controllers could signal the test exec using UDP (say) for i/o discovery together with two network streams for the data. From the advice above there's two or three candidate comms solutions - I'll prototype and let you know how it turned out. What's the best way of sharing code snippets here?

Shaun, I still think datasocket is 'broken' on this obscure point. It's possible you configured your input string to be a publisher not a subscriber. Labview allows you to do this. To see the effect for sure: - 1. Run datasocket server and open the diagnostics window 2. Search labview examples for datasocket and open 'Front Panel Datasocket read.vi' and 'Front Panel Datasocket Write.vi'. 3. Run 'Front Panel Datasocket read' and check the 'fpwave' variable that appears - on my Win XP machine running Labview 2010 that appears as a blue '2' for integer 4. Run 'Front Panel Datasocket Write' and the new variable changes to the correct type Thats my problem I think - datasocket subscribers don't show as the proper data type until someone publishes data to the variable. This probably has to be - If you create a datasocket subscriber using 'datasocket open' rather than binding a control, that subscriber is capable of accepting any kind of data. I've tried a lot of dodges with datasocket properties, writing data once from inside the instrument control apps etc. but so far they all result in remote inputs being unusable or datasocket misbehaviour. As NI hint that datasocket is non-preferred, I thought it would be better to move on to a comms standard with some life left in it. I'd been looking to adopt something that was cross platform, a lot of language bindings and an active developer group. As has been pointed out, though, adopting third pary carries risks, hence the debate.

The datasocket prototype allowed the user to select using the 'DS select' menu. When test exec script ran, all datasockets were opened and data transfer was by DS Read and Write. Whne the script stopped all sockets were closed. Very simple, if it weren't for the fact inputs don't show up correctly. You try it, put a string input in a while loop. Make sure the input is bound to datasocket. Start datasocket server and run the VI. Open the datasocket server diagnostics. Check the input you've just created. It's shown as an integer not a string. So if another app wishes to discover what datatype that input is, it can't tell. Bah!

Yes you're right, passing around ctrl refs is probably more brittle than using the control names. In the proposed 0MQ solution, when an instrument controller starts, it sends a registration message to the test exec defining the appname and also for each remoteable control: controlname / datatype / direction. So a number of such instrument drivers start and the test exec accumulates a list of this information. The user edits a test script and can select the required control or indicator for data transfer from a tree style menu derived from the list. (He can also type in <appname/controlname>) When the script runs, the 'output' instruction takes data from a defined spreadsheet range and transfers it to <appname> <controlname> The remote apps could pass the ctrl refs to the test exec to store in the same list and the test exec could use those to define where the data is going, but this is just more complex. The control names alone are enough - it's just a string versus an integer.

I'll take another look at Dispatcher, Shaun, I had a brief play with it a while back. Like Jack says, it all depends which is the 'closest fit' to any one requirement. Keeping things native labview would be a bonus. One thing the 0MQ author says might be true Jack - if 0MQ doesn't seem to fit your needs, you may be looking at the requirement from the wrong angle. All the various port type Pub Sub Request Reply Router Dealer and so on can be mixed and matched. There may be an unconvenstional combo that does fit - just a thought. I thought you'd like to hear a little about my application which is a deliberately very simple test exec with all the horsepower that comes with spreadsheets. As such it's relatively slow but pretty versatile: - 1. One or more excel spreadsheets contain data, program logic or analysis logic 2. 'Spreadpump' is a test executive that just moves ranges of excel data around sheets and between sheets and instrument controls and indicators 3. Zero or more instrument control applications that can slave to Spreadpump. The user can name these, so that more than one instance of an instrument driver can used 4. Spreadpump is programmed with around 20 instructions using a table based editor with drop-down user selection where possible so the learning curve is tiny. Includes conditional goto and gosub based on whether a range is all blank or not. 5. 'In' and 'Out' instructions move desired ranges to and from the instrument control apps. A control or indicator is thus defined as <user appname>/<control name>. A range can be one value, 1D or 2D array of one type of data - string, integer, float, boolean. 6. Spreadpump optionally waits for spreadsheet recalc before reading from a sheet. The user can control display refresh to improve speed or hide intermediate states. So each of my instrument apps needs to identify itself as healthy. If I use a 'multipart 0MQ message', the 'identity' feature of 0MQ can be set with the unique app name as a string and id's the sender to the test exec. The 'first message' from any instrument driver would be to tell the test exec the names, control refs, data types and direction for all controls and indicators requiring remote control. Each instrument control app would be fitted with a 'request' port to enable that. The test exec needs to talk with 0-N instrument control apps. The 0MQ 'router' port appears to fill that bill. In any multipart message received, the first part would be the user name for the app, than an empty part, then the data required. If reading from a control, Spreadpump would send a message to the relevent app with the control ref. as data. The remote app would return the data as a variant. Writing to an Indicator, Spreadpump would send to the relevent app the control ref and data as variant. The remote app would acknowledge with maybe just the control ref. The router takes care that the reply returns to the requester. To make sure all apps are still alive, if the remote instrument controllers get sent a 'heartbeat' message, they return the 'first message' again (say) with a timeout in Spreadpump to spot dead links. I haven't completely worked out what happens when things fail, but it's not going to be sophisticated - just wait and retry until the user says stop. It's been working well using datasocket reading indicators from some pretend instrument drivers, but as I say datasocket is quirky in that when an instrument controller published it's inputs, they all appear is integers. That's a bit naff, since Spreadpump can't easily discover what data type to deliver to an input.

The MDI toolkit's ok for local but not distributed. LabbitMQ looks interesting - RabbitMQ has been quite popular. I found nanomsg http://nanomsg.org/ (son of 0mq) but still only alpha so not interesting yet. I wonder if a truly dominant messaging standard will appear in this age of distributed 'things'? We still don't agree which end the MS digit goes half the time. The other issue is 'more complicated' is 'better'. At least I can take 0mq in quickly because the api is tiny.

I hadn't tried transport.lvlib. Will download and see how it compares with 0mq for this application - thanks for the prompt. I want my controller app to be able to detect slave apps by their inputs and outputs a la datasocket, but probably not pubsub. I was going to fit my test exec app with a 0mq 'router' port and the satellite hardware driver apps fitted with a 'request' port. At start up, each driver app would send a 'request' that contained a description of I/O ports to the test exec. The test exec would compile these into a dictionary of possible connections - like the datasocket connection popup. The 'router'/'request' combination allows each driver app to set an 'identity' for itself. The user can then connect to 'frequency in' port of 'siggen 1' and so on from a selection tree. I can see how the conversation would work and that it could recover from a failure of either slaves or exec ok.More labview 0mq examples are needed to illustrate proper recovery from failure and also graceful shutdown. I agree about having it event based.

For anyone who hasn't come across omq before, this book was very useful in getting started. http://zguide.zeromq.org/page:all Yes, between LV and the rest of the world is particularly useful as the safety critical products I'm working around are mainly programmed in C. The number of language bindings for 0mq is impressive. Not something that NI seems all that interested in, which is shame (for us that is)

I've tried datasocket, too limiting. Tcpip - there's got be a higher level than that. Shared network variables - daunting in complexity and still proprietary to NI. I found 0mq or zeromq the other day, which ticks a lot of boxes. I've written an Excel based test executive but wanted a robust and simple interface to control distributed slave instrument apps. It prototyped ok in datasocket if it wasn't for the fact that controls all appear as integers whatever their real type before they are written to. This makes auto-discovery of resources a pain. I don't see any discussion of zeromq on lavag, has anyone got experience of using the labview version - http://sourceforge.net/p/labview-zmq/wiki/Home/ ? It would be comforting to know it had proved to be reliable and scaled ok before spending any more time on it. I'm encouraged by some prototypes i've written for fault tolerance. Would welcome any experience with 0mq and other suggestions for simple networking without going completely back to basics. Cheers bob, uk

Yair - Thanks for the hints. I'd tried converting the MGI 'read/write anything to file' down to labview 7.1. I got a lot of bad vi messages, so I expect it's the new features you mention that aren't backward compatible. I'll look at those vis more closely as to the technique used. Avoiding being locked into 7.1 is a very good idea, though - so I need to be cautious in any bit-banging approach taken. DannyT - I've not come across 'LabVIEW Data (2 of 2) in several searches Ton - thanks for that - I removed the array (as you say it makes no sense) - and your code then produces the cluster, so that would be useful as part of the conversion process.

No, the code is nonsense. It was supposed to (say) allow the user to create a variant containing cluster of numeric, string and binary or any other combination. Instead it produces a cluster of variants.

As usual when you ask a question, you may end up seeing the answer yourself. I wonder if the attached vi is the sort of thing I'll need to do - albeit the inputs are embedded in the adapted 'Universal Probe' as vis pulling the data from excel? Bob Variant at runtime test.vi

I'm working towards a Labview 7.1 app that would be a bridge between Excel and a small network of Labrad test instrument servers ( http://en.wikipedia.org/wiki/LabRAD ). Spreadsheet as general purpose test controller in other words, with program steps stored as excel comments. Labrad supports arbitrarily complex data, described as a string e.g. (b*3s) = cluster of binary and 3d string array. To support this, the labrad interface uses labview variants. It seems logical to stick with variants for the excel interface, to keep it general purpose. By adapting Jim Kring's 'Universal Probe' http://vi-lib.com/news/UniversalProbe-LabVIEWdat.html, I'm able to pass any labview variant into excel. (User layout choices to follow eventually) Anybody any hints on going the other way - assembling the values pulled from excel into a labview variant? Inputs are (1) the labrad string describing the data (2) labview data from the individual spreadsheet cells. Pulling the data out of excel is already working, it's assembling the required variant using a string formula that seems tricky. I suspect the variant will have to be constructed byte by byte - but would some of the openg variant vis help? Being self-taught, the application of some of these is obscure. After cracking this hurdle, I hope to include it in my existing code with an added 'data direction' input. I already know of NI App Note 154, http://openg.org/docs/LabVIEW%20Data%20-%201%20of%202.pdf and the openg variant examples on sourceforge. Cheers, Bob