This star implements a dynamic map-function. It is inherited from DEDynMapBase. It instantiates and deletes any block given by the parameter blockname on demand from newBlock or delBlock, respectively. In newBlock and delBlock an integer value as unique identifier for the block to be created is expected.
Derived from: DEDynMapBase
Location: $PTOLEMY/src/domains/de/contrib/stars
Version: 1.7 "03/27/98"
Author: J. Voigt
newBlock | int | gets the number of the instance to create |
delBlock | int | gets the number of the instances to delete |
in (multiple) | anytype | dummy input, we just need a connection to DEDynFork |
out (multiple) | ANYTYPE | dummy output, we just need a connection to DEDynMerge |
This star creates and deletes blocks dynamically. It must be connected to DynMerge-star(s) and/or DynFork-star(s) in order to get and release all the portholes needed for the dynamically created blocks.
It is a real implementation of a dynamic map-function. Each time newBlock gets an event, a new instance of a block of type blockname is put into the system's configuration. Each time delBlock gets an event, a block is taken from the configuration.
Actually, this star is just an example on how to do this. We here use just plain integers for the instancename of the block we create dynamically. Other, very similar stars can also be inherited from DEDynMapBase and might have portholes of other datatypes. Especially the message-type will be very useful to send more information about and to the dynamically created block.
In setup() we check whether or not the number of outputs of blockname fits to the number of DEDynMerge this star is connected to. And so we do with the number of inputs blockname has and the number of DEDynMerge this star is connected to. If there are any differences, an errormessage is given out. In fact, we do need one DEDynMerge for each output of blockname and one DEDynFork for each input blockname has.
We use now the states of the baseclass DEDynMapBase to get all information we need about the block to create. See the description of DEDynMapBase, where this star is derived from, for further information.
We check how many output-portholes our block with blockname has. From setup we know that we have exactly as many DEDynMerge connected to the out-multiporthole of that star. Each of the portholes in out is connected to the first porthole of the input-multiporthole of its DEDynMerge.
So, each output-porthole of our newly created block of type blockname is to connect to another DEDynMerge. For each output-porthole we do: We look for the farside of the next porthole in out. The parent of this farside is exactly a pointer to the DEDynMerge-star this porthole in out is connected to. If this parent is not a DEDynMerge an errormessage is given out. Then we look in the output_map for the name of the porthole of blockname and get a pointer to this porthole. We create a new porthole in the input-multiporthole of our DEDynMerge and connect both portholes.
The same procedure is done for every output-porthole of our newly created instance of type blockname.
We check how many input-portholes our block with blockname has. From setup we know that we have exactly as many DEDynFork connected to the out-multiporthole of that star. Each of the portholes in out is connected to the first porthole of the output-multiporthole of its DEDynFork.
So, each input-porthole of our newly created block of type blockname is to connect to another DEDynFork. For each input-porthole we do: We look for the farside of the next porthole in in. The parent of this farside is exactly a pointer to the DEDynFork-star this porthole in in is connected to. If this parent is not a DEDynFork an errormessage is given out. Then we look in the input_map for the name of the porthole of blockname and get a pointer to this porthole. We create a new porthole in the output-multiporthole of our DEDynFork and connect both portholes.
The same procedure is done for every input-porthole of our newly created instance of type blockname.
We do the same procedure as in connectXXXputs, but we do it in the reverse order. We disconnect the portholes and delete the portholes on the farside in the DEDynMerge and DEDynFork-stars.
However, we have to be careful with deleting the input-portholes of DEDynMerge. Some events might be scheduled to them. If there are any, we better delete them.
See: source code,
DynMap users
copyright (c) 1997 Dresden University of Technology All rights reserved. See the file $PTOLEMY/copyright for copyright notice, limitation of liability, and disclaimer of warranty provisions.