Resources

Introduction

The Control Center service supports the use of centrally managed resources. A resource is something that is either used when configuring modules in Flows, such as OPC UA tag lists or Modbus register mappings, or files that need to be downloaded into the Nodes when deploying Flows. File resources can then be accessed from within modules when they run on a Node, for example Python or C# scripts that are imported in the respective code modules, machine learning models that are used inside a code module or a CSV file with static data that is accessed with the CsvReader module. Resources are added to Flows from within the Flow Studio. Module specific resources are added through the respective module settings. File resources are added from the Resources panel. All resources used by the Flow are managed in the Resources panel, where new resources can also be created.

The Resources page in the Control Center web UI is used to manage all available resources. The main page shows all currently available resources and new resources can be uploaded from here. A resource can be created by uploading a file from local storage, or by entering the information directly in the UI. If you no longer want a resource to be available there are two options:

  • Archive the resource. If the resource is used by Flows that are, or have been, deployed (read-only) you can archive the resource. This will block the resource from being used in new Flows or versions, but existing Flows can still download the resource.
  • If the resource is not used by any deployed Flows can can also Delete the resource from the system.

 Some general things to note about resources:

  • All resources have a name. This name is used when referring to the resource in the UI, e.g. on the main resource page and when selecting the resource for use in a Flow. Resources that are downloaded into the Nodes, such as file and script resources, also have a local name. This is the local filename used to refer to the file from inside a module. See below for more details on how this is used for the different resource types.
  • Resources can be version controlled.
  • Once successfully created a resource cannot be changed or removed, it can however be archived. The reason is that an uploaded resource may be used in a Flow and changing or removing the resource may have undesirable effects on the running Flows.
  • An archived resource cannot be used when configuring a new Flow version. Existing Flows that use the resource will still get access though.
  • Resources can be downloaded to your local computer, e.g. to modify it and upload a new version. There is however a size limitation and files larger than 10MB cannot be downloaded.
  • Small resources (<1MB) can be viewed in the UI and the content can be copied into a new resource, which is useful for small changes.

Note: You must have permission to manage Resources to be allowed to add resources. However, all users can use the resources when creating Flows.

Add a new resource

There are two places where resources can be added: In the Flow Studio and on the Resources page.

To add a new resource in the Flow Studio, open the Resources panel using the Project menu bar along the right side of the screen:

 

Crosser Flow Studio | Flow Studio | Resources
Crosser Flow Studio | Flow Studio | Resources

Then click on “ADD RESOURCE” and then on the ‘+’ button. This will open up the Create Resource panel.

When adding a resource inside the Flow Studio it is automatically added to the current Flow.

Alternatively you can add resources on the Resources page by clicking on

Fill in the required information and either enter the data in the UI (‘Code’) or upload an existing file.

Resources added on the Resources page must be added to Flows that need them in the Flow Studio, using the Resources panel.

Resource types

The following sections describe how to create and use the different types of resources.

File resources

A file resource is any type of file that is needed locally on a Node, by the Flow running on that Node. Examples are machine learning models that are loaded into some ML framework in a PythonBridge module or a CSV file accessed by the CSV Reader module. The system makes no assumptions on format or content of these files, it will just make sure that these files are downloaded to any Node that runs Flows that reference these resources.

File resources must have a local filename, which can contain a path. A local name can only include alphanumeric characters plus ‘.’, ‘_’, ‘-’ and ‘/’, ie ‘a/b/c/test.csv’ is a valid name, while ‘a/b/c/test 2.csv’ is not. When accessing a file from within a module in a Flow, e.g. the CSV Reader, it should be referenced using a base path of ‘data/Flowresources/’, ie the file above will be available as ‘data/Flowresources/a/b/c/test.csv’.

You can copy the full path to the file using the 'copy' button to the right of the filename on each resource in the Resources panel. 

Python and C# Script resources

Python/C# script resources are very similar to file resources, ie they will be downloaded to the Nodes where they are referenced. The Control Center will not validate the content. The difference is that these resources are intended for use in a specific module, namely the PythonBridge and Csharp modules respectively.

These modules will find the resources in the predefined location. For example, if a Python resource is uploaded with a local filename/path of ‘mylib.py’, it can be used in the PythonBridge module with a standard ‘import mylib’ statement.

OPC resources

OPC resources are tag lists that can be used when configuring the OPC UA Subscriber and Reader modules, instead of typing each tag in the module UI. When using an OPC resource all the tags in the resource will be used by the OPC UA modules. Any tags entered manually in the UI, or loaded dynamically from a Flow message, will be added to the list of tags in the resource file. The format of OPC resources is a JSON array with an object per tag:

[
 {
  "NodeId": "ns=4;i=1244",
  "path": "/4:Boilers/4:Boiler #1/4:PipeX001/4:FTX001/4:Output",
  "customType": "tempSensor",
  "customScale": 1.5
  },
 {
  ...
 }
]

The NodeId property is mandatory and should follow the OPC UA syntax for Node IDs.

Any other properties added will be included in the output message for the tag. Custom properties can for example be used to add metadata to allow filtering/grouping of tags in other modules in the Flow, or apply per tag specific scaling/conversion parameters that can be used in other modules to change the values.

This format is also used when loading tags dynamically from Flow messages and matches the output produced by the OPC UA Browser module. Note though that the output of the OPC UA Browser contains several properties in addition to NodeId and these will be treated as custom properties by the Subscriber and Reader modules. If you don’t want to have these properties in the output they must be removed with a Property Mapper module between the Browser and Subscriber/Reader module.

Modbus resources

Modbus resources are used to specify the register mappings for different PLCs. When the resource is used in the Modbus Reader module, all of the listed tags will be retrieved. Additional tags can be added in the module UI. A JSON file is used to define these mappings. Any properties in addition to the default tag properties described below, will be treated as custom metadata and will be added to the messages.

Example Modbus resource:

    {

    "name": "PLC1",
    "unitId": "1",
    "tags": [
        {
            "id": "tag1",
            "modbusDataType": "Int",
            "modbusFunction": "ReadHoldingRegisters",
            "address": "0001"
        },
        {
            "id": "tag2",
            "unitId": "2",
            "modbusDataType": "Byte",
            "modbusFunction": "ReadDiscreteInputs",
            "address": "0101"
        }
    ],
        "byteOrder": {
        "twoByte": "01",
        "fourByte": "0123",
        "eightByte": "01234567",
        "string": "01"
    }
}

 

A Modbus device (PLC) is specified as a JSON object which must have at least a name and at least one tag in the tags list. Optionally the unitId can be specified if something other than the default value of 1 is needed.

A tag (register) is defined by the following parameters:

  • id - Unique name of the tag, will be included in the message.
  • name - Optional name of the tag, will be included in the message. If not specified, 'name' will be set to 'id'.
  • modbusDataType - The type of data to read, could be one of: `Byte`, Int, UInt, String, Short, UShort, Float and Double. This setting will affect the number of bytes to read and how they should be interpreted by the module.
  • modbusFunction - Defines what function code to use (address space), could be one of ReadDiscreteInputs, ReadHoldingRegisters, ReadCoils and ReadInputRegisters.
  • address - The starting address of the data.
  • length - Integer (>=1), only used with String types to specify the number of characters to read.
  • unitId - (optional) Will override the global unitId for this tag/register.

S7 resources

S7 resources are used to specify the register mappings for different Siemens S7 PLCs. When the resource is used in the S7 Reader module, all of the listed tags will be retrieved. Additional tags can be added in the module UI. A JSON file is used to define these mappings. Any properties in addition to the default tag properties described below, will be treated as custom metadata and will be added to the messages.

Example S7 resource:

<

    {

   "name": "Conveyor belt controller",
   "tags": [
       {
           "id": "tag1",
           "name": "ValveTemp",
           "s7DataArea": "Input",
           "s7DbAddress": 0,
           "s7StartAddress": 0,
           "s7Type": "Int",
       },
       {
           "id": "tag2",
           "name": "ValveOpen",
           "s7DataArea": "Input",
           "s7DbAddress": 0,
           "s7StartAddress": 2,
           "s7BitAddress": 5,
           "s7Type": "Bool",
           "tagCount": 1,
       },
       {
           "id": "tag3",
           "name": "Machine",
           "s7DataArea": "DataBlock",
           "s7DbAddress": 0,
           "s7StartAddress": 10,
           "s7Type": "String",
           "length": 25,
       }
   ]

A S7 device (PLC) is specified as a JSON object which must have at least a name and at least one tag in the tags list.

A tag (register) is defined by the following parameters:

  • id - Unique name of the tag, will be included in the message.
  • name - Optional name of the tag, will be included in the message.
  • s7DataArea - One of Input, Output, Memory or DataBlock.
  • s7DbAddress - Integer selecting the Db (only used when s7DataArea is DataBlock).
  • s7StartAddress - Integer setting the start address within the selected data area.
  • s7BitAddress - Integer (0-7), only used with Bool types to specify the bit to use within the selected byte.
  • s7Type - The type of data to read, could be one of Bool, Byte, Word, DWord, Char, SInt, Int, DInt, USInt, UInt, UDInt, Real or String. This setting will affect the number of bytes to read and how they should be interpreted by the module.
  • length - Integer (>=1), only used with String types to specify the number of characters to read.

Rockwell resources

Rockwell resources are used to specify the register mappings for different Rockwell/Allen Bradley PLCs. When the resource is used in the Rockwell Reader module, all of the listed tags will be retrieved. Additional tags can be added in the module UI. A JSON file is used to define these mappings. Any properties in addition to the default tag properties described below, will be treated as custom metadata and will be added to the messages.

    {

   "name": "Conveyor belt controller",
   "tags": [
       {
           "RockwellTagName": "xyz123",
           "RockwellType": "real"
       },
       {
           "RockwellTagName": "xyz123",
           "RockwellType": "real",
           "name": "ValveTemp",
           "scaleFactor": 1.5
       }
   ]

A Rockwell device (PLC) is specified as an object which must have at least one tag in the tags list.

A tag (register) is defined by the following mandatory parameters:

  • RockwellTagName - The name of the tag, as defined in the PLC, will be included in the message.
  • RockwellType - Data type of the tag, as defined in the PLC. One of sint, int, dint, lint, real, lreal, bool, string. Will be included in the message.

Search Documentation

Page Sections