Block Configuration

This page describes common block properties, settings, and functions. Detailed information on functions and usage of specific blocks are found on their respective pages.

Configuration Dialog

After being placed in the workflow, a block is usually configured for a specific task. Naturally, different blocks have a variety of different settings which are not detailed here.


To open the block’s configuration, double-click the block after it is placed in the workflow. The configuration window contains 4 tabs 1:

  • Configuration: the block-specific configuration. The contents of this tab depend on the type of the block you configure and are described on the block’s documentation page in (click the help button 2 to open this page).
  • Options: allows to view and set block’s options, and to add options to workflow parameters (see section Options).
  • Ports: allows to view input and output ports, their data types, set up port monitoring, and add ports to workflow parameters (see Ports).
  • Sandbox: sets the location of the block’s working directory (see Sandbox).

Many blocks allow to map some values from configuration to their inputs and outputs. One of the simplest examples is Const, the block that allows you to add named constants; each constant added automatically creates an output port with the same name, so when the workflow starts, this port outputs the value you have set for the constant. Other typical example are CAD and CAE integration blocks, such as SolidWorks; after a document file is loaded in this block, you can select document variables that have to appear as block’s inputs and outputs.

Common Settings

This section describes settings and properties that are common across all blocks.


Options are an essential part of the block configuration; the Options tab often contains advanced settings not available on the Configuration tab.


To change an option, double-click its value 1. Non-default values are shown in bold 2.

On this tab you can also add any option to the list of workflow parameters 3. It makes the option available on the Configuration tab in Run, allowing to change its value quickly without opening the block’s configuration. Note that values specified in Run override those set in the block’s configuration.

While the layout of this tab is the same for all blocks, available options depend on the type of the block. Detailed option descriptions are found on block documentation pages.


Each block has named inputs and outputs called ports. In pSeven, all ports are one-way only, either input or output (bidirectional ports can be emulated by input-output port pairs when needed).


The Ports tab shows current ports, their names 1 and types 2. Note that certain changes in block’s configuration can change its ports (for example, when adding variables).

In some cases a block requires an input to some port, but this value is a constant. To avoid adding a block with constants, you can assign a value 3 directly to a port. For input ports, these values are accepted only if there is no link connected to the port. Values assigned to output ports work differently: they are used as output defaults, in case of error, by the blocks that support such behavior (see section Error Handling).

Like options, ports can also be added to workflow parameters 4 allowing to send values to them from the Configuration tab in Run. Note that values specified in Run override those set in the block’s configuration, and neither of them is used if there is a link connected to the port (that is, the link has top priority if it exists).

Finally, any port can be monitored 5 meaning that all data sent or received through this port is captured by pSeven and stored in the project database for further analysis. Monitored ports are also shown on the Configuration tab in Run.

Signal Ports

All blocks have two special ports: do (input) and done (output) which are intended for explicit block synchronization.

The do port is used to give a start signal to a block. If this port is not connected, the block will start as soon as it receives all required data. However if you create a link connected to this port, the block will wait until it do port receives some input. The do port accepts data of any type, so any variable can be used as a signal. The value received does not matter.

The done port always emits a signal when the block has finished execution. The signal is a Boolean value which is True is the execution finished successfully and False if there was an error, thus done can also be used as a status port.


A sandbox is the current working directory for the block at workflow run-time. For example, this directory stores files needed during block execution — whenever a block needs to write a temporary file to disk, it writes to the sandbox.

By default, the sandbox is a temporary directory created in the system directory for temporary files. The default sandbox exists only while it is needed, so each block decides when to create and delete the sandbox by itself. You can change this behavior, as well as the location of the sandbox, on the Sandbox tab.


The location may be set relative to project directory (useful for portable projects) or by an absolute path.

Behavior determines when to clear the sandbox: the cleanup may be done automatically — either each time the block executes, or only when the workflow finishes — or manually, meaning that there is no automatic cleanup, and the block never deletes its sandbox.

If the sandbox has to be cleared between block start-ups, yet there are some files that must always be found in sandbox, you can also set a sandbox prototype. It is a directory which contents are copied to sandbox when it is created or re-created. The prototype can also be used simply to initialize the sandbox with all required files.

Finally, two or more blocks can be assigned the same sandbox. In this case, all of them have equal rights to access sandbox files, but the sandbox may be cleared only when all blocks allow this. For example, such configuration can be used to exchange files between blocks, if for some reason these files cannot be sent through ports.

Advanced Settings

This section describes advanced configuration options that are available only in a few blocks.


Data caching allows to avoid redundant calculations by remembering the input and output values of the block. When a cached block receives an input, it looks through the cached input values. If the received input is found in cache (cache hit), the output values are read from the cache and output to the workflow. If the input is not found (cache miss), the block performs calculations, outputs the results and updates the cache.


To use the cache, select “Enable cache” in the block configuration dialog. The file name is optional:

  • If the file name is not specified, the block will use a memory cache which exists only while the workflow runs and is cleared when the workflow finishes. In this case, cached values are not available after running the workflow.
  • If you specify a file name and path, the block will store cached values in this file. The file is persistent, so in this case cahced values will be available for analysis after running the workflow.

In case you want to reset a cache file, you can clear it from the block configuration dialog. Note that clearing the cache deletes all cached data.

Caching is currently supported only by the Composite block. Another block can be cached if it does not have optional inputs (that is, the block always requires data to all input ports in order to start). Such blocks can be enclosed into an Composite with enabled cache, effectively creating a cache for the nested block. Blocks with optional inputs cannot be cached using this workaround because Composite itself does not support optional inputs.

Note also that since the workflow itself is an Composite block, you can configure caching on the workflow level using the properties of the workflow root block.

