Activity/Action Block
The activity block is the key Petri-Net component, together with the container type C block, it provides for discrete event simulation.
It has two input connections, An and Bn. Both must be containers (or integrators)
It has two output connections Cn and Dn. Both must be containers (or integrators)
Connecting to other block types doesn't work.
The delay (activity time) is defined by the sum of the value found at the output of the Pn connection block, plus the value in the pp parameter. Positive values are fixed, negative values are random with the mean being specified.
The distribution is an Erlang Distribution with shape factor 2, so it doesn't give a big peak near zero like the Poisson and the probablility of really extreme values is restrained a bit.
The Pn connection can alternatively be used to deliver any sort of time delay, random or variable for each occasion.

The essential PetriNet idea is a transition that takes place when tokens are taken from input places and are moved to output places. There must be places for the tokens to be moved to and there may be other conditions imposed for the transition to take place. Here, if the A-Block is idle, available tokens are taken from the containers identified as blocks An and Bn. They are moved to interior containers inside the A-block. A second transition takes place when the delay time has been reached and the tokens are moved to the output places identified by Cn and Dn.
Thus the A-block can represent a process which operates when resources are available, which takes time and will deliver the product to appropriate recipient locations. It could be a manufacturing operation, the execution of a computer subroutine, a simple delay in delivering a message or a tool. The tokens can be real objects or simply abstract concepts like permission to proceed.
With no content it waits for tokens to become available at its inputs. When available, the tokens are taken, it becomes busy and will remain so until the delay time has elapsed.
It then delivers tokens to each of the identified output connections, but only if there is space for them, and, becoming empty, reverts to waiting for incoming tokens to be available.

If an input connection is not defined then it is ignored. With only one input it will start its delay time cycle as soon as there is a token there.
If both inputs are zero (null, not connected) then, being unconstrained by them, it will repeatedly cycle, delivering tokens to its output connections.
If an output connection is not defined, then it too is ignored and the A-Block will make the second transition, back to idle without waiting for space to be available to put its token.
The device is a state machine, so don't play with the State variable without care.
It has various modes of behaviour described below.

Variants and extensions: Take and Put rules
The parameters aa, bb, cc, dd are used to define the rules for taking and delivering (putting) tokens.
The default value is ONE, matching the description above.

Take Rules
Any positive (aa or bb) values will have to be available in the relevant containers for the starting transition to be made and those specified quantities will be taken from the relevant containers. They do not have to be integer amounts.
For example, it can take a bucket load out of a heap of material being accumulated in an integrator, or matching quantities of materials from two places to perform a blending operation.
Any negative (aa or bb) values will tell the Block to check that there is something available and then take as much as it can up to the amounts specified as the absolute values of aa, bb.
The amounts taken from containers (or integators) An and Bn are stored in the A-Block's internal store. The values are shown when the block details are shown for creation or modification. The intent is that whatever is taken from Block-An will be going to Block-Cn and what is taken from Bn will be going to Dn, but the "Put rules" can modify that.

Put Rules
Any positive (cc or dd) values will cause those quantities to be put into the containers Cn and Dn respectively (if connected and if space is available), regardless of the contents of the internal store. For example, an amount, e.g.50kg, taken from a store to represent a sack full of material can appear delivered as a unit (one sack) amount.
Any negative (cc or dd) values will cause the contents of the A-Block's internal storage to be put in the corresponding recipient container (if connected and with space available) up to the amounts represented by the absolute values of cc,dd. Thus, making 'cc' the same as 'aa', will result in a delivery into Block-Cn of whatever was taken from Block-An.
Regardless of what is put into recipient blocks the internal store is emptied as the transition to idle takes place.

Other Ideas
Since the A-block can transfer arbitrary values from one place to another the "tokens" could have meaning other than quantity.
A token could be a type number such that when delivered into a container it could be read by a logic block and used for routing.
The progress of a bus that can gather up to 50 passengers could be represented as an A-Block with aa=-50 and bb=1 and with cc=-50 and dd=1 it could move up to 50 passengers (from An to Cn) and move the bus from Bn to Dn.
Taking in a token as a "permit" or a "tool" to do a job might well release the tool and the job but could also release other tokens to allow further actions to be taken.

Instant Action and Sequence Control
Instant (zero delay) action is allowed. This means that an A-block can move tokens from one container to another instantaneously. It never appears busy in the graphical display if it is able to do so. Combined with the control of computational sequence provided by the use of block ID numbers, and the use of tokens to represent switching conditions, timed, cyclic, logical and counting operations can be performed. The demo file Diverter_1_in_N.txt uses this.

A: Activity/Action Block Code.
Procedure ActivateA(ii:integer); //Activity. for Petri Net version 4 of McSimAPN.
var initialState:integer;
AvailA,AvailB,DropC,DropD:real;
begin
with B[ii] do begin
if OnOff<=0 then begin Vn:=Vn+Delt; EXIT end; //switched off, let anything inside wait
InitialState:=State;
if((State=0)OR(State=1)) then begin {for empty states in this block}
AvailA:=isAvail(An,aa); AvailB:=isAvail(Bn,bb);
if (AvailA*AvailB>0) then begin //isAvail() has checked that An Bn are C or I.
Take(An,AvailA); //IsAvail has checked block numbers are OK
Take(Bn,AvailB); // block zero will be ignored by Take()
Store[1]:=AvailA; Store[2]:=AvailB;
State:=2; Vn:=NextEventTime(B[Pn].Vn+pp);
//Tell('A: state=',State);
end {if available};
end{State is empty};
// Note state may now have changed to 2, so Zero time delay generates immediate action.
if (Time+TinyDelt>=Vn) then
if ((State=2)OR(State=3)) then begin {for OCCUPIED states}
DropC:=cc; if(cc<0) then DropC:=min(Store[1],-cc); //Decide what is to be Dropped
DropD:=dd; if(dd<0) then DropD:=min(Store[2],-dd);
if (isRoom(Cn,DropC) AND isRoom(Dn,DropD)) then begin
Put(Cn,DropC); Put(Dn,DropD);
Store[1]:=0; Store[2]:=0; State:=1 end{if isRoom}
else state:=3; //state 3 used to flag blocked condition for display
end{OCCUPIED states};
if ((initialstate<>state) AND Animation ) then DisplayA(ii)
end{with B(ii)}
end{proc};