John Hughes (aba8d445) at 11 Feb 13:13

I would like to encourage you to get listed on the FMI tools page https://fmi-standard.org/tools/, see https://github.com/modelica/fmi-standard.org/blob/main/CONTRIBUTING.md#updating-the-tools-list for hints. Thanks for this open source project!

https://github.com/modelica/fmi-standard.org/pull/582

Thanks for this crate! I have been using it's FMI 2.0 support in my Rust projects. I was wondering what your plans are with respect to supporting FMI 3.0. I noticed that initial work has started in the fmi3 branch.

Are you planning on bringing FMI 3.0 support to this project? Does the fmi3 branch already support a subset of the standard? What steps would still need to be taken implementation wise to get to a fully supported FMI 3.0 implementation?

Hi @nielsmeima, I've migrated rust-fmi from Gitlab over to Github, and in the latest release I have added support for FMI3.0. github.com/jondo2010/rust-fmi

John Hughes (90aebc85) at 03 May 13:27

In the implementation of callback_logger_handler, we reuse the va_args twice, one time to compute the length, the other to produce the string.

But this is not allowed, we need to either switch to vasprintf (but it seems to be Linux only) or to do a copy (either by using va_copy or by reinitializing the va_arg, that's what is done in this CL)

This used to display the wrong thing, and could cause a crash in some case

In the implementation of callback_logger_handler, we reuse the va_args twice, one time to compute the length, the other to produce the string.

But this is not allowed, we need to either switch to vasprintf (but it seems to be Linux only) or to do a copy (either by using va_copy or by reinitializing the va_arg, that's what is done in this CL)

This used to display the wrong thing, and could cause a crash in some case

John Hughes (00a89dc9) at 03 May 13:15

... and 1 more commit

Looks good 👍

Hi @tinou98, thanks for the PR! Definitely looks like an improvement. In particular, I never fully fleshed-out the CoSim stuff, so this is a good step in that direction.

So I dug in and did some additional testing over the last week, and I think there's something wrong with your FMU. I don't have a native Linux machine available to test, but was able to cross-compile and test in Docker using the fmi_check utility in the repo. The FMU initializes, but segfaults inside do_step().

I also re-built and tried out FMUs generated from the master version of OpenModelica on Mac and was able to get things to work.

Finally, I made some small fixes here that prevent a possible panic in the logging callback, and makes the importer look for the shared library in the same places that FMILibrary uses.

John Hughes (918c10d7) at 02 Apr 11:38

Hi! Interesting failure. Based on your first error, it looks like the FMU is logging a NULL message to the callback_logger_handler, which isn't currently handled graciously. What are you using to build your FMU? Would it be possible to share it with me?

John Hughes (e63c7d42) at 13 Mar 20:44

John Hughes (dd5ad503) at 13 Mar 20:44

... and 1 more commit

Hi, happy to hear this crate is still getting some use. I started playing around with the FMI3 stuff a while ago, there's quite a bit of work left to getting the XML to fully parse, and I didn't even start on the ffi portion. Curious what your use case is? I don't have access to a commercial Dymola license since quite a few years, and it looks like OpenModelica doesn't yet support FMI3.0.