.. _xmera-known-issues: Xmera Known Issues ===================== Version 2.3.0 ------------- - A bug was introduced at 2.2.1 (2dc0a35) to the :ref:`SimulationBaseClass` `AddModelToTask` function when it was refactored to use the updated module variable logging. The bug manifests as no data being logged for a variable when there are more than one task, a module in each task, and the variable being logged is from a module assigned to a task added to a process after the first task has been added to a process. - Doing a clean build on Windows appeared to complete, but when running python simulation scripts, errors came up about not finding Xmera packages. The python version number checking on Windows had an issue that is now corrected in the current build. - ``swig`` 4.2 was causing run-time errors with Xmera. The latest version of Xmera now added support for this version of swig. - Xmera no longer builds on Windows with the ``opNav`` flag turned on. The ``opencv`` related ``conan`` settings are updated in the current release to address this. Version 2.2.1 ------------- - There was an issue with :ref:`thrusterStateEffector` where if there are multiple instances of the thruster state effector then the last effector will over-write all the state of the earlier thrusters. This is corrected in the current release. - Doing a clean Xmera build with `opNav` flag on fails building openCV. The conan install script is updated this is corrected in the current release. - We found a slow memory leak if messages with arrays or vectors were accessed from python. The ``swig`` issue has now been fixed in the current release. - The :ref:`facetSRPDynamicEffector` module was double counting a cosine term in the SRP force calculation. This is corrected in the current release. - The :ref:`facetDragDynamicEffector` module was missing a negative sign in the drag torque calculation. This is corrected in the current release. Version 2.2.0 ------------- - VizInterface has been updated to use 4.5.0 version of ZMQ library. Be sure to use Vizard 2.1.5 or newer. Version 2.1.7 ------------- - The way to include effector bodies in Vizard has changed in this release. - The streaming between ``vizInterface`` and Vizard was not reliable because of a ZMQ compatibility issue between the two code bases. xmera is reverting to using ZMQ 4.3.0 for now to avoid this issue. - Building Xmera with ``opNav`` mode was no longer working as a conan package dependency issue came up. This has been corrected in the new version by specifying ``xz_utils/5.4.0`` in ``conanfile.py``. Note that building with ``opNav`` now also appears to require ``conan>=1.59.0``, but less than 2.0.0. Version 2.1.6 ------------- - in :ref:`boreAngCalc`, the variable ``boreVecPoint`` is now called ``boreVec_Po``. Version 2.1.5 ------------- - In Xcode, when editing ``vizInterface.c/h`` files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn't work in that module. - :ref:`hingedRigidBodyStateEffector` and :ref:`dualHingedRigidBodyStateEffector` module inertial state outputs are relative to the central gravity body, not the inertial frame. This is now corrected. - Adding an instrument camera to :ref:`vizInterface` has changed. See :ref:`vizardSettings` on how to use the new method ``addCamMsgToModule()``. Version 2.1.4 ------------- - In Xcode, when editing ``vizInterface.c/h`` files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn't work in that module. - prior version had a bug in computer the latitude in ``PCPF2LLA()`` inside :ref:`geodeticConversion`. This is used in the ``specifyLocationPCPF()`` method inside :ref:`groundLocation`, and in :ref:`msisAtmosphere` and :ref:`albedo`. - :ref:`coarsesunsensor` now receives in ``sensorList`` a list of CSS configuration state pointers, not a copy to the configuration structures. This allows these values to be changed on the fly from within python. However, the simulation code must ensure that the CSS configuration structures are retained in memory or a segmentation fault will ensue. - How stand alone C-wrapped message objects are created in python has moved from ``cMsgCInterfacePy`` to ``messaging``. Old scripts still using ``cMsgCInterfacePy`` still work as a link has been created to ``messaging``. But, the use of ``cMsgCInterfacePy`` is no depreciated and code should be updated to using ``messaging`` instead. - The use of custom message in the external modules folders is broke with the new build modification in this release. This is fixed in the latest release.