OMG Data Distribution Service (DDS)

[Daintree]

Engineers that work for me are current LabView users, but I am not, and they have not been ble to answer a query I have about datasockets, shared variables and DDS.

We have been investigating use of the OMG Data Distribution Service (DDS) for a system that will need to integrate LabView, C++ and Java applications, a Microsoft Access database and possibly other third party software. It appears that RTI have a DDS interface for LabView and that NI supported its development in some way and that integrating the other applications and database with DDS would be relatively simple.

I am told by our main LavbView engineer that shared variables are now the preferred method of passing data around a LabView system rather than datasockets which are currently used in a large LabView application we are upgrading and maintaining for a client.

From my quick discussion with our engineer it appears that shared variables and DDS are quite similar but that DDS has some advantages that make it a better choice than shared variables for the system in question. My questions are:

1 - Does NI see a future for DDS in the LabView world?

2 - If so what would be the relationship between the shared variables and DDS?

3 - If not is there an alterantive to shared variables that offers some of the features of DDS such as no single point of failure and QoS?

[Kilometers]

1+2- I can't answer anything about possibilities for future features in LabVIEW. If you would like your voice to be heard on this you can post on the LabVIEW Idea Exchange here, http://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas . We do pay attention to this when we're looking into new features for future versions of LabVIEW especially ideas that have received a lot of attention.

3- I'm not familiar with DDS. Could you give some more information about your application and what kind of benchmarks your looking for? You can find a lot of information on the options for network communication in LabVIEW and their specifications in this white paper https://www.ni.com/en/shop/labview/using-the-right-networking-protocol.html . 

I hope that helps.

[Daintree]

Miles,

Thanks for the response.

The fact you can't answer questions 1 and 2 gives me the information I was expecting.

DDS is a messaging bus that provides very good capabilities and real-time performance. We prefer to use DDS because it is used by some allied projects that are not LabView centric and from what I have read the shared variable paradigm is not what we are looking for and we also want to avoid directly using socket connections at the application level.

Richard

[Ronald_RTI]

Hello Richard,

My name is Ronald and I am with RTI. As the white paper Miles referred to pointed out, there are many ways to communicate and the best protocol depends on the use case. Have you tried the RTI DDS LabVIEW Add On yet? We offer free evaluations for the product. Feel free to send me an email at ronald@rti.com, and I would be more than happy to assist you further. 

Best regards,

Ronald

RTI

Product Manager

[Daintree]

Hi Ronald,

I assume you read my original post and the LabView DDS implementation I referred to was in fact the RTI one you mention.

The client system in question has a lot of LabView applications that currently use 'data sockets' to communicate which creats a spider web of connections and means that the applications need to know about system topology. I would like to convert the communication to DDS which notionally at least removes vendor lock-in allows other non-LabView applications to be easily integrated, eliminates, at least in our case, the need for knowledge of system topology and offers better performance that I suspect the LabView offerings can provide.

The problem is the system is evolving slowly over time and a change from a LabView supported technology to a technology such as DDS not actively supported by NI would be seen as revolutionary and I doubt funding would be provided to enable the transition. The people that make the funding decision are not technical so they will rely on the technical people most of whom are hardware rather than software engineers who think LabView is all there is. This is good for NI but actually inhibits the implementation of worthwhile enhancements to this system.

If NI had come back and said something like "We understand DDS and intend to support the technology in the long term through a third party package from RTI" then we could make a case to the client's technical people that using DDS is better than using data sockets or shared variables. Without that sort of support the NI shared variable option will be the winner but given my understanding of how it is actually implemented I am not convinced it can provide the performance, scalability or features required of this system into the future wheras DDS does. 

In summary, I would be happy to try the RTI offering for a client demo but doubt anything will come of it for this project. We are experimenting with DDS for use on projects that if they eventuate will be C++/Java based and therefore more receptive to such ideas.

Regards,

Richard

[Kilometers]

Hi Richard,

I just wanted to let you know my response before was meant to be entirely neutral. This type of messaging bus may or may not be a part of NI's Future, but I am not the one who can tell you that. I'm an Applications Engineer who's happy to support you if you have any questions specific to your current application. As for questions about the future of National Instruments this would be a question for R&D or Marketing, but that's not the type of thing they would announce on the forums. I'm sorry I won't be able to give you a definitive answer, but as I said earlier if you have specific thoughts on avenues NI should pursue, the idea exchange would be the place to go to try and rally people behind your idea. 

[Daintree]

Miles,

Thanks. I understood your response was neutral and the fact you couldn't say DDS is a currently supported technology confirmed what I thought: we would have a hard time convincing the client to use DDS instead of an existing supported NI technology for reasons of risk and cost.

My explanations in the earlier posts weren't meant to be a rant against NI and LabView or trying to convince NI to support DDS in future. I actually quite like LabView and it is certainly the right tool for many projects. I was just trying to explain the situation we are in and the problems we face.

There is already a third party DDS interface for LabView which we can use if we can convince the client to do so, so I don't need to rally support for anything further from NI.

Thanks for you help.