Input Pin

Aus ExpeccoWiki

Wechseln zu: Navigation, Suche

Input pins are used to read information from other steps, a frozen value or an environment variable.

Inhaltsverzeichnis

Pin Attributes

All data input pins

An individual input pin's trigger behavior specifies if and how the arrival of a data value affects the triggering of a new activity for a step. Every pin's behavior is determined by three independent attributes:

  • consuming / non-consuming
  • triggering / non-triggering
  • synchronous / asynchronous


Since not all combinations of the above attributes make sense, expecco only allows for some predefined combinations to be used:

  • Regular pins (consuming, triggering, synchronous)
  • Parameter pins (non-consuming, non-triggering, synchronous)
  • Telegram (formerly Mailbox) pins (consuming, non-triggering, asynchronous)


The example shows these possible input pin types. From top to bottom, these are: normal input pin, parameter pin and mailbox pin. Their behavior is defined by the following attributes (or combinations of them):

  • Triggering / non-Triggering
    In case of incoming data triggering pins cause the execution of a step. Depending on the steps triggering conditions all, only the connected ones or only one of its pins must have data to be triggered.
  • Consuming / non-Consuming
    Non-Consuming pins hold data in their input baskets. Consuming pins feature waiting queues for their data. This data then triggers activities in the order of their arrival which take the data from the input basket. They consume it. Since multiple activities can run at the same time, the data can be processed in parallel.
  • Telegram / non-Telegram
    Non-Telegram pins are read once at the beginning of the execution. In contrary, Telegram pins are not required to have a value when the activity starts. If it does, that value is read and used inside the activity. Otherwise, the pins value will be read or used to trigger internal activities later during the execution of the action. It can thus be used to control the behavior at any later time of the execution. Typically these event pins are used to cancel long activities or to react on external events (e.g. user entries, sensor messages or interruptions). The cancel-pin is of this kind.

Regular / Normal Pins (Triggering + Consuming)

Regular pins are triggering, meaning that they can lead to the execution of a new activity for the step. They also consume their input value, which means that before the activity is started, the input value is fetched from the input queue, and remembered in a step-private local storage during the execution of the activity. Any new data arriving at the pin during the execution of the activity does NOT affect the ongoing activity. Instead, new data is placed into an input-queue, to be consumed by another activity.

Parameter Pins (Non-Triggering + Non-Consuming)

Parameter pins are non-triggering. This means that in order for the activity to be triggered, at least one non-parameter-pin, or an enable-input-pin, or the autostart flag must be present. Similar to the above, the parameter value is fetched and remembered during the execution, but in contrast to the above, is not removed from the input-pin. Thus, the parameter value can be read again in the next activity. Incoming values replace the stored value, to be used in the NEXT activity. In other words: they only hold the newest data; incoming data replaces the old one.

Telegram Pins (Non-Triggering, Consuming, Asynchronous)

Telegram pins (formerly called: "Mailbox" pins) are non-triggering and asynchronous. This means that there is no local storage for the pin's input value, where the value is save from being overwritten during the execution of the activity. In contrast, any incoming value immediately replaces the currently stored value in the pin, and this change is immediately visible to the activities' code or network. If the message pin's step is a compound step, the incoming value is immediately transferred to any connected inner step of the network. If it is an elementary step, the underlying code being executed can immediately see the new value in the pin variable.

Basket Buffer Size

The basket buffer size can be limited for each input pin. The default setting is "unlimited". The purpose of this setting is to limit the number of values that can be queued on an input pin. When the limit is reached, no further values are taken into the queue from any delivering connection. This can cause the yielding step to suspend execution until the value has been removed from the connection.  


For more information on pins in general see: Pin
For other diagram elements see: Diagram Elements
Back to the full online documentation: Online Documentation

Meine Werkzeuge