General

Which Protocols are available?

The System-on-Module inherits most of the available industrial protocols from GOAL. The available protocols are: Profinet, EtherNet/IP, EtherCAT, Modbus/TCP. Beside that, the System-on-Modue contains HTTP, Webserver and UDP/TCP functionality. The Protocols can be activated at startup by the attached application controller. After a reset, the started protocol can be changed.

Can the System-on-Module act as a Gateway?

It is not possible to start multiple industrial procotols at the SoM at the same time. However, it might be possible to realise very basic Gateways like Modbus - Profinet, if the application controller acts as a Modbus device, controlling the SoM via SPI to get process data from the Profinet fieldbus.

Are there additional costs using the System-on-Module?

The SoM uses port’s GOAL Source Code for all included industrial ethernet protocols. This is paid for with obtaining the module. However, if you sell your final product containing the SoM, you may need a membership at the protocol-specific user organisation.

Do I need to certify my application?

The System-on-Module is pre-certified or at least tested for compliance with the provided basic example applications for each industrial protocol. However, Your created application in combination with your used hardware must be certified as a final product - We’re happy to help you with a pre-certification in-house test with the official test equipment.

How do I get the Software?

The firmware for the System-on-module is provided as binary file. We do provide updated firmware container at regular intervals to keep the SoM compliant with the latest specification of the supported industrial protocols.

The GOAL / uGOAL Software package for the application controller is provided as source and must be compiled and flashed to the desired controller.

Application Controller Integration

What is a typical work load on the application controller?

The application controller could act as a sensor providing values via SPI to the System-on-Module, which handles the fieldbus communication. Due to the splitted cores, the requirements to the application controller are quite low.

Please refer to Getting Started for an example.

What is the possible minimum cycle time on the SPI interface?

The SPI interface supports clock rates between 29.3 kHz and theretically up to 20 MHz, depending on the used hardware. The module depends on constant cyclic requests, thus a slow SPI clock (< 2 MHz) rate might decrease the performance.

What are typical firmware footprints for the application controller?

This depends on the used platform and GOAL or uGOAL configuration. uGOAL reserves a large memory block for it's heap implementation, which is configured at compile time usingCONFIG_UGOAL_HEAP_BUFFER_SIZE.

Is an operating system required?

No, the software packages for the application controller operates with or without an operating system. The software delivery does not specifically consider issues of multi tasking systems. Thus if one wants to integration the code into a multitasking application, all uGOAL relevant functions should be concentrated and called from one single task. Data exchange with other tasks should be done in a protected way (locking, messages, semaphores, queues).

Does the software package implement a watchdog functionality?

The software on the communication controller implements a watchdog for the internal functionality. It watches execution times of critical routines and restarts the module of those checks fail. Beside that a separate watchdog functionality is implemented checking the SPI interface.

Once a cyclic communication on the SPI Interface is established, a timeout detection is activated. This timeout closes any cyclic fieldbus connections and sets an error. Timeout is detected after 1 second of inactivity.

This timeout can be deactivated for debugging purposes.

Can I use another application controller?

The GOAL and uGOAL software packages support many platforms. It is also possible, to port the software package to your own CPU / platform. Please refer to our application note for uGOAL specific portations.

Application

How do I create my own application?

The GOAL and uGOAL Software packages contain several pre-built examples for basic application using Profinet, EtherNet/IP, EtherCAT, Modbus/TCP et cetera. Feel free to use on of our provided examples as a starting point for your example.

We also provide the Industrial Communication Creator for comfortable and easy configuration and object dictionary management.

Device does not switch from DHCP to static IP configuration

If the switch between static IP configuration and DHCP fails after reboot, please check the follow CM variables using the Industrial Communication Explorer: 

To disable DHCP, set the variable DHCP_ENABLED to 0. Make sure variable VALID is set to 1. Upload these settings to the module and save those values permanently. After a reboot DHCP should be disabled. 

EtherCAT EoE is not working as expected

Please make sure that the fallback Ethernet activation, which is configured using the following CM variable, does not interfere with starting of the EtherCAT stack:

EoE will only work if the EtherCAT stack is up and running before the fallback Ethernet activation is executed. Using the provided CM variable the timeout can be configured in seconds.

Is there logging at the Synergy S7G2SK board?

The Synergy S7G2SK board provides a UART on header J10. In order to use the UART, make sure J9 is set correctly. Pins 1-3 and 2-4 must be connected. Please refer to the Boards user manual for correct settings. UART is available at J10, where Pin 1 is connected to RX and Pin 4 is conntected to TX of the Synergy CPU.

Hardware

The LEDs on the adapter shield seem to be inverted

There are multiple versions of LED driver built on top of the shield. Set the compiler define GOAL_CONFIG_PLAT_DRV_LED_IIC_PCA9552 1 at goal_config.h to invert the signals.

How are the LEDs controlled by the SoM module?

The SoM module does not provide visual indication of the stack. The respective information are available in the cyclic communication channel and can be mapped by the application. The corresponding LED states are coded in the "Generic data provider", where logical LED signals are available to be mapped to physical LEDs by the Application controller. For the reference design of the Arduino shield these LEDs are controlled using the I2C interface of the CPU.

How to connect the LEDs for link and activity

Here it depends on the network socket used and the LEDs installed in it. On our ARDUINO Shield Board the cathode of the Ethernet port LEDs is directly connected to the pin header J302 of the SoM. This connects the activity and link signals directly to the integrated PHY's via a 22 Ohm series resistor. The anodes are each connected to 3.3V DC with a 220 Ohm resistor.

Is the shield connection earthed?

Pin 23 on J301 (Shield) must not be connected to ground potential of the module. The decoupling of the shielding is integrated on the SoM. We recommend a minimum distance of 2 mm between shield and logic and supply voltage potential.

Do the inputs of the module need any pull-up or pull-down resistors?

The SoM has an internal pull-up of the reset line. This reset signal on J202 pin 4 is low active.

What are the two signals CATSYNC0/1 for?

CATSYNC0/1 are protocol specific signals for EtherCAT. Both signals are also internally provided with a 22 Ohm series resistor for current limitation. These signals belong to EtherCAT DC, for the generation of an EtherCAT network-wide synchronous pulse, e.g. for axis synchronization. These signals are currently intended as output and are only available for EtherCAT. Without EtherCAT they are unused and do not need to be wired.