New release for MSL 3.2.2

[bernhard-thiele]

Make a new new release tested/updated for MSL 3.2.2

[tbeu]

From the open tickets #104 should be solved for a new release.

[bernhard-thiele]

Agree. MoLic2 is fine. Any header that you recommend to use? Possibly the same style you used in MSL?

[tbeu]

Hm, I proposed to license all C/H files under Simplified BSD License.

[tbeu]

You might want to use Modelica_Syncronous v0.92.1 instead of v0.92.

[bernhard-thiele]

Just made a checkout of Modelica_Synchronous and it says version="0.92". So why v0.92.1?

[tbeu]

Modelica_Synchronous v0.92 depends on MSL v3.2.1 and @MartinOtter released v0.92.1 (that depends on MSL v3.2.2).

[bernhard-thiele]

This makes sense, but I don't find the release. To my knowledge the official repo is https://svn.modelica.org/projects/Modelica_EmbeddedSystems/trunk/Modelica_Synchronous and there is the mirror repo at https://github.com/modelica/Modelica_Synchronous

What I can see is that @MartinOtter increased the build number to versionBuild=3 a few days ago, but he didn't change the version number. it is still v0.92 and depends on MSL version="3.2.1". Do I look at the wrong place?

[MartinOtter]

In order to not interfer with OpenModelica (that seems to use trunk), I made a branch at from the trunk. In this branch the uses-annotation is changed to Modelica 3.2.2 and the release notes are updated https://svn.modelica.org/projects/Modelica_EmbeddedSystems/branches/ForMSL3.2.2/Modelica_Synchronous

[bernhard-thiele]

Hm, in this case the trunk doesn't reflect the most recently released version. I guess the idea was that our automated testing will run unaffected. The better solution seems that we adapt our tests.

From my side it's fine if you update the trunk version, I will just update our test scripts afterwards.

[MartinOtter]

Have changed trunk to the tagged version 0.92.1 (merged the tagged version into the trunk and checked that everything is o.k).

[bernhard-thiele]

I just tried it on my computer.
There was a little bug in package.order that I fixed and committed since omc didn't like it.

Besides from that, on my computer it works without changing anything in the testing. We'll see what results the nightly testing on the server will give.

[bernhard-thiele]

Created release 1.4.4

[tbeu]

@bernhard-thiele I am not that happy with the release notes, just stating that v.1.4.4 is a bug fix release. Rather I'd have prefered to list the actual bug fixes, which were quite a lot.
Previously (v1.4.0 in particular) you created a draft release which could be inspected and improved by other contributors? Why did you not this time? Why the rush on a Saturday? You see, even one ticket was forgotten to fix (#110).

[tbeu]

The release notes of v1.4.4 have some strange link to Modelica_DeviceDrivers_v1_4_4.tar.gz in the bullet list. Please revise.

[bernhard-thiele]

I fixed the link in the release note. We can still modify the release notes in README.md or also at v1.4.4. You are right that more things were improved that are worth mentioning, particularly if one considers the intermediate steps from v1.4.0 to v1.4.4.

I did the release today, because I had time working on it and thought it would be a good thing to conclude it. However, I just set the status of the release on "draft" and will update the README.md. So we have some more time to work on this release. Alternatively, we could also just keep the status as it is and go directly to a v1.4.5. What do you prefer?

[tbeu]

Well, it's Saturday evening. I'd prefer to fix the release notes in Readme.md, package.mo and the tag at v1.4.4 and simply retag as v1.4.4.

[bernhard-thiele]

Changed the Readme.md. The latest release points to v1.4.3 again and v1.4.4 has draft status. So I think it is fine to start working on it next week and retag it for the official release.

[tbeu]

Also, MSL 3.2.2 will not be released before April 11th.

[tbeu]

I also reopened the 1.4.4 milestone. Maybe you can set a due date.

[bernhard-thiele]

Okay, might be a bit strange to release a library which declares dependencies to a library that is not yet released. So we should have the official release on the same day as MSL 3.2.2 is released, but finish the release earlier (and just keep the status as DRAFT) so that MDD can be shipped with tools which are released soon and will already include MSL 3.2.2.

[bernhard-thiele]

After some development break, I would like like to continue working at the next 1.4.4 release targeting next Tuesday as official release (hence, after MSL 3.2.2 is released). I probably will create a new draft release tomorrow, which will be basically the same as the current draft release but include the improvements (release notes and #110) that we discussed in this thread.

Could you already check whether the current Draft release works with SimulationX?

[tbeu]

Yes, I can do it.

Please give me some time to inspect the release notes before finalizing them.

[tbeu]

I also propose to remove this "Currently, (2015-09-01)" fromUsersGuide.mo and "currently (2016-04-09)" from Readme.md.

[bernhard-thiele]

OK, I'm fine with having these removed.

[bernhard-thiele]

Just created a new draft that includes all the latest changes. The only thing missing is #110, but we can move that to the next milestone, too? Is there anything left from your side?

[tbeu]

Hm, you reverted some of my latest changes? By purpose or faulty merge?

[bernhard-thiele]

Sounds like a faulty merge. Don't remember to have reverted anything by intention. There was one conflict regarding the release notes that I resolved (we both worked at them at the same time and I rebased my changes on yours). What is missing?

[tbeu]

Hang on, I'll fix it (again).

[tbeu]

Fixed by 8de040a.

[bernhard-thiele]

Thanks. Anything else?

[tbeu]

SimulationX test, hang on.

[tbeu]

Model Code Generation
Warning (Model Analysis): Warning In Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackager:
For the variable "getBoolean.y_int[1]" is no assignment in the initial system. The startvalue "0" is used. Set fixed=true or add an assignment in an initial section
Message: InitialSystem.MissingInitialAssignment

[tbeu]

Model Code Generation
Warning (Model Analysis): Warning In Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackager_UDPAutoBufferSize:
The following when-clauses are part of an algebraic loop. They are evaluated more than once because of the solution algorithm:
when if _addFloat._b then not _pre__addFloat._b else false then
    uDPSend.pkgIn.userPkgBitSize=-1;
    uDPSend.pkgIn.autoPkgBitSize=0;
    uDPSend.bufferSize=Modelica_DeviceDrivers.Packaging.SerialPackager_.getBufferSize(packager.pkgOut.pkg);
end when;
when if _addFloat._b then not _pre__addFloat._b else false then
    packager.backwardPropagatedBufferSize=if addFloat.pkgIn.userPkgBitSize>0 then div(7+addFloat.pkgIn.userPkgBitSize,8)else div(7+addReal.pkgIn.autoPkgBitSize,8);
    packager.bufferSize=packager.backwardPropagatedBufferSize;
end when;
when if _addFloat._b then not _pre__addFloat._b else false then
    addReal.pkgIn.autoPkgBitSize=192+8*div(7+addReal.pkgOut.autoPkgBitSize[1],8);
end when;
when if _addFloat._b then not _pre__addFloat._b else false then
    addFloat.pkgIn.autoPkgBitSize=64+8*div(7+addFloat.pkgOut.autoPkgBitSize[1],8);
end when;
when if _addFloat._b then not _pre__addFloat._b else false then
    addInteger.pkgIn.autoPkgBitSize=32+8*div(7+addInteger.pkgOut.autoPkgBitSize[1],8);
end when;.
Message: Modelica.WhenInAlgebraicLoop

[tbeu]

Model Code Generation
Warning (Model Analysis): Warning In Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackager_SerialPort:
The following when-clauses are part of an algebraic loop. They are evaluated more than once because of the solution algorithm:
when if _addInteger._b then not _pre__addInteger._b else false then
    serialSend.pkgIn.userPkgBitSize=-1;
    serialSend.pkgIn.autoPkgBitSize=0;
    serialSend.bufferSize=Modelica_DeviceDrivers.Packaging.SerialPackager_.getBufferSize(packager.pkgOut.pkg);
end when;
when if _addInteger._b then not _pre__addInteger._b else false then
    packager.backwardPropagatedBufferSize=if addString.pkgIn.userPkgBitSize>0 then div(7+addString.pkgIn.userPkgBitSize,8)else div(7+packInt.pkgIn.autoPkgBitSize,8);
    packager.bufferSize=packager.backwardPropagatedBufferSize;
end when;
when if _addInteger._b then not _pre__addInteger._b else false then
    packInt.pkgIn.autoPkgBitSize=packInt.width+packInt.pkgOut.autoPkgBitSize[1];
end when;
when if _addInteger._b then not _pre__addInteger._b else false then
    addString.pkgIn.autoPkgBitSize=8*addString.bufferSize+8*div(7+addString.pkgOut.autoPkgBitSize[1],8);
end when;
when if _addInteger._b then not _pre__addInteger._b else false then
    addInteger.pkgIn.autoPkgBitSize=32+8*div(7+addInteger.pkgOut.autoPkgBitSize[1],8);
end when;.
Message: Modelica.WhenInAlgebraicLoop

[tbeu]

This one is really bad.

Error
Time: 0 s: In TestSerialPackager_SharedMemoryExternalTrigger assert failed: true != false assert(0)

Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackager_SharedMemory works as expected.

[tbeu]

That's it then: 2 different warnings and one assert/error with SimulationX 3.7.2.

[bernhard-thiele]

Okay, thanks for checking.

Are these newly introduced problems or problems that we had already for the previous releases?

[tbeu]

Not sure at all. Diagnostics of SimulationX is getting better.

[tbeu]

I guess they all can be fixed.

[bernhard-thiele]

Yes, but maybe as goal for the next release. This will need some more investigation, e.g., is it a bug in the library or a bug in the tool, how can we work around... Don't get any complains by Dymola for the failing example (but of course, that doesn't automatically mean that it is correct Modelica...).

[bernhard-thiele]

I think it makes sense to have a dedicated ticket for these results. We could call it SerialPackager isues?

[tbeu]

OK, the Modelica.WhenInAlgebraicLoop is related to autoBufferSize=true. Hence, skip it for now.

At least the Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackager_SharedMemoryExternalTrigger should be fixed then. Need to check why Modelica.Blocks.Logical.ZeroCrossing fails.

[bernhard-thiele]

Hm, I just tried find an assert() that could potentially fail, but didn't find it. Guess you have a better insight to this error. The model is quite similar to the UDP variant of external triggering (TestSerialPackager_UDPExternalTrigger), except that it uses state events instead of time events to trigger the instantaneous equations.

[tbeu]

Can only check TestSerialPackager_SharedMemoryExternalTrigger tomorrow.

Meanwhile I was thinking how to proceed with this library. Here is my proposal to finally gain Modelica compatibility for #73.

• Remove Comedi from library because of Modelica compatibility: Construction of external objects is not allowed in records #93 and probably not easy to fix
• Redesign Serialpackager. The autoBufferSize = true is nice and should be kept as default. However the calculation of the buffer size is non-standard Modelica. The idea how to resolve the issue is in http://www.ep.liu.se/ecp/118/046/ecp15118427.pdf, section 3. The packager creates the SerialPackager external object where the bufferSize of each added buffer is found by hidden inner outer constructs and inherited connects. This would mean there can only be one inner packager per model (that still could create an array of external objects using array connectors).
  @bernhard-thiele @tbellmann I would need your commitment that you really care about it and not just postpone the improvements to any time in future. We tackled MDD_socketCANRead not in compliance with MLS #71 and I am confident that we also are able to finally resolve Github project description #73. This even would make the library working in OpenModelica.

[MartinOtter]

Please, do not make such drastic non-backwards compatible changes. There are organizations, especially DLR that use this library. DLR developed this library and we need to clarify the library officers that make the final decisions, and cleary someone from DLR must be part of this group. If you need such drastic changes, copy the library, rename it and do with it what you want.

[tbeu]

TestSerialPackager_SharedMemoryExternalTrigger looks like a tool issue. Still investigating...

[bernhard-thiele]

I have finally released the library and created ticket #112 for discussing issues regarding the SerialPackager (have seen too late that you are still looking into the issue, if it turns out to be not tool issue we will tackle that for v1.4.5).

Thanks to everybody for the good discussions and the coding efforts leading to many improvements for this release!

[tbeu]

TestSerialPackager_SharedMemoryExternalTrigger looks like a tool issue. Still investigating...

Closing remark: Can confirm that it really was a tool issue that is fixed for upcoming SimulationX 3.7.3. Thanks for your patience!