See also

The tutorial on using the cache feature in Composite blocks.


Environment settings allow to change environment variables for the process started by the block. These changes apply only at the run-time and only to this process — they do no affect the system environment or other blocks. If the block supports defining environment variables, its Configuration tab contains a nested tab named Environment.


You can add new environment variables or modify existing ones. Values of existing variables can be used in new definitions. For example, to append a directory to system PATH:

  • Create a new variable named PATH.
  • Set its value to ${PATH};C:\path\to\directory (Windows) or ${PATH}:/path/to/directory (Linux).

Note that the syntax for names of variables is ${VARIABLE} for both Windows and Linux. The Windows system syntax (%VARIABLE%) should not be used.

Environment settings are supported in:

  • Program — set environment variables for the program or shell script executed by the block (in case of remote execution, also supports changing remote environment variables).
  • PythonScript — set environment variables for the embedded Python script.

Error Handling

In case a block encounters an error when running, it can perform certain actions as specified in its configuration. Error handling by the block is controlled using the Error handling behavior option that has 3 possible values:

  • “stop workflow”: the block raises an error and the workflow is stopped immediately. This is the default for all blocks. It is also the only possible behavior for blocks that do not support error handling.
  • “output signal only”: the block suppresses the error (does not interrupt the workflow) but outputs False to the done port (see Signal Ports). The signal can then be processed in order to handle the error. Other ports do not output any data.
  • “output defaults and signal”: the same as above, but in addition to the signal, the block also outputs values assigned to ports (see section Ports). In this case, the assigned values can be understood as default output in case of error.

Note that setting the error handling behavior to “output defaults and signal” requires assigning values to all output ports of the block — otherwise it will not pass validation and the workflow will not start.

Error handling is most useful for the blocks that launch external programs: if the program execution results in an error, handling this error in the block allows the workflow to continue normally, possibly taking some predefined actions such as selecting an alternative processing branch.

Blocks that support the Error handling behavior option are:

  • Integration type blocks: ANSYSWorkbench, Creo, FloEFD, Kompas3D, NX, SolidWorks, and CATIA (beta block). These blocks can output defaults in case the program finishes with an error — for example, fails to rebuild a model or run simulation.
  • Excel: can output default values if it fails to recalculate the Excel document or read output cells.
  • Text: can output default values of variables if it fails to parse or generate a file.
  • Program: can output empty files (instead of stopping) in case the program it launches has finished with an error, or other type of error has occurred (as set in the block’s configuration).
  • PythonScript: can output default values of variables that were not initialized in the embedded script.
  • Core algorithmic blocks: Optimizer, ApproxBuilder, DFBuilder, DRBuilder, DoE, IVE. These blocks can output default values or files in case of internal algorithm failure.
  • Composite: can output default values in case if any of the nested blocks finishes with an error. Note that Composite handles only errors raised by the blocks, but not errors that appear when data is sent from one port to another with an incompatible data type.

See also

Conditions and Error Handling
The tutorial that provides an example of handling possible errors during workflow execution and shows using the Error handling behavior option.

Manual Stop

Certain blocks in pSeven support the stop function, meaning that you can manually interrupt block’s execution in a running workflow. The behavior of a stopped block may be different, depending on its configuration and the type of interrupt support it implements. Some blocks support partial results output which allows the workflow to continue normally; others can only raise an error when stopped. By default this error stops the workflow, but the block can be configured with error handling which allows the workflow to continue even in this case.

The stop function is available on the Run screen. To stop a block, hover it with your mouse cursor and click the stop icon that appears in the top left corner. A dialog will appear asking you for the action to perform when stopping the block.

If the block supports partial result output, the stop icon is colored white.


In this case the Stop block dialog has 3 available actions.

  • Stop: try to output partial results (soft stop). For example, if the block controls a loop, and some iterations of this loop have already finished, the block can output results of these iterations. There are two possible cases here:
    1. Partial results are available. In this case, the workflow continues normally, processing the partial results output by the block.
    2. Partial results are not available. In this case the block raises an error, and the error is processed according to the error handling behavior configured for the block. If the behavior is to output defaults or signal, the workflow will continue (though it can be stopped by the next block if, for example, it is unable to process these defaults). If the behavior is to stop the workflow, the workflow will be stopped immediately (see section Error Handling for more details).
  • Terminate: do not try to output partial results, always stop the block (hard stop). The block always raises an error, which is then processed in the same way as described above. So, depending on the block’s error handling behavior, terminating a block may still allow the workflow to continue.
  • Cancel: do not interrupt the block, continue running the workflow.

If the block does not support partial result output, the stop icon is colored red.


In this case, the soft stop action is not available in the dialog.


Blocks that do not support partial result output can be stopped with an error only. Again, this error is processed according to the block’s error handling behavior, and depending on it, the workflow may continue after you terminate the block.

The stop dialog also contains a special option to update data caches (see Cache). This option is available only if the stopped block is contained into a block with enabled caching.

  • When “Cache values output by the stopped block” is enabled, the results output by the block on stop (and corresponding input values) will be added to the cache. This is primarily intended to cache partial results for the blocks that support this feature. Note that updating the cache on stop may also be unwanted — for example, when terminating the block that outputs default values in case of error (default values probably should not be saved to the cache).
  • When “Cache values output by the stopped block” is disabled, the cache will not be updated. This is useful in the case noted above (output values indicate an error and should not be cached).

The manual stop function is supported by the following blocks:

  • Map and For (beta block) support both the stop and terminate actions.
  • Program, Optimizer, ApproxBuilder, DFBuilder, DRBuilder, and Composite support the terminate action only.