string inputs to external object constructor

[Volker Waurich]

Hi,

String arguments to external object constructors are usually handled like this:

static const MMC_DEFSTRINGLIT(tmp0,11,"stringinput");
data->simulationInfo->extObjs[0]  = omc_ExtObj_Name_constructor(threadData, MMC_REFSTRINGLIT(tmp0));

if the actual external constructor call is reached,it gets as an input

MMC_STRINGDATA(_inputArgument)

These macros put the string in some data structure. The MMC_STRINGDATA does bitshifting to reach the original string.

This is the case for simulation. In FMU-Generation, the original string reaches the constructor call without being transformed to some other structure. Anyway, the bit shifting using MMC_STRINGDATA is applied and hence the string argument to the constructor is incomplete.

So simulation needs the MMC_STRINGDATA call and FMU-generation does not.

How should this problem being adressed? Shall we check if an FMU
should be generated and decide in the template call whether to set the macro or not? Or can we leave these macros at all? (I have no overview where these things are necessary)

Thanks.

[Martin Sjölund]

What code in FMUs get this code? All Modelica function calls take strings and all strings in the simulation must use mmc_mk_scon or similar to box the argument. Where is this not performed?

[Volker Waurich]

Use the model from #4062 with:

translateModelFMU(MDD_test, version="1.0", fmuType="me"); getErrorString();

I end up with a runtime error:

MDDSerialPort.h: CreateFileA of serial port OM3 failed with error: 2

Which should be "COM3"
See attached file for more details.

[Volker Waurich]

The attached file was wrong, Iv found the mmc_mk_scon. The runtime error appears anyway.

[Martin Sjölund]

So the problem is with start-values in FMUs, I guess?

[Volker Waurich]

In MDD_test_callExternalObjectConstructorsdata->simulationInfo->stringParameter[0]gets in the constructor, which is "COM3". After calling MMC_STRINGDATA(_deviceName) only "OM3" is left.

[Volker Waurich]

I think I found it,
​https://github.com/vwaurich/OMCompiler/commit/889d1e8b23100046d6fe0e13f90c60dde0c813b7

[Volker Waurich]

For DAE.SCONST inputs to external constructor calls, it works fine. For DAE.CREF inputs of type DAE.T_STRING, we miss a mmc_mk_scon() call. The cref is generated by
CodegenCFunction.tpl ::daeExpCrefRhs. I do not know which template I should change to generate a mmc_mk_scon() call of a cref. The templates to generate crefs are used frequently and adding mmc_mk_scon-call breaks the codegeneration. I could implement various cref-template functions to bypass the ordinary templates for the concrete situation, but I dont like to add so many functions for such a special case. As a workaround for my model, I will evaluate all parameters and leave this topic open for discussion.

[Martin Sjölund]

CREF does not need any mmc_mk_scon call (bootstrapping works just fine after all). Which variable does not work for you? (with your commit, COM3 is passed just fine, but then seg.faults due to COM3 not being available on Linux)

[Volker Waurich]

In MDD_test_01.exp.c :: MDD_test_callExternalObjectConstructors I get data->simulationInfo->stringParameter[0] /* serialReceive._Serial_Port PARAM */ as an input. This is forwarded to MDD_test_functions.c :::omc_Modelica__DeviceDrivers_Communication_SerialPort_constructor and then put in the constructor:

MDD_serialPortConstructor(MMC_STRINGDATA(_deviceName),...

data->simulationInfo->stringParameter[0] is "COM3" and MMC_STRINGDATA(data->simulationInfo->stringParameter[0]) is "OM3"

[Martin Sjölund]

That works just fine with your commit 889d1e and becomes COM3. I get the following printed just fine:

assert            | debug   | MDDSerialPort.h: open(..) of serial port COM3 failed (No such file or directory)

I guess the problem is simply that the start-value is not boxed when it is put into the data structure (it is already boxed at that place in the C runtime, so you need to fix it sooner in the FMU code; I can look for the place).

[Volker Waurich]

Oh..misunderstanding. The commit fixes the problem but breaks other tests. So I thought I need something different. But if you say that this fix could be valid, I will take a closer look at the broken test.

[Martin Sjölund]

The problem is in CodegenFMU.tpl: ScalarVariableTypeFMU. I'll fix it :)

[Martin Sjölund]

The value in there seems to be ignored by some other FMI function. It's rather messy and I guess I won't be able to find the cause :(

[Volker Waurich]

Shall we check whether the inputs to the constructor are constant and if not, output a warning or even evaluate all constructor inputs by default?

[Martin Sjölund]

We shouldn't need to. I think we have use cases for constructing external objects depending on parameters.

This should not be a problem that is only true for external objects, but also more general models, right? Although that warrants testing :)

[Volker Waurich]

Another attempt to fix this: ​812cfc6

[Volker Waurich]

If there are no opposite views, the issue is fixed and I will close the ticket.