Only clocked/sampled communication about modelica_devicedrivers HOT 13 CLOSED

@dietmarw May be interesting for you that the syntax hiliting of the closing bracket is blue where it should be black.

from modelica_devicedrivers.

I'll ping @thorade as he knows more about what highlighter is currently used by GH.

from modelica_devicedrivers.

Modelica syntax highlighting was added as a reaction to this issue:
github-linguist/linguist#2053
here is the corresponding pull request:
github-linguist/linguist#2059

In that pull request, the repo@commit BorisChumichev/modelicaSublimeTextPackage@d7e50e3 was chosen for syntax highlighting. The repo has since then seen some updates, so the pointer to the hash should be updated. But before doing that, you should file an issue that demonstartes your problem here:
https://github.com/BorisChumichev/modelicaSublimeTextPackage/issues
Upload some problematic Modelica code e.g. to Gist, then use Lightshow:
https://github-lightshow.herokuapp.com/
E.g. like this:
http://bit.ly/19e6Mv1

from modelica_devicedrivers.

@thorade Feel free to do it. Thanks. 😀

from modelica_devicedrivers.

@bernhard-thiele Do you think we can reuse PackageIn.trigger and PackageOut.trigger for alternative triggers? Can we use backwardTrigger only enable if trigger_type is cyclic? Is this allowed in a connector?

from modelica_devicedrivers.

@tbeu Yes, I think so. I will try something once I have some time and a free dymola license. I will try to support an additional external Boolean trigger input signal which is conditional available if some Boolean parameter is set. The different triggering options could be realized by a distinctive "trigger" block. I think this would be a pretty flexible solution.

from modelica_devicedrivers.

Good idea. I believe I can support you. Cylclic should be independet of Boolean trigger input to realize "Cyclic + Event" triggering.

from modelica_devicedrivers.

@tbeu I just made a first attempt in a new feature branch. Example Modelica_DeviceDrivers/Blocks/Examples/NEWTestExternalTriggerSerialPackager.mo illustrates the idea.

Note that this is a backwards compatible change. What do you think about it?

from modelica_devicedrivers.

Thanks for fast implementation. My thoughts:

• Why did you choose to add the trigger port to the SerialPackager? Answering myself, one reason might be to do it only once at exactly one location in the package. But if I had done it I'd select the communication send/receive blocks for the addtional trigger port. In my opinion it logically belongs there. It is then possible to create a package and connect multiple send blocks (wih different triggers) to it.
• There is no need to support the "Cyclic + Event" triggering like we did in the past and I mentioned above. Best way of modeling is like mentioned above with one package and multiple communication blocks.
• Imagine the case where two ore more packages need to be sent in a particular order (in order to realize some special communication protocol). This would require an extra Boolean outport returning the I/O success for the communication blocks for modeling chained communication processes.

Let me hear what you think about these comments. Thanks.

from modelica_devicedrivers.

Ok, my thoughts:

• I implemented the mechanism for the SerialPackager just as an example for discussion and planned to implement the same mechanism also for the various receive and send blocks. However, that alone is probably still not sufficient for the use case that you describe, since it wouldn't allow to connect several send blocks to one package. The triggering logic would need to be extended so that it can cope with several sinks or sources. For the sinks and sources one would need to be careful so that the same device can be shared. But maybe I'm thinking too complicated...
• The Boolean output is an interesting idea. But a simple I/O success might not be sufficient for modeling chained communication processes. We could either generate a new event that is capable of triggering the next blocks, or we could try to ensure that all blocks are synchronized at events and use an additional signal to establish data-flow dependencies that would ensure the correct ordering. What scenario do you have in mind?

from modelica_devicedrivers.

• You are right: Multiple communication sinks are too complicated if possible at all. Maybe the extended trigger type is a solution.
• I was thinking of custom protocols where packages need to be sent in a particular order, e.g, do a handshake first and then do sampled communication. It should be possible as custom text but maybe not with generic block components since different packages may be required for the different protocol steps.

from modelica_devicedrivers.

Just created branch externalTriggerFeature in which I added an option to use an external trigger for triggering the read/write operations. This approach uses conditional connectors which adds another challenge to Modelica tools and people trying to understand the code ;-).

@tbeu Does the new code work in SimulationX and do you have any comments on it?

from modelica_devicedrivers.

Can test it next week.

from modelica_devicedrivers.