Is it possible to hand control to an external application?

[azhew]

Hi,

 

First, I am new to this forum, and also not so well versed with Labview as others, so please forgive me if this question should be somewhere else, or is not interesting.

 

I am currently developing an imaging system (for my phd), and now that the hardware is almost done, it is time to develop the software ;-)

My system has many detectors that can move, along with other stuff, which allows it to go from one imaging configuration to another (it's an adaptive system, a bit similar to adaptive optics in telescopes).

Ideally, I would like to have a main application to control the hardware in my system, and from this main app, be able to load an external application that will then "take over" the control. By this I mean: the external application should get acquisition data as input (continuously), and send some commands for the hardware as output (continuously, or once, or every minute depending on the situation...), and when it is done, it will end and the main app will again be in control.

The external application could be located on the same computer that controls my hardware, or on another computer, or a cluster of computers... (or the cloud maybe...).

 

Is this something that can be done in Labview? Is there something in what I said that can't be done?

Can someone direct me towards some material I can read about this?

 

Thank you in advance for any help!

 

-cecile

[Rolf Kalbermatter]

Hi,

 

First, I am new to this forum, and also not so well versed with Labview as others, so please forgive me if this question should be somewhere else, or is not interesting.

 

I am currently developing an imaging system (for my phd), and now that the hardware is almost done, it is time to develop the software ;-)

My system has many detectors that can move, along with other stuff, which allows it to go from one imaging configuration to another (it's an adaptive system, a bit similar to adaptive optics in telescopes).

Ideally, I would like to have a main application to control the hardware in my system, and from this main app, be able to load an external application that will then "take over" the control. By this I mean: the external application should get acquisition data as input (continuously), and send some commands for the hardware as output (continuously, or once, or every minute depending on the situation...), and when it is done, it will end and the main app will again be in control.

The external application could be located on the same computer that controls my hardware, or on another computer, or a cluster of computers... (or the cloud maybe...).

 

Is this something that can be done in Labview? Is there something in what I said that can't be done?

Can someone direct me towards some material I can read about this?

 

Thank you in advance for any help!

 

-cecile

 

There is very little you can not do in LabVIEW. But the architecture you describe is not something that will be trivial to build. Are you planning to write your PHD about distributed cloud computing or rather the imaging aspect you described? The system you describe could easily be a whole PHD on its own and then some more.

 

As long as you keep everything in LabVIEW, what you want to do is somewhat manageable but still a big task.Obviously because of your idea about distributed computing you will need to keep its communication network based. A fairly quick and maybe a little dirty approach would be to directly use the VI Server interface, with which you can control local VIs as well as VIs on any other computer that has LabVIEW installed and is accessible through a TCP/IP network connection.

[azhew]

Thank you for your answer.

To be honest, I would like to avoid doing two phds, the hardware is already a big task ;-)

 

But if I don't have time to implement everything myself in the software, I would at least like to plan the architecture so that the next student can build on top of that without re-writing the entire software.

I actually see it as a good opportunity to learn more about labview programming. So I will at least try!

 

I will look into the VI Server interface, thank you.

Ideally, external applications could be written in any language (most likely C or Cuda).

[ShaunR]

I think you will need to scale back your expectations as to what you will be able to achieve for the software aspect. How much time do you have left? I'm guessing that you have spent most of your PHD time creating the hardware and now it's "just a little bit of software to make it work" 

 

 

Remote communications (especially for hardware)  is not a trivial subject but you can get an idea of how you might tackle it (and the complexity) from  XML-RPC Server for LabVIEW or Dispatcher in the Code Repository. There are also examples shipped with LabVIEW to show the basics of client/server communications. That is before we get to actually controlling the hardware. 

 

Personally. If you have experience of text based programming (did you write the firmware?) and are on Linux (which I suspect from the phrasing of the question) then I would use Python.

[PaulL]

As ShaunR and rolfk have already indicated, the architectural questions your requirements derive will require significant understanding to satisfy.

 

In particular, you will need to understand state machines and effective network communication communications.  Part of a good solution may include a publish-subscribe communications paradigm.  (That's what I would use, but I build systems like this all the time.)  You may want to take a close look at which requirements you actually need to achieve.  (Which external interfaces do you really need to support?)  You will likely need to implement this in phases, designing in such a way as to support new features in the future.

[azhew]

Thank you all for your answers and also for the reality check ;-)

 

I think that what I am going to do is develop the software so that the system can be used for routine acquisitions, maybe with the possibility of having an adaptation rule loaded on the control computer, and leave the remote communication part as a "future work".

I do not know how much longer I have for my PhD, but hopefully less than a year (more than 6 months though). I will work on the software this summer while I am getting some big parts machined. I will come back and describe the architecture when it is ready ;-)

 

Thanks for the useful input!

[jcarmody]

Hi,

 

[...] please forgive me if this question should be somewhere else, or is not interesting. [...]

 

Definitely interesting.  Good luck with your PhD.