Present library at modelica.cz

[tbeu]

I believe it is worth to present the recent features and release at modelica.cz - the upcoming Modelica Conference in Praha. The last paper was from 2009 and since then we have put a lot of new features and fixes (for Modelica and tool compatibility) into M_DD that are worth a new article. Additionally, we figured out the trouble-makers (in the library, I mean).

@bernhard-thiele Would this be fine for you? Would you find the some time to contribute before the submission deadline Dec 30, 2016?

@vwaurich Would you help to contribute (either on article or feature support for #116 or improved OM compatibility)?

Thanks for your feedback!

[vwaurich]

Sounds good. If I have some spare time, I will check the bluetooth stuff.

[bernhard-thiele]

It's a very good idea, indeed.

A good reason to invest some additional effort into it and possibly also to develop a little demonstration that beefs up the story. We just ordered some Arduino and Raspberry Pi boards in order to play with them in the context of code generation. Maybe this can be connected. There now has been progress, particularly thanks to @vwaurich, to improve OpenModelica support for MDD. Hence, MDD will work on two platforms and with three tools. That would make a good message worth spreading in a Modelica paper.

[tbeu]

@bernhard-thiele @vwaurich Thanks for your positive feedback. Here's my first proposal. Please comment on it or edit it.

Add the TeX sources in Resources/doc/Modelica2017 for shared access.

Working titel: Towards a standard-conform, platform-generic and feature-rich Modelica device drivers library

Structure

1. Introduction @bernhard-thiele
   • 1.1 Background / History
   • 1.2 Similar projects
     • UDPLib
     • TCP/IP in AixLib (RWTH-EBC/AixLib#149)
     • modelicaSocketExample
     • ModelPlug
2. Enhanced Modelica standard compliance @bernhard-thiele @tbeu
3. Enhanced tool support @vwaurich @bernhard-thiele @tbeu
4. New features
   • 4.1 Big endian (#66) @bernhard-thiele
   • 4.2 Serial port on Win (7717f0cb67b691b462c4e071d9c610e4399ba3e1) @tbeu
   • 4.3 TCP/IP client (#78) @bernhard-thiele @tbeu
   • 4.4 LCM / UDP Broadcast (#115) @tbeu
   • 4.5 Bluetooth (#116) @vwaurich
   • 4.6 MQTT (#130) @tbeu @vwaurich
   • 4.6 More ideas to come @vwaurich @bernhard-thiele @tbeu
5. Open issues and pitfalls @bernhard-thiele @tbeu
   • 5.1 Serialpackager (#112)
   • 5.2 Automatic buffer size (https://github.com/modelica/Modelica_DeviceDrivers/issues/107#issuecomment-208516979)
   • 5.3 External objects in equation (mo:#1669, #122)
   • 5.4 Construction of external objects in record (#93)
   • 5.5 Linking to platform-dependent system libraries (mo:#2104)
   • 5.6 Missing fixed attribute for String (mo:#1797)
   • 5.7 Support of several include directories (mo:#2103)
6. Application examples @vwaurich @bernhard-thiele
   • 6.1 Arduino
   • 6.2 Raspberry Pi
   • 6.3 HID Joystick
7. Outlook @vwaurich @bernhard-thiele @tbeu
8. Acknowledgements

[bernhard-thiele]

The proposed structure should be a good start. Additional features that should be worth mentioning in (4.):

• Keyboard, UDP, Joystick, Space Mouse and shared memory was mentioned in the old paper, but it was Windows only. Having it cross-platform is new (and for some of these blocks also the Windows implementation changed considerably).
• Softing CAN bus (Windows),
• SocketCAN (Linux)
• Comedi interface (Linux, http://www.comedi.org/)
• Serial port on Linux and Windows

Of course, some of these are not cross-platform, but I think this could be discussed in "Open issues and pitfalls". Also, real-time execution/simulation might fit somewhere within the structure.

[tbeu]

Should I push the template structure to a modelica2017 branch?

[bernhard-thiele]

Yes, probably good to have it in its own branch

[tbeu]

@bernhard-thiele @vwaurich The proposed paper is automatically built with every git push to branch modelica2017 and available from drone.io.

@casella The official ModelicaConference2017-pdfLaTeX-template.zip from https://modelica.org fails to build with ! Package keyval Error: hidelinks undefined. on legacy Ubuntu 12.04. See bd59b6a0150bb0726d1c106eba631562fee2c9c1 for a fix that worked for me.

[tbeu]

@bernhard-thiele Can we speak of a v1.5.0 release (with backward-compatible new features) that will be available just before MoCo 2017?

[bernhard-thiele]

@tbeu Yes, we should manage this.

[bernhard-thiele]

@casella @tbeu I updated the latex template. Seems like the hidelinks option was added 2011, so it should be available on most installations. Anyway, I changed it now for better compatibility with legacy installations.

[tbeu]

Seems like the hidelinks option was added 2011

Yes, that is what I also found. Ubuntu 12.04 uses TeXLive 2009.

[bernhard-thiele]

I asked @sjoelund whether he was interested in helping with the paper and the application examples and was very happy that he was positive about it.

This is a perfect fit since he is leading our ARM code generation experiments for the Raspberry Pi and is also responsible for the recently added OpenModelica real-time synchronization feature. I will work with him at the application examples and other things. Together with the help of @vwaurich this now becomes an excellent opportunity that all necessary parts of OpenModelica can be targeted to get better support for MDD, something which is on my wish list since quite some time :-).

[tbeu]

@bernhard-thiele Can you please update the above article structure with respect to the authors. Thanks.

[tbeu]

Just saw https://github.com/vesselEfficiency/vesselEfficiency-0.1 which utilizes the UDP send feature (to LabVIEW) of M_DD.

[tbeu]

Edited 5.5 and 5.7 in the above structure proposal to point to the newly created MLS issues mo:#2103 and mo:#2104.

[bernhard-thiele]

I contacted @tbellmann and talked with him about the paper effort. I'm now happy that he will join this article effort, particularly by contributing a project application example from DLR and also by writing about the historic background in the introduction.

I updated the latex sources.

• I changed to the up-to-date Modelica Conf. Template
• I added all authors including their affiliation (please check it)
• I started with a tentative structure similar, but also a bit different to the one above. This is of course not fixed and I expect that it will be adapted during the writing process
• I also added who is tentatively responsible for which sections. Also this is of course not fixed.

I will put some more work into the draft and related tickets at the weekend.

[tbeu]

When checking the pdf from drone.io, I noticed that

• There is some problem with ö in your commit.
• @vwaurich's PR #157 has now merge conflicts.

[bernhard-thiele]

Merged #157. Didn't know that you have set-up a drone.io process for it. I changed \usepackage[utf8]{luainputenc} -> \usepackage[utf8]{inputenc}, which seems to work for the drone.io latex configuration (https://drone.io/github.com/modelica/Modelica_DeviceDrivers/files).

[tbeu]

@bernhard-thiele @vwaurich The proposed paper is automatically built with every git push to branch modelica2017 and available from drone.io.

[bernhard-thiele]

FYI: I started with the abstract and introduction (9be142bedf617dc79eeb0442a286173b8d486340)

[tbeu]

FYI: I updated the drone.io commands to build the article with every git push independent of the branch. Hence:

The proposed paper is automatically built with every git push and available from drone.io.

[tbeu]

@bernhard-thiele The starting period in .Blocks or .ClockedBlocks looks somewhat strange as it might indicate a fully qualified identifier. I propose to get rid of these starting periods.

[bernhard-thiele]

@tbeu Just merged your changes, but now pdflatex doesn't compile it anymore due to "\footnotemark[\ref{tmw}]" construction. I will try for quick fix

[bernhard-thiele]

I just merged the initial AVR support (#169) from @sjoelund and opened issue #170 for it. This feature is related to the application that we plan to describe.

[tbeu]

@bernhard-thiele I would not use relative time spans (like "recently") in the article. Better refer to an explict version, like OMC 1.11 Beta 1, M_DD 1.5.0 or absolute dates (like 2016).

See https://github.com/modelica/Modelica_DeviceDrivers/blob/modelica2017/Modelica_DeviceDrivers/Resources/doc/Modelica2017/modelica2017_Modelica_DeviceDrivers.tex#L171 and https://github.com/modelica/Modelica_DeviceDrivers/blob/modelica2017/Modelica_DeviceDrivers/Resources/doc/Modelica2017/modelica2017_Modelica_DeviceDrivers.tex#L201 for the lines I mean.

[tbeu]

@bernhard-thiele I do not like the direct addressing of the reader in "Notice that ...". Was it copy/pasted or by design?

[bernhard-thiele]

@tbeu relative time spans like "recently" should be clear to the reader to refer to the time of the writing of the paper. Referring to absolute dates would be possible as well, though I'm not convinced that the reading flow necessarily gets better by this. Regarding the use of "Notice that". It was not a copy/paste mistake and it is a matter of taste. At this particular position I agree that it will read nicer without it and I will change it.

[tbeu]

Just as an idea for checking the reading flow. If you like it I can add it.

Currently Microsoft Windows and Linux are supported as main platforms, but recent prototypical work also targets popular embedded systems boards directly (see Section~\ref{sec:EmbeddedControl}).

As of MDD v1.5.0, Microsoft Windows and Linux are supported as main platforms, but prototypical work also targets popular embedded systems boards directly (see \cref{sec:EmbeddedControl}).

and

Initially, the library was developed using the Dymola tool. Later, considerable development efforts have been spent for supporting the library also within SimulationX and very recently also within OpenModelica.

Back in 2009, the library was developed using the Dymola tool. With MDD v1.4.0, considerable development efforts have been spent on the Modelica compliance of the library in order to better support SimulationX and OpenModelica on Microsoft Windows. Since OpenModelica 1.11 Beta 1 the MDD Communication blocks are finally supported by OpenModelica.

(As a note, v1.4.0 also brought support for the MinGW toolchain.) (As a second note, we might point to https://openmodelica.org/newss/176-december-1-2016-openmodelica-1-11-beta1-released in a footnote.)

[bernhard-thiele]

The above reads well, except that I would leave out mentioning Microsoft Windows. OM runs on both, Linux and Windows and the restriction to Windows is confusing at this place:

Back in 2009, the library was developed using the Dymola tool. With MDD v1.4.0, considerable development efforts have been spent on the Modelica compliance of the library in order to better support SimulationX and OpenModelica on Microsoft Windows. Since OpenModelica 1.11 Beta 1 the MDD Communication blocks are finally supported by OpenModelica.

Back in 2009, the library was developed using the Dymola tool. With MDD v1.4.0, considerable development efforts have been spent on the Modelica compliance of the library in order to better support SimulationX and OpenModelica. Since OpenModelica 1.11 Beta 1 the MDD Communication blocks are finally supported by OpenModelica.

I can add that, or you can add it if you want to.

[tbeu]

I can add that, or you can add it if you want to.

Guess it is easier and faster if you do it. Thanks (for both accepting and updating).

[thorade]

Is your title final (read: citable)?

[tbeu]

It started as a working titel, but as it never was discussed or changed yet, I believe it will not be touched again.

[bernhard-thiele]

Sorry for answering so late, I didn't notice the post. Yes, I think the title is good and don't expect that it will change.

[bernhard-thiele]

I'm going to write a first version of the "Features" section over the weekend. Since the end of the year is approaching, we should try to work in parallel at different sections for concluding a first complete draft version next week. I would propose following tasks:

• @tbeu start draft text for Section 3 "Modelica Compliance"
• @vwaurich Section about your use-case. The current Arduino text is is written in a generic style of what can be done in principle, but I think you have a very concrete application running. It would be good to briefly present the concrete application including a picture of the set-up.
• @tbellmann Text for the DLR use-case
• @sjoelund Text for the SBHS use-case

I don't know whether the features MQTT #130 and Bluetooth #116 have been driven forward. From texts by @vwaurich I understand that we can use Bluetooth devices by using the serial port interface API and some configuration which allows to do serial communication over Bluetooth.

[vwaurich]

I updated the section about arduino which includes a sentence about bluetooth. I havent done anything about HID-bluetooth and I dont think this is of high relevance. I also worked on mqtt but again, its a mess with pthreads and I have no working implementation yet. Besides that, it is not clear how a mqtt-interface should look like (using serial packages or native modelica types or serialized json, ...). I will discuss this in #130.

@bernhard-thiele Are you fine with the picture?

[bernhard-thiele]

@vwaurich Thanks for the text! It's fine and I just merged it in 592bb5d16cd8bf9df6abe535c6f8c37b02627151.

The picture fits very well, but

• Is the Arduino schematic sketch "free" so that we can safely use it, or do we need to ask for permission?
• The screenshot seems to be from OMEdit and unfortunately OMEdit renders also deactivated ports. I just used gimp to remove the deactivated port, I think this makes the picture a bit clearer. Alternatively one could do the screenshot with a different tool, which doesn't render the port. Anyway, this is a minor issue.

[sjoelund]

Looks like https://openclipart.org/detail/181334/microcontroller, which is public domain

[vwaurich]

Good question. The sketch is made with autodesk circuits. We could mention it somewhere. I found also paper which used such sketches without having any copyright notice etc.

[vwaurich]

And thanks for removing the boolean port in the picture. Its better this way.

[tbeu]

I am going to work on chapter 3 in January (I was already told that there will be an extended deadline). I guess I need at least 2 pages, thus it is necessary to either shorten the article or apply for some extra pages (as stated at the official call).

[vwaurich]

According to Autodesk legal notices, it should be ok to publish screen shots for educational purposes which is considered as fair use. PR180 adds a attribution statement.

[bernhard-thiele]

@vwaurich Very well, then the figure should be fine. Thanks for checking.

[bernhard-thiele]

@tbeu I'm out of office in January with very sporadic internet access. Hence, I want to submit at least a complete draft in December. After a first draft is uploaded, it is of course possible to upload further iterations. I can start with writing a first (short) draft of section 3 and you can improve upon it and complete it. @sjoelund can take care for uploading improvements to easychair during January as a back-up when I'm not available.

We currently have about 7 pages, so there are 3 more pages allowed. I expect that the embedded control part will take less than 1 page, so that about two pages for Section 3 should be available. There should be also some room for shortening the remaining text if needed. On the other hand, I'm optimistic that we would get an allowance to exceed the 10 pages a bit, if we ask. Of course we need to keep an eye on the page limit, but I think we will manage without much trouble.

[tbeu]

@bernhard-thiele I am basically offline from 24th till 1st and will not manage to add content before the 24th. I am able to contribute in January and can also update the final article on Easychair in January (provided you share the credentials) before the final deadline. So there is no need to hasten to meet the first deadline - neither for you nor for me. Would this be fine for you? You still can add the draft version before the first deadline on Easychair.

[bernhard-thiele]

Yes this can work. @sjoelund has my Easychair credentials, so that he can take over the uploading/editing etc., in January without problems. I just want to make sure that we can submit a paper version before I leave in which section 3 is not completely empty (I also can't contribute to the section in January). But no need for you to rush, if January works for you, than work and polish the part in January, that's fine.

[tbeu]

OK, I am also fine with that.

[tbeu]

There are now several open (and partially conflicting) PRs by the co-authors.

@bernhard-thiele Can you please give a small lookout how to proceed with the finalization of the article till the 22nd? Will you care for all December PRs and @sjoelund or me for the January updates? Thanks and Merry X-mas!

[bernhard-thiele]

@sjoelund thanks for the text, I just merged it and also made some changes. Please check whether these are fine for you.

My idea was to (also) present a concrete application example, together with a photo. The title "Embedded Control" suggests a control application. I was thinking that you would add some lines regarding the SBHS board?

[bernhard-thiele]

@tbeu I will care for the December PRs and check yours the day after tomorrow (tomorrow I'm away). I think @sjoelund can take care for the January PRs, since he will also commit the final version to easychair. I might also have some online spots there I can check some small things in January.

[bernhard-thiele]

Now, the paper has material below all top sections.

I will comment out remaining comments, so that they are not visible in the PDF (but they will still be in the latex source).