I've written a labview application that is a test executive linking
datasocket based 'instrument drivers' with excel. I can push ranges of
data around using a small script to create wahtever application type is
needed - logging, dashboard, batch processing of data and so on.
I'm not happy with datasocket- particularly with the fact that
datasocket controls appear as integers when published, making automatic
discovery of type really awkward to engineer.
I'm impressed with 0MQ and interested in the labview binding which no
doubt would be plenty fast enough for my excel-paced executive. I'd
like to hear about any serious applications written with the labview
binding. Is it stable for something that may need to run for months at a
time?
Someone's just given me LabView 2010 at work so I'm going to give some
simple 0MQ patterns a try.
Cheers, Bob, Chippenham U.K.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Bob,
Originally LV-ZMQ was written for just this purpose! While we never got around to implementing it ourselves (still something we dream about), we use LV-ZMQ daily as part of our control and acquisition system (http://www.labscriptsuite.org/). I wrote a package for python RPC from LabVIEW based on ZMQ (http://pybywire.sf.net) capable of transferring data arrays for processing and returning the result. We often run it for weeks at a time without problems (sometimes we must restart for unrelated hardware issues).
I've spent a lot of time working on memory management details to prevent memory leakage at a low level (ZMQ and LV have different garbage collection mechanisms). But provided you stick to the ZMQ paradigms, there shouldn't be any issues. PUB/SUB is a beautiful thing.
Cheers,
Martijn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The latest version of LV-ZMQ is working very well for me. In my Excel based test system, my 'instrument drivers' bind as Routers and my 'test executive' connect as Request. This allows more than one instance of a 'test executive' to make requests on an 'instrument driver'. It works well and seems very stable, so thanks for your work with LVOOP.
I discovered a latent problem with memory leak in the Excel interface I adopted which used an early form of GOOP, so I have to fix that. I need to rewrite using modern OOP.
As a newcomer to OOP, I've been looking at your code. What resources did you use to learn about it? Is the code pure LVOOP or did you use one of the addons like Endevo GOOP to help?
I'm thinking of publishing the test executive as open source like you've done with LV-ZMQ. Any advice on that based on your experience?
Cheers, Bob Edwards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Bob,
Sorry for not replying sooner - I seem to be been missing out on notifications about posts from SF lately.
My experience with LVOOP is mostly based on reading other people's code and adapting the techniques that I like combined with my experience with OOP in other languages. The first LVOOP toolkits I wrote were pretty messy and as a result I like simplicity. Because I don't do anything particularly complex I haven't been using any addons for development. It's not particularly agile when making changes to the API, but for things like this toolkit the underlying API changes slowly anyway.
As for open-source publishing, there's certainly no one way to do it. Pick a service that offers convenient file hosting because VIs are not text-based and that doesn't fit well with many source control/sharing systems. I chose SF at the time because it supported my revision control scheme (hg), provided web hosting, forums and binary releases (which github and friends didn't do a few years ago). Packaging can be a bit of a pain, and while VIPM handles many of LabVIEW's more annoying compatibility problems, it does have its own issues. It all depends on how complex your project is and whether you want it to install and handle dependencies and such. Good luck!
Cheers,
Martijn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've written a labview application that is a test executive linking
datasocket based 'instrument drivers' with excel. I can push ranges of
data around using a small script to create wahtever application type is
needed - logging, dashboard, batch processing of data and so on.
I'm not happy with datasocket- particularly with the fact that
datasocket controls appear as integers when published, making automatic
discovery of type really awkward to engineer.
I'm impressed with 0MQ and interested in the labview binding which no
doubt would be plenty fast enough for my excel-paced executive. I'd
like to hear about any serious applications written with the labview
binding. Is it stable for something that may need to run for months at a
time?
Someone's just given me LabView 2010 at work so I'm going to give some
simple 0MQ patterns a try.
Cheers, Bob, Chippenham U.K.
Hi Bob,
Originally LV-ZMQ was written for just this purpose! While we never got around to implementing it ourselves (still something we dream about), we use LV-ZMQ daily as part of our control and acquisition system (http://www.labscriptsuite.org/). I wrote a package for python RPC from LabVIEW based on ZMQ (http://pybywire.sf.net) capable of transferring data arrays for processing and returning the result. We often run it for weeks at a time without problems (sometimes we must restart for unrelated hardware issues).
I've spent a lot of time working on memory management details to prevent memory leakage at a low level (ZMQ and LV have different garbage collection mechanisms). But provided you stick to the ZMQ paradigms, there shouldn't be any issues. PUB/SUB is a beautiful thing.
Cheers,
Martijn
Hi Martijn,
The latest version of LV-ZMQ is working very well for me. In my Excel based test system, my 'instrument drivers' bind as Routers and my 'test executive' connect as Request. This allows more than one instance of a 'test executive' to make requests on an 'instrument driver'. It works well and seems very stable, so thanks for your work with LVOOP.
I discovered a latent problem with memory leak in the Excel interface I adopted which used an early form of GOOP, so I have to fix that. I need to rewrite using modern OOP.
As a newcomer to OOP, I've been looking at your code. What resources did you use to learn about it? Is the code pure LVOOP or did you use one of the addons like Endevo GOOP to help?
I'm thinking of publishing the test executive as open source like you've done with LV-ZMQ. Any advice on that based on your experience?
Cheers, Bob Edwards
Hi Bob,
Sorry for not replying sooner - I seem to be been missing out on notifications about posts from SF lately.
My experience with LVOOP is mostly based on reading other people's code and adapting the techniques that I like combined with my experience with OOP in other languages. The first LVOOP toolkits I wrote were pretty messy and as a result I like simplicity. Because I don't do anything particularly complex I haven't been using any addons for development. It's not particularly agile when making changes to the API, but for things like this toolkit the underlying API changes slowly anyway.
As for open-source publishing, there's certainly no one way to do it. Pick a service that offers convenient file hosting because VIs are not text-based and that doesn't fit well with many source control/sharing systems. I chose SF at the time because it supported my revision control scheme (hg), provided web hosting, forums and binary releases (which github and friends didn't do a few years ago). Packaging can be a bit of a pain, and while VIPM handles many of LabVIEW's more annoying compatibility problems, it does have its own issues. It all depends on how complex your project is and whether you want it to install and handle dependencies and such. Good luck!
Cheers,
Martijn