Jump to content

Bob Edwards

Members
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

1

About Bob Edwards

  • Rank
    Active

Profile Information

  • Gender
    Male
  • Location
    WIltshire UK
  • Interests
    Walking, Cycling, Reading, Ham Radio, Flying

LabVIEW Information

  • Version
    LabVIEW 2010
  • Since
    2003
  1. 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.
  2. 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 sla
  3. 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?
  4. 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 Wr
  5. 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
  6. 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/controln
  7. 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
  8. 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.
  9. 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 connecti
  10. 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)
  11. 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
  12. 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 t
  13. 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.
  14. 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
  15. 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://
×
×
  • Create New...

Important Information

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