Dimension conflict in SerialPackager about modelica_devicedrivers HOT 21 CLOSED

If I remember correctly, that will allow to connect several sinks at the output, e.g., you could use shared memory and UDP or have UDP sending to two different locations.

However, I just noticed that I can't run some the examples any more. Seems I have broken something with my last renaming action. Need to have a look at this.

from modelica_devicedrivers.

But still

partial block PartialSerialPackager
      parameter Integer nu(min=0,max=1) = 0 "Output connector size"
          annotation(Dialog(connectorSizing=true), HideResult=true);

looks strange. Either 0 or 1 is allowed but is it not possible to edit in diagram layer.

from modelica_devicedrivers.

Can't we get rid of nu?

from modelica_devicedrivers.

I just made a fix to my previous commit. Didn't rename one variable consistently.

from modelica_devicedrivers.

OK. But back to my questions which is independent of branch.

from modelica_devicedrivers.

Regarding the nu, this uses the feature of automated connector sizing which should be fine

from modelica_devicedrivers.

But dimensions are wrong then. It only works because nu is 1 in samples.

from modelica_devicedrivers.

The problem is that some of the ports are unconnected at the ends (for the blocks that read). They need to be size 0.

from modelica_devicedrivers.

OK, the get functions are fine. But problem still is apparent in add functions. Above code is taken from an add function. addRealAsFloat should take nu array of pkg and return nu array of dummy.

from modelica_devicedrivers.

I think I understand it again. The connector is either 1 or 0. For the reading blocks that is needed so that they can be used without a terminal block. For the writing blocks that is not really needed since they will always be connected to terminal block that writes the package to a (physical) device. However, since the writing blocks inherit the same interface like the reading blocks, they share that code that is not required for them to work (but doesn't hurt either).

from modelica_devicedrivers.

An alternative would be to have different base classes for reading or writing blocks (and maybe factor out the common parts in yet another base class). Whether this would be a nicer solution, I'm not so sure. But we can do that. What do you prefer?

from modelica_devicedrivers.

So how did you build the example models? Did you set nu manually in the text layer to 1? This is strange since users are not aware of such a hidden parameter.

from modelica_devicedrivers.

No, Dymola does set it to 1 automatically as soon as you connect to it. Just tried to build up a new model using drag-and-drop and it worked. Or am I missing some issue?

from modelica_devicedrivers.

I see. Thus you can easily build a model with nu > 1 and run into trouble.

from modelica_devicedrivers.

That's partly true. In theory there is the constraint max=1 but Dymola doesn't check it. However, in that case the translation will fail due to a wrong number of equations.

What does SimulationX do? If slight changes would make it more convenient to use that blocks form both SimulationX and Dymola, we could do that.

from modelica_devicedrivers.

SimulationX 3.6 behaves in the same way as Dymola regarding the automatic incrementation of nu. But it not fail if nu > 1 which is strange. SimulationX 3.7 will behave differently than now.

from modelica_devicedrivers.

Maybe we should introduce different connectors for add and get packager. What do you think?

from modelica_devicedrivers.

I will think about it. However, have to stop looking at it and leave know. Of course if you have some idea that we can test, we'll do it...

from modelica_devicedrivers.

OK. Let's both think about it. Is backward compatibility an serious issue for you?

from modelica_devicedrivers.

Backward compatibility is important. There are sometimes good reasons to break it anyway. However, I would prefer starting an alternative packaging system at some day and mark the current one as deprecated.

from modelica_devicedrivers.

Well, then this issue can be closed, right?

from modelica_devicedrivers.