Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

Simulink Ports, Vector Ports

171 views

Skip to first unread message

Avram K. Tetewsky

unread,

Aug 30, 1993, 10:29:55 AM8/30/93

topic simulink need for vector ports and proposed examples.

from Avram k. Tetewsky,
atet...@draper.com
Document unto others as you would document onto you.
How did Gd create the world in 6 days, no documentation.

On one hand, the basic object in simulink has one vector input, one vector
output,
sys=function(t,x,u,flag)

but in general, we naturally tend to think of generalized blocks as having
multiple vector inputs and outputs. The current Matlab simulink solution
is unacceptable -- that of muxing and demuxing scalars.
To do vectors, we have muxed and demuxed all vector inputs into a single
vector, but the simulation results are really slow. Simulink
should implement automatic mux and demuxing of vector inputs/outputs
in some way that once the diagram is running, the cost of the mux and
demux is nill. We would like it to be transparent so that we could
think in terms of multiple vector in/out ports.

I would like to propose that the mathworks consider upgrading Simulink
to handle multiple vector and input and outputs. They could take
the limited integrator example and turn it into a more general system
as described below (thus fixing the problem and then manual at once!)

1) A new example to follow the liminted integrator using vector ports,
an upcoming feature in simulink sorely needs to be done.
This new example is a direct extension of the limited integrator,
called the vectored limited integrator with time varying gains,
and the ability to determine input sizes based on the input parameters!!!!!

The problem with simulink is that one can't partition large problems
with current limited scalar i/o port tools provided.

problem:

create a limited integator of dimension n, and time varying gains,
to implement

[u1:un]' +----------------------------+
----------------->| diagonal k(t) matrix |
| ------------------- |------> [y1:yn]' out
[k1:kn]' | s |
----------------->| with upper and lower bounds|
| on each channel |
+----------------------------+
^ ^
lower upper
vector of lower and upper
bounds for each channel
from the work space

this is just a vector version of your limited integrator problem
except that each integrator has a time varying gain.

We would like to be able to make an S function, or sometype of
block that
a) took multiple vector inputs and outputs.
b) could resize based on the size of u and k and y, assuming
that we check to see that they are compatible.

resizing is a major thorn because it currently seems that although
mathwork supplied diagrams can resize, m and c functions
that we write can't test the size of u and xo within the bodies to
determine sizes. Please try to really demonstrate that
when we write the m or c or fortran version of the above
multi-vectored in/out block, that we can make the sizes variable.
Using the matlab integrator, I could build a vector integrator
with run-time sizing only by testing the initial condition xo size
from the workspace -- but at least using their built-in integrator
I could do that one resizing at the start of the simulation.
Doing the same with an m or c file was impossible once the S wrapper
was put around it!

Note: we could live with testing the initial conditions so that
the sizes don't change once the simulation is running,
allowing optimizations to be done.

from Avram k. Tetewsky,
atet...@draper.com
Document unto others as you would document onto you.
How did Gd create the world in 6 days, no documentation.

Rick Spada

unread,

Sep 1, 1993, 11:34:16 AM9/1/93

In article <1993Aug30.1...@draper.com> Avram K. Tetewsky,

atet...@draper.com writes:
> On one hand, the basic object in simulink has one vector input,
> one vector output,
>
> sys=function(t,x,u,flag)
>
> but in general, we naturally tend to think of generalized blocks
> as having multiple vector inputs and outputs. The current Matlab
> simulink solution is unacceptable -- that of muxing and demuxing
> scalars. To do vectors, we have muxed and demuxed all vector
> inputs into a single vector, but the simulation results are really
> slow. Simulink should implement automatic mux and demuxing of
> vector inputs/outputs in some way that once the diagram is
> running, the cost of the mux and demux is nill. We would like it
> to be transparent so that we could think in terms of multiple
> vector in/out ports.
>
> I would like to propose that the mathworks consider upgrading
> Simulink to handle multiple vector and input and outputs. They
> could take the limited integrator example and turn it into a more
> general system as described below (thus fixing the problem and
> then manual at once!)

This is an excellent suggestion, and you'll be happy to know that
this is in the development process as we speak. In a forthcoming
release of SIMULINK, all blocks will be able to accept vectors.

Thanks again, for a good suggestion.

-- Rick

0 new messages