Jump to content
OpenSplice DDS Forum

All Activity

This stream auto-updates     

  1. Last week
  2. In OpenSplice the typename you pass to the register_type operation is only used inside the participant itself to locate the the meta-data given the type_name parameter of your create_topic operation. However, in the builtin topics the IDL name is always advertised, regardless of the type_name you specified in your register_type call. This is to avoid two applications compiling the same IDL but using different type_names from not being able to communicate with each other. The IDL typename used in the builtin topic is always fully scoped, using the IDL scoping operator "::". So interopeability with other vendors is going to be hard if you do not pick the IDL type name when registering your datatype.
  3. Hi Luca, When using header files from only include/dcps/C++/SACPP (in other words, you are using the Classic StandAlone C++ API) you should link to only libdcpssacpp and libddskernel.so. When you are using header files from the new C++ API (include/dcps/C++/isocpp2, keeping in mind that include/dcps/C++/isocpp is deprecated) you link to only libdcpsisocpp2.so and libddskernel.so. Regards. Erik Hendriks.
  4. The problem seems not to be in the include guard, because A.idl, B.idl and C.idl are all compiled independently. It is at link-time that you run into this issue since each compiled object file now has the same symbol. I will look into a way around this, but in the mean time you might want to circumvent the issue altogether by getting rid of the anonymous sequence, by putting a typedef in the file that hosts your T_IdentifierType type, and then referring to that typedef from A.idl, B.idl and C.idl. So as an example, let F.idl look like this: struct T_IdentifierType { T_Int32 A_resourceIdentifier; T_Int32 A_instanceIdentifier; }; typedef sequence<T_IdentifierType> T_IdentifierTypeSeq; And then use a reference to T_IdentifierTypeSeq in your other IDL files instead of using anonymous sequences there.
  5. Earlier
  6. Well it was my first tought but it indeed has the include guards. the other strange thing is that only those 2 would cause me trouble and not the other struct that were declared pretty much identically in those LDM_Common.IDL Plus I did not wrote those IDL files, and I'm 100% not allowed to touch them or modify anything with them. I must do with whatever was given to me. Anyway I solved my probleme by editing the generated h files and putting all the declaration of those problematic functions as inline. Not pretty but it will do the trick untill I find a more elegant solution that does not require me tinkering with those generated files.
  7. Looks like you are trying to use the GVA/LDM IDL files. Could the problem maybe be that the LDM_Common idl file is missing include guards?
  8. sure that would be the definition of struct T_IdentifierType { T_Int32 A_resourceIdentifier; T_Int32 A_instanceIdentifier; }; this definition is found in a IDL file that is included in all my other IDL files. This strutc type is also used in all my other IDL files. the problems appear to be with the __alloc and _alloc function of the DDS_sequence for that type. in all of my *Dcps.h file that I got i have these lines that were generated : DDS_sequence_P_LDM_Common_PSM_T_IdentifierType *DDS_sequence_P_LDM_Common_PSM_T_IdentifierType__alloc (void); P_LDM_Common_PSM_T_IdentifierType *DDS_sequence_P_LDM_Common_PSM_T_IdentifierType_allocbuf (DDS_unsigned_long len); #define P_HUMS_PSM_C_Monitored_Entity_sequence_P_LDM_Common_PSM_T_IdentifierType__alloc DDS_sequence_P_LDM_Common_PSM_T_IdentifierType__alloc #define P_HUMS_PSM_C_Monitored_Entity_sequence_P_LDM_Common_PSM_T_IdentifierType_allocbuf DDS_sequence_P_LDM_Common_PSM_T_IdentifierType_allocbuf and this is exactly what poses problem. Is there a way to regenerate those file without those multi-inclusion trouble or do I have to go and try to find a manual correction ?
  9. Hi Everyone, I'm having the same problem and I realized I'm also linking both libraries. Our OSPL.xml is configured to run in single process, and we use the header files from include/dcps/C++/SACPP. I assume that therefore the right library to use is libdcpssacpp.so. Could someone please confirm this? Is the library libdcpsisocpp.so meant to be linked when using header files from include/dcps/C++/isocpp(2)? Thanks in advance, Luca
  10. Hi, It might be an issue with anonymous types (that are deprecated in IDL 3) .. could you share an example that exhibits the issue ?
  11. HI, I have multiple IDL files, lets says A.idl, C.idl D.idl, and all of these IDL have the same F.idl included at the top. I have run the IDL preprocessor n all those files for a C standalone exit and do have all my *.c and *.h file. The probleme occurs when I try to complie those .c and .h file I got a linker error dure to multiple declaration of type that where in the F.idl. Howerver those .c and .h files seems to have multi-inclusion protection written by the preprocessor but they seem not to work at compilation. Is there any way to generate those *.c and *.h file all together so the preprocessor implement working multi-iclution and multi-definition protection or do I have to try and correct them manually ?
  12. Hi Jan-Marc, Unfortunately not: you have to specify a list of peers, either by address (as you've done here) or by name. Note however that 'your own address/name' may be part of that list thus allowing the same config-file to be applied to every machine in the system.
  13. Hi Hans, when not using multicast, I've to define a set of 'peers' as automatic discovery doesn't work. As far as I know each IP address must be specified individually; e.g .: <DDSI2Service name="ddsi2"> <General> <NetworkInterfaceAddress>AUTO</NetworkInterfaceAddress> <AllowMulticast>false</AllowMulticast> <EnableMulticastLoopback>false</EnableMulticastLoopback> <CoexistWithNativeNetworking>false</CoexistWithNativeNetworking> </General> <Compatibility> <!-- see the release notes and/or the OpenSplice configurator on DDSI interoperability --> <StandardsConformance>lax</StandardsConformance> <!-- the following one is necessary only for TwinOaks CoreDX DDS compatibility --> <!-- <ExplicitlyPublishQosSetToDefault>true</ExplicitlyPublishQosSetToDefault> --> </Compatibility> <Discovery> <Peers> <Peer Address=""/> <Peer Address=""/> </Peers> </Discovery> </DDSI2Service> Is it also possible to specify an IP address range? Best regards, Jan-Marc.
  14. I'm not aware of a 'special editor', guess you could use any editor you like .. What we use ourselves are a bunch of 'best-practices' captured in such QoS-profiles that 'capture' different 'kinds' of data such as telemetry, state and/or events. Here's for instance our 'telemetry' profile (typically used to distribute periodic digital-samples of the analogue world): telemetry.xml
  15. Hi Hans, thank you for your hint. In the meantime, I also found it ... In the source code I also found some XML files where QoS policies are defined. Also, I found the schema file "DDS_QoSProfile.xsd". Is there a special editor for QoS profile files? Best regards, Jan-Marc.
  16. I suspect you'd be happy with our 'qosProvider' API:
  17. In my DDS applications (which use the same data model) the QoS policies are set in the program code. The applications are written in C ++ and use the "ISO / IEC C ++ 2 DCPS API". The data model is written in an IDL file used by all applications. In contrast, the QoS policies are set individually in the applications. However, this often leads to inconsistencies regarding the QoS policies (QoS mismatching). Is there a way to describe the QoS policies in a separate file (for example XML file)? I know, that the ability to use XML to configure DDS QoS was standardized by OMG as part of the "DDS for LwCCM" specification. Or is there another way to define the QoS policies in a coordinated way for all applications? Best regards, Jan-Marc.
  18. I realise that editing the output of idlpp isn't the correct thing to do but I just wanted to try and see if it'd work. I have a publisher (which I don't have the source code for) that has a type of parentModule.childModule.structAType (sorry, I can't post the actual type) and a topic of structA. I've generated code using idlpp from the given idl (which does have :: in it). When running the subscriber (without editing) it has a type of parentModule::childModule::structAType and I'm giving it a topic of structA, but when I publish I receive nothing in the subscriber. They're on the same domain. I thought that changing the type to be the same would fix it (hence why I edited the output of idlpp) but that just gives me the aforementioned ospl error.
  19. editing output of idlpp is generally a bad-thing to do so I doubt that anybody else has experienced that same issue. I'm trying to understand what you'd like to achieve .. is it about modules in the IDL (and related 'fully-qualified-type-names that migh have ::) ? Otherwise, if its about topi-names, those can't have a '.' in them.
  20. Hi, I am trying to subscribe to a publisher whose type name is formatted as "a.b.c" and written with RTI but when I try to replicate the '.' instead of '::' in opensplice I get an error when trying to create the topic. Has anyone tried this before? Is it even possible with opensplice? A bit of background: I've generated the files from the .idl and have changed the '::' to '.' in the generated Xsacdcps.c file to no avail. The error is that the type is not found. The type is registered without an errors; the retcode is OK. Thank you.
  21. As far as I know you can't get the exact glibc version used while building a library. You can get the ABI version (try ldd -v -r) which provides exactly the info you need to determine if it is compatible with the glibc installed on a particular machine.
  22. Hi Hans! Thank you for your hint. I already knew the use of "ldd". However, it only indicates that "libc.so.6" is used and from which directory; but not which version of "libc.so.6" was used during the build! I was hoping that maybe a define or an entry would be created during the build process. For explanation: The "OpenSplice Run-Time-System (RTS)" can be easily installed by only unpacking the installation archive. Unfortunately there is no check if the installed RTS is compatible for the respective node! How could this be checked? Best regards, Jan-Marc.
  23. if you do an 'ldd' on for istance $OSPL_HOME/lib/libspliced.so you'll get something like this: hansh@perf2:~/ADLINK/Vortex_v2/Device/VortexOpenSplice/6.9.181127OSS/HDE/x86_64.linux/lib$ ldd libspliced.so linux-vdso.so.1 => (0x00007ffd1c702000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00002ae91a668000) libddskernel.so => /work/hansh/ADLINK/Vortex_v2/Device/VortexOpenSplice/6.9.181127OSS/HDE/x86_64.linux/lib/libddskernel.so (0x00002ae91aa32000) /lib64/ld-linux-x86-64.so.2 (0x00002ae91a22f000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00002ae91ae09000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00002ae91b112000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00002ae91b316000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00002ae91b533000) would that be helpful ?
  24. I want to check (on Linux) if the OpenSplice RTS libraries are executable on the node. For that I would like to compare the version of "glibc" installed on the node with the version of "glibc" used to build the libraries. If the versions differ, the DDS application should output a corresponding error message. How can I find the version of "glibc" used to build the OpenSplice RTS libraries? Does the meta configuration file "ospl_metaconfig.xml" contain a relevant entry? For any hint I would be very grateful! Jan-Marc.
  25. Hi Jan-Marc, Thats 2 questions applications can exploit KEEP_ALL writer-history QoS setting which allows them to specify a timeout on the ability to 'get rid of their data' (i.e. to get notified of such a timeout when blocking on a high-watermark) the WHC settings can NOT be influenced by API-functions (as the whole point of DDS is to 'shield' applications from those underlying network intricacies) but you CAN choose to change the (default) settings (of a 100 kb watermark) like this (see 'Watermarks' section): <DDSI2Service name="ddsi2"> <General> <NetworkInterfaceAddress>AUTO</NetworkInterfaceAddress> <AllowMulticast>true</AllowMulticast> <EnableMulticastLoopback>true</EnableMulticastLoopback> <CoexistWithNativeNetworking>false</CoexistWithNativeNetworking> </General> <Compatibility> <!-- see the release notes and/or the OpenSplice configurator on DDSI interoperability --> <StandardsConformance>lax</StandardsConformance> <!-- the following one is necessary only for TwinOaks CoreDX DDS compatibility --> <!-- <ExplicitlyPublishQosSetToDefault>true</ExplicitlyPublishQosSetToDefault> --> </Compatibility> <Internal> <Watermarks> <WhcHigh>800 kB</WhcHigh> </Watermarks> </Internal> </DDSI2Service>
  26. My statement was about not being able to support TRANSIENT/PERSISTENT data in your system once you remove all durability-services. It indeed doesn't impact TRANSIENT_LOCAL data-distribution. So whereas using TRANSIENT_LOCAL data in your (current) applications is a 'local decision', not having any durability-services configured is more of a 'global decision' for the whole system. I've also checked with the durability-exports on the cause of that warning and that's typically related to high network-latencies (i.e. like in a WIFI) network that's not anticipated by the durability-service's internal protocols do decide who is the 'master' to provide late-joining applications with TRANSIENT/PERSISTENT historical data. We've introduced an alternative to that 'majority-voting' that can be easily enabled by adding the 'masterPriority="1"' attribute in the durability-configuration: <Policy alignee="Initial" aligner="true" durability="Durable" masterPriority="1" nameSpace="defaultNamespace"/> Here's a complete ospl_sp_ddsi.xml that includes that setting ospl_sp_ddsi.xml
  1. Load more activity
  • Create New...