sysmik Scalibur SCA-340, Manual, Page: 47 / 58

Best Practices and Troubleshooting
Manual SCA-340 / SCA-340-L sysmik.de 47
Diagnosis
The available resources can be shown in Workbench using all accesses:

Platform:
Platform Administration

Station:
Views

Resource Manager

Sedona: App

service

plat (see [4])
Note: The system load should be below 100 %, because otherwise the relevant timing (cycle
times) can’t be ensured. Optimize in this case your application, i.e. by increasing Sedona
task cycle time or intervals of the Niagara station (e.g. poll intervals). Please be aware that
every kind of communication creates processor load, too – so leave a margin for that.
5.2 Reliability of Nonvolatile Memory
Scalibur contains a highly integrated Flash memory for use in the industrial
temperature range. Physically caused, the reliability is depending on the number of
writes and the environmental temperature: frequent writing of large data blocks
wears out the memory and a high environmental temperature reduces the
guaranteed data retention time.
The stress on the memory depends heavily on the application. Occasional write
accesses due to programming and software upgrades cause writing of large data
blocks to the Flash. However, these are almost negligible in comparison to the
amount of data which is written in regular intervals, like logging of history data or
StationSave
.
The write load caused by history data can be shown via
Station

Config

Services

PlatformServices

DataRecoveryService
.
Size and write frequency of history data should be configured in such a way, that
writing of a data recovery block happens less than once a minute.
StationSave
should be performed much less than once per hour.
Regarding the environmental temperature, the defined maximum values in chapter
Fehler! Verweisquelle konnte nicht gefunden werden.
must not be exceeded
and the mounting position has to be observed (see chapter 3.1.2).
5.3 Diagnosis and Troubleshooting
Scalibur is a very complex device with many functions and interfaces. This
complexity leads to many possible misconfigurations in practical use. Most mistakes
arise from connections with other devices or components. Therefore the controller
should not be diagnosed isolated, but in context with the complete system.
Several tools allow to locate possible reasons for failures:

power LEDs (see 3.3.2)

software status LEDs (see 3.3.3)

IO status LED (see 3.3.4)

communication LEDs (see 3.3.5)

diagnosis LEDs of the connected IO terminals

Service LED (see 3.3.6)

Ethernet status LEDs (see 3.3.7)