hey Flavio,

I'm not a OM-developer but you have to make sure that the I/O's of your FMU truly are causal. (Since FMI isn't modelica specific, (it has support in e.g. matlab), there is no such thing as acausal connections, which btw is one of the strength of Modelica.) Since causal connections in Modelica correspond to signals I suggest, in your case, to connect a torque sensor to your flange before you export the FMU.

Or do you already get the phi and  tau as time dependent signals of your FMU (not fully sure what you mean by properties) ? In that case you can connect any of them to its corresponding rotational source at Modelica.Mechanics.Rotational.Sources and then connect that to your rotational system.

cheers,

patrik

Hi Patrick,

Thanks for the answer and the tipps!

What I meant when I said "properties" (maybe I used it wrong, sorry!) was the attributes (better?), I mean for example my Flange has essentially an Angle and a respective Angular velocity.

Although when I am using Modelica to model I can simply connect to a MEchanical.Rotational.Inertia 's flange and they so to say communicate, when I export it doesn't in fact keep the attributes (Tau and Phi) attached as a packet called flange but it breaks down in to different signals flange_tau and flange_phi, which in it self is understandable since then you can create a controller for the separate signals.

My problem is I want to for example attach inside modelica a Load (MEchanical.Rotational.Inertia) to my imported FMUBlock dcmotor and I can't do it since I can't attach a signal to the Inertia flange!

I am trying to get the understanding of how it would work so later on I could go for more complex models and try some Importing/Exporting between several IDE's such as Simulink <--> OpenModelica and such.

I did a screenshot from my model (before exporting) together with the broke down properties (when Imported as a FMUBlock) maybe it will help.
http://img843.imageshack.us/img843/7084/iotest.jpg

Flavio,

Nah, Attributes isn't really a good name either, I'm sorry. In Modelica terminology they are simply variables, (since they vary over time during the simulation). Parameters can change too, but only before the simulation process start. If you would have referred to those as properties or attributes -  I wouldn't have objected. 
Anyhow...

The reason you cannot treat tau and phi as a Modelica.Mechanics.Rotational.Interfaces.Flange_a is that the order and how the equations are solved is determined by the Modelica translator/compiler and depends on which context, i.e. model, they're in.
A simplified argument goes like;

If you have two flanges, x and y, connecting them yields the following equation;
tau_x + tau_y = 0.
When the acausal Modelica code is translated into sequential/causal (c-code), this equation either becomes;
tau_x := - tau_y or tau_y := -tau_x.

This is exactly what happens when you generate a FMU. The FMU has the advantage of being supported by any IDE that implements the FMI, which in one sense is much simpler (to enable portability between many tools) than translating/compiling Modelica code. But it comes at the cost that the causality (information flow) is decided once and for all for each sub-system that constitutes the FMU. And if you want to connect such together, you, yourself, have to define what is input and what is output between your FMUs.

In your case I realised that you cannot simply measure the torque from the EMF and send it as a signal from your FMU and then connect that signal to a torque source, since the torque generated depends on the load. I'm not saying it's impossible to solve with signals, but I haven't figured out a correct solution. Generally I would, however, recommend you to model as much of the dynamics in Modelica and only split up you models into FMU-subsystems where it makes sense to have only I/O connections. Fiddling around too much with signals can also hinder the Modelica compiler from optimizing the code (which is of essence in larger models).

hope it clears it out somehow,

cheers,

Patrik