Skip to Content


In the past 2 blogs we have introduced the demo connector for Fischertechnik and have shown how to use it for your own custom models. In this blog post we want to show how to use the connector for a specific model, the Fischertechnik factory simulation. We use this model a lot to show demos in the space of manufacturing execution.

When you run this model, we strongly advise you to connect all five controllers using a USB cable and not using Wifi. In order to connect all controllers via USB, you need to reconfigure the TXT controllers that they all have unique IP addresses. The default IP for a connection via USB is The steps to reconfigure the controllers are not part of this blog. This is a question of network configuration on Linux.

Configuration File

The basic configuration file we have used so far has to bet extended for this model. It basically looks like this:

url = <IP address of your TXT controller>
url_1 = <IP address of your TXT controller>
url_2 = <IP address of your TXT controller>
url_3 = <IP address of your TXT controller>
url_4 = <IP address of your TXT controller>
miiUser = <ME/MII user>
miiPassword = <ME/MII password>
miiUrl = https://<ME/MII Url>
ws = wss://<endpoint of your message gateway>
token = <a_unique_string_without_spaces>
whcolumn_1 = 0
whcolumn_2 = 0
whcolumn_3 = 0
rotDiff_wh = 0
horDiff_wh = 0
rotDiff_oven = 0
rotDiff_white = 0
rotDiff_red = 0
rotDiff_blue = 0
horDiff_white = 0
horDiff_red = 0
horDiff_blue = 0
maxWhiteValue = 1280
maxRedValue = 1400
conveyerWhiteDiff = 0
conveyerRedDiff = 0
conveyerBlueDiff = 0

As you can see there are some changes to our basic configuration file. The first and very important step is to assign the right IP addresses. The parameter url needs to point to the controller which is right behind the furnace station, url_1 needs to point to the controller next to the polishing station (or drilling station), url_2 to the controller next to the color sorter, url_3 the controller next to the main crane and finally url_4 to the controller next to the warehouse. In other words, the numbering starts next to the furnace and then moves around clock-wise. It is really important to get these steps right. In the worst case, if you mix up the different controllers, then you might break something on your model.

The next three parameters are miiUser, miiPassword and miiUrl. At certain points the factory sends GET request with some URL parameters to give status updates to SAP MII. You can build diverse things on top of the status updates sent to MII, e.g. dashboards for the frontend as well as complex business flows via business logic services (BLS) in the backend. You can also tightly integrate MII with ME via BLS. For an easier setup we store the username and password as plain text in this configuration file. Of course that procedure is nowhere near close to being secure. Only use it with test users in test environments where you don’t care about security. If you don’t want to use this feature for security reasons, then just omit these parameters. The specified URL is being used to call an MII transaction which must be located in a folder fischertechnik/FactoryResponse and must be named trxFactoryStatus. With each call we pass two URL parameters, one is the token and one is the status. The parameters are called “Token” and “Status” respectively. The value for the status is a single digit number.

  • 0: called on connector startup and upon forced error (see below for more details)
  • 1: called on initialization and at the begin of each execution
  • 2: called at the beginning of each execution
  • 3: called when object is in front of oven
  • 4: called when object enters the polishing (or drilling) station
  • 5: called when object enters the color sorting station
  • 6: called when object is in the output bin after the color sorter
  • 7: called when process is complete

The URL to the MII system should not contain any part of the path to the transaction. It should be only the hostname with port and protocol: https://<host>:<port>. To simulate an error situation, you can pick up the object from the conveyor belt after the light barrier behind the color sorter. In this case the process cannot be finished and a status 0 is being sent again.

All other new parameters are calibration parameters. Each model can behave slightly different due to production tolerances. Each of the adjustment values can be positive or negative to perform adjustments in one or the other direction.

  • whcolumn_<column>¬†adjusts the crane in the warehouse to pick up the handling unit (= little black box). A positive number moves the crane farther away from the exit position.
  • rotDiff_wh adjusts the rotation of the big crane to pick up the object from the exit of the warehouse. Positive numbers let the crane rotate farther.
  • horDiff_wh adjusts how much the arm of the crane moves out to pick up the object at the warehouse. Positive values let the arm move out farther.
  • rotDiff_oven positions the large crane in front of the oven after the object has been picked up from the warehouse. Only adjust the value after you have finalized the value for rotDiff_wh. Positive values mean that the crane rotates farther away from the oven.
  • rotDiff_<color> adjusts the rotation for the crane to pickup objects after the color sorter. Where white stands for the output bin closest to the color sorter, red stands for the next output bin and blue stands for the last output bin. A positive value means that the crane rotates closer to the color sorter.
  • horDiff_<color> adjusts the horizontal movement of the crane to pickup objects after the color sorter. Positive values let the arm move out farther.
  • conveyer<color>Diff lets the conveyor belt of the color sorter move a shorter or longer period of time. Adjust if the object is not being pushed correctly to the output bin.
  • maxWhiteValue specifies the threshold whether a piece is white or not. Start with the given value. If white pieces are pushed into the red output bin, then increase the value. If red pieces are pushed into the output bin for white, then decrease the value.
  • maxRedValue specifies the threshold whether a piece is red or not. Start with the given value. If red pieces are pushed into the blue output bin, then increase the value. If blue pieces end up in the output bin for red, then decrease the value. This value should be higher than maxWhiteValue.

Keep in mind that the configuration parameters are only read on the startup of the demo connector for Fischertechnik. If you do changes, then restart the connector.

For this specific model we have two options to start it. The first option is to start the connector like you have learned in the previous blog posts.

java -jar ftconnector-<version>.jar

If you do so, the command to be sent via the websocket connection is


The values for row and column specify from where the item should be picked up in the warehouse. The value range is from 0 to 2. The value for SFC (shop floor control), shoporder and material are simple strings which are typically provided by the SAP S/4 or ME system. For the execution of the factory itself they are not relevant.

Another way to start the factory is with the following command

java -jar ftconnector-<version>.jar podmode run

In this case the factory will start to run and pick up one object after the other from the warehouse. Sometimes it is just easier to run it in this mode, for example if you want to explain some basics, or would like to do some calibration tasks and watch what parts need to get calibrated. If you want to show the tight integration into an SAP system, then use the first approach.

In addition to the status updates to SAP MII the factory publishes updates on the web socket endpoints. The JSON object published to that endpoint looks like this:


For these messages the type parameter is always set to ui5Status. As you can see in the above JSON, you get percentage values on the status of the different operations. For each of these operations different states are possible. The states can be planned, neutral, positive and negative. It is generally safe to assume that the positive state value is the difference of 100 and the sum of the states planned and neutral. The negative state is usually 0. The exception to this rule is the state for assembly. As written earlier you can simulate an error situation and that is why for this operation a value for the negative state is given. Moreover the factory reports on what sfc, shoporder and material it is working. These are the values provided with the startFactory JSON file, as explained above.


When we show this demo, we have for example built the following dashboard:

At the top of the screen you see the information about what material, shop order and SFC are currently in process. Below that, you see the process flow and where in the process we are. The first two steps have a full green circle, thus they have the state positive set to 100%. The next step, polishing, is half green and half grey. Its status is 50% positive and 50% neutral, meaning that the operation is half done. The last two operations are both 100% planned, which means they have not yet started. At the bottom you see some analytics. On the left you see how many bearings (in our scenario the wooden objects are bearings) have been produced. On the right you see a temperature chart for the furnace. These values are simulated, but you notice the hump in the chart, corresponding to the time when the bearing is inside the furnace. This means that we can act on the sensor data, in this case the sensors tell us that the piece is in the oven or outside of the oven.

Have fun with your demo connector for Fischertechnik. If you use it to build cool scenarios and integrate models with SAP software, please post them on SCN.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply