Jump to content
OpenSplice DDS Forum

James Butcher

  • Content Count

  • Joined

  • Last visited

About James Butcher

  • Rank

Profile Information

  • Gender
    Not Telling
  • Company
  1. Hi Yes I heard from engineering that the above is valid, but of course PrismTech will be fixing it properly in a future release so the workaround won't be necessary. cheers James
  2. Hi, Thanks for raising this. I've reproduced it and am talking to the PrismTech engineering team about it. For now, I got it to compile by changing the command to "Marshal.ReadInt32(attr2Seq0Buf);" Are you able to use that as as workaround for now? Obviously it's a bit awkward cos it's generated code. I'll check whether that's actually a valid workaround, and of course make sure the generated code is fixed in a future release. Thanks James
  3. Hi John It looks like you've done everything right in the build process. I suspect it to be an issue with the network interface configuration. See the post here: http://forums.opensplice.org/index.php?/topic/2842-communicate-betwwen-different-subnets/ Hope that helps, James
  4. Hi, No I don't believe there is a pre-existing port of the community edition for aarch64. It could be done of course, or PrismTech could no doubt provide a supported port for the full version of Vortex OpenSplice. Contact PrismTech if you would like to discuss cheers James
  5. Hi Andoni Did you get this working? If you do want to work with multicast, maybe check that the network interface has multicast enabled? Also if the machines have multiple interfaces check that the right one is being selected. See <NetworkInterfaceAddress> in the DDSI2Service part of the XML config where you can set that. James
  6. Hi Jon Yes, in the isocpp2 API you no longer need to register the type explicitly. The templated nature of the API allows for the type registration to be done implicitly. In your code: dds::topic::Topic<M> myTopic(myParticipant, "topic name", myTopicQoS) M is the fully scoped name of the structure which will be registered within the call. i.e. if you have a module it would be mymodule::mystruct etc I wonder if the issue is with the qos provider or not. To help narrow it down you could try removing the myTopicQoS parameter. isocpp offers nice overloading where a lot of the parameters are optional. Also check the ospl-info.log and ospl-error.log for clues cheers James
  7. Hi Shankara I see you are calling "read" without any restrictions on what samples are seen - i.e. LENGTH_UNLIMITED with ANY_SAMPLE_STATE, ANY_VIEW_STATE & ANY_INSTANCE_STATE. That will mean that the read operation will be returning an ever growing list of samples. Users typically use "take" to pull samples from the reader cache, or if they do use "read" change the ANY_SAMPLE_STATE to NOT_READ_SAMPLE_STATE so that they see different samples each time. When you are say "not all samples are received" do you mean there are missing samples in the middle, or does the data flow stop? If you switch to RELIABILITY::RELIABLE, the writer operation will return TIMEOUT in the case that it wasn't able to deliver the sample. Are you seeing that? Best Regards, James
  8. Hi Loay Quick question - have you set OpenDDS to also use Domain number 223? The port numbers that are used are derived from this number so it must be the same on both sides Also check that the right network interface is being selected on both sides. Wireshark should confirm that James
  9. Hi Loay That's good news. In the first instance you were linking both -ldcpsisocpp and -ldcpsisocpp2. It should be only one or the other. I think shapes on 6.7.1 uses -ldcpsisocpp BR, James
  10. Hi Loay I'm just reading over this and I do think this is an environment run-time issue rather than something to do with Qt5 since DDS libs are independent of that. For simplicity I suggest staying with the default "single process" XML configuration for now - at least while you get the compatibility sorted. So all you need to do is ensure the release.com is sourced (i.e. setting OSPL_HOME and OSPL_URI). Can you output the environment here after doing that please, e.g with "env". Can you also try running the examples "as is", i.e. before any use of Qt. You are using OpenSplice 6.7.1 but which OpenSplice target build are you using? It looks like the software downloads page provides only ubuntu 14 builds at present. Perhaps the issue is more to do with compatibility on Ubuntu 16 rather than Qt, which is why running the examples normally (with the OSPL environment correctly set) is a good first step BR, James
  11. Does everything work when it is just Java to Java, and/or just C++ to C++? i.e. do you think it is an interoperability issue? What structure are you sending?
  12. Hi The DDS middleware takes care of the serialization & de-serialization within its linked libraries - and that is specific to each target platform. I believe that the code generated from the IDL is the same whether you use idlpp from a 32 or 64 bit version of OpenSplice, but the librarires/dlls that are linked into the applications do need to match the target platform. i.e. if you are running a 64 bit C++ application, you need to run it with the 64 bit version of OpenSplice. Hope that helps James
  13. Hi Jon, I'm not sure that was a good idea, but I guess explains the difference in one working and the other not I would expect that symbol would be in the ddsos library, can you check that is being linked in? I'm not familiar with using gcc (is that via cygwin or minGW?) on windows but I guess it has been working ok because you got the initial application to run successfully. nm is the gnu tool for showing symbols James
  14. Hi Jon Yes it does sound likely to be an environment issue. Is it the same version number of (the open source?) OpenSplice on both machines? Can you do a windows "dumpbin /EXPORTS" command to verify that the os_reportVerbosity is defined in one of the libraries or source files. Maybe you could paste the link line and the error in full? cheers James
  • Create New...