Technical Information: STARDOM Troubleshooting Guide: Information Analysis TI 34P02K03-03E

Technical STARDOM Troubleshooting Guide:
Information Information Analysis

TI 34P02K03-03E
TI 34P02K03-03E
8th Edition Jan. 22, 2019 (YK)
Blank Page
i
Introduction
This guide describes how to analyze system information when troubleshooting
system problems, which may occur during operation of a STARDOM-based
system. It is written for engineers responsible for engineering and maintenance of
STARDOM systems.
It also describes how to design systems to avoid problems in future operation
and is thus useful in the system design phase.
This documentation assumes that the reader has basic knowledge of system
management of the Windows operating system (hereinafter abbreviated as
Windows).
Engineering Workflow
System Design
Unit & Integration Test
System Tuning
System Operation &

Maintenance
Figure STARDOM System Engineering Flowchart
The above figure shows the standard engineering workflow. This document describes
precautions in system design, a checklist for system tuning and how to analyze
problems in system operation and maintenance for FCN/FCJ (R1.70 or later version).
Refer this document during application design to avoid problems in future operation, and
refer it during system tuning and system operation to troubleshoot problems.
TI 34P02K03-03E 6th Edition: May 31, 2017-00

ii
IMPORTANT
In this manual, the term “FCN/FCJ” refers to FCN-500, FCN-100, FCN-RTU, and FCJ
autonomous controllers.
- The term “FCN-500” refers to the autonomous controllers with NFCP501/NFCP502
CPU module.
- The term “FCN-100” refers to the autonomous controllers with NFCP100 CPU
module.
- The term “FCN-RTU” refers to the low power autonomous controllers with
NFCP050 CPU module.
- The term “FCJ” refers to the all-in-one type autonomous controllers.
■ Organization of This Manual

This document consists of the following chapters.
Chapter 1 FCN/FCJSystem
The chapter describes how to analyze system information when troubleshooting
FCN/FCJ system problems.
For details on how to gather information required for problem analysis when a system
problem occurs, see “STARDOM Troubleshooting Guide: Information Gathering”
(TI34P02K03-02E).

iii
Copyright and Trademark Notices

■ All Rights Reserved
The copyrights of this document belong to Yokogawa Electric Corporation.
No part of this document may be transferred, sold, distributed (including delivery via a
commercial PC network or the like), or registered or recorded on videotapes.
■ Trademark and License Software

- STARDOM is a trademark of Yokogawa.
- Company names, product names included in this document are trademarks or
registered trademarks of their respective owners.
- Registered trademarks or trademarks are not denoted with the ‘TM’ or ‘®’ mark in
this document.

Blank Page
v
STARDOM Troubleshooting Guide:

Information Analysis
TI 34P02K03-03E 8th Edtion
CONTENTS
Introduction ................................................................................................i
Copyright and Trademark Notices .........................................................iii
CONTENTS ................................................................................................v
1. FCN/FCJ System ..............................................................................1
1.1 Analyzing Revision Information ............................................................... 1
1.1.1 Type and Version of Windows OS on PC ....................................... 1
1.1.2 Revisions of FCN/FCJ, Development and Maintenance Tools ....... 2
1.2 Analyzing LED States ................................................................................ 3
1.2.1 Analyzing States of LEDs of Power Supply Module ....................... 3
1.2.2 Analyzing Operating Status LEDs of FCN/FCJ ............................... 5
1.2.3 Analyzing Communication Status LEDs of FCN/FCJ .................... 11
1.2.4 Analyzing Status LEDs of I/O Modules ......................................... 12
1.2.5 Analyzing Status LEDs of SB Bus Repeat Module ....................... 13
1.2.6 Analyzing Status LEDs of Serial Communication Module ............ 14
1.2.7 Analyzing Status LEDs of FOUNDATION Fieldbus
Communication Module ................................................................ 15
1.2.8 Analyzing Status LEDs of CANopen Communication Module ...... 16
1.2.9 Analyzing Status LEDs of PROFIBUS-DP Communication
Module ........................................................................................ 17
1.2.10 Analyzing Status LEDs of Serial Communication Port on CPU
Module for FCN-RTU .................................................................... 18
1.3 Analyzing CPU Status ............................................................................. 19
1.3.1 Execution Duration of Tasks ......................................................... 19
1.3.2 Analyzing CPU Load ..................................................................... 21
1.3.3 Watchdog Timer Error ................................................................... 23
1.3.4 CPU Overload ............................................................................... 25
1.4 Logic Designer Information .................................................................... 27
1.4.1 Analyzing Data of System Global Variables .................................. 27
1.4.2 POU Error Information .................................................................. 30
1.4.3 Analyzing Logic Designer Log Data .............................................. 30
1.5 Analyzing Resource Configurator Information .................................... 31
1.5.1 Basic Settings of CPU Module ...................................................... 31
1.5.2 License Information on System Card ............................................ 33
1.5.3 Analyzing RAS Information ........................................................... 35
1.5.4 Project Information ........................................................................ 37
1.5.5 Resource Configurator Definitions ................................................ 38
1.5.6 Analyzing Loop Check Tool Information........................................ 39
TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

vi
1.6 Analyzing Information from Maintenance Page ................................... 41
1.6.1 Analyzing Information on the Top Page ........................................ 41
1.6.2 Analyzing FCN/FCJ Log Data ....................................................... 41
1.6.3 Analyzing Date and Time Information of FCN/FCJ ....................... 45
1.7 Problem Analysis Using Remote Shell (FcxRsh) Software Tool ........ 46
1.7.1 Description of Remote Shell (FcxRsh) Software Tool ................... 46
1.7.2 Getting Remote Shell (FcxRsh) Software Tool ............................. 46
1.7.3 Executing Remote Shell (FcxRsh) Software Tool ......................... 47
1.8 Case Analysis of FCN/FCJ Problems .................................................... 54
1.8.1 Case Analysis: Retained Data Related Problems ......................... 54
1.8.2 Case Analysis: I/O Signal Related Problems ................................ 56
1.8.3 Case Analysis: Time Measurement Related Problems ................. 57
1.8.4 Heart Beat Timeout Error .............................................................. 58
1.8.5 MISCMP Error ............................................................................... 60
1.8.6 Communication Failure between FCN/FCJ and PC ..................... 63
Appendix A. Performance Data......................................................67
Appendix A.1 Estimating Communication Time .............................................. 67
Revision Information .................................................................................i

<1. FCN/FCJ System> 1
1. FCN/FCJ System
1.1 Analyzing Revision Information
1.1.1 Type and Version of Windows OS on PC
The PC system prerequisites for installing various software tools required for
FCN/FCJ development and maintenance are described in the relevant IM and GS
documents.
Verify that the Windows operating system version, the CPU and the memory of the
PC satisfy the operating environment prerequisites of the software tools.
● Documents describing PC operating environment prerequisites

- “STARDOM FCN/FCJ Guide” (IM 34P02Q01-01E)
- “NT751FJ Logic Designer” (GS 34P02Q75-01E)
Check the PC operating environment prerequisites using the latest versions of the IM
and GS documents.
● FCN/FCJ development/maintenance tools and APPFs

- Resource Configurator
- Logic Designer
- FCN/FCJ Simulator
- PAS Portfolio
- Other APPFs (application portfolios)

1.1.2 Revisions of FCN/FCJ, Development and

Maintenance Tools
Check the revision of the FCN/FCJ Basic Software, the revision of each development/
maintenance tool and the revision of each APPF.
● All latest versions of software

If the FCN/FCJ Basic Software, development/maintenance tools and APPFs are all of
the latest versions, all released functions can be used.
● Different versions of software

If the FCN/FCJ Basic Software, individual development/maintenance tools and APPFs
are of different versions, depending on the version combinations, some functions may
fail to work properly, Logic Designer compilation errors may be reported or other
problems may arise.
Examples:
- A project using NPAS_POU is downloaded to FCN/FCJ R1.40
As FCN/FCJ R1.40 does not support NPAS_POU, a PLC error will be reported.
- A new project created using Logic Designer R1.86 cannot be downloaded online
to FCN/FCJ R1.60
The online download function is supported on R1.70 and later versions. Although
the Logic Designer is of R1.86 version, the FCN/FCJ is R1.60 so online
downloading dose not work.

1.2 Analyzing LED States

1.2.1 Analyzing States of LEDs of Power Supply Module
There are two LEDs (SYS, FLD) located on the upper part of the front panel of the
power supply module of the FCN. These LEDs, when lit, have the following respective
meanings:
- SYS LED: 5.1V system power supply is supplied
- FLD LED: 24V analog field power supply is supplied
● 5V system power supply

There are three types of power supply modules:
- NFPW441: 100 to 120 VAC input
- NFPW442: 220 to 240 VAC input
- NFPW444: 24 VDC input
- NFPW426: 5VDC input
Whichever power supply module is used, its input supply is always converted to 5.1 V
DC. The SYS LED of the power supply module indicates the status of the power
supply after conversion to 5.1 V DC.
If the input power to the power supply module is abnormal, the SYS LED goes off.
Even if the input power to the power supply module is normal, if the 5.1 VDC power
supply is abnormal due to, an internal fault of the power supply module, the SYS LED
goes off.
● 24V analog field power supply

The 24V analog field power supply is required for supplying power to the field signal
interface circuit of some I/O modules and field devices. The FLD LED indicates the
status of this 24V analog field power supply.
The table below lists some I/O modules that require 24V analog field power supply.
Table I/O Modules that Require 24V Analog Field Power Supply
Model name Function
NFAI141 16 points, current input (when using 2-wire system)
NFAI143 16 points, current input
NFAI841 8/8 points current I/O

NFAI135 8 points, current input
NFAI835 4/4 points, current input/current output

NFAI543 16 points, current output
NFAP135 8 points, pulse input
NFAB841 8/8 points, voltage input/current output
Note: If no 24 V analog field power is supplied, these I/O modules will report IOP and OOP alarms and fail to operate
normally.

The rated current output of the 24V analog field power supply is 4A so the total 24V
DC current consumption of all analog I/O modules must not exceed 4A.
If the total current consumption exceeds 4A, the I/O modules will fail to operate
normally but the FLD LED will remain lit. Thus, the FLD LED only indicates whether
24 V analog field power is supplied regardless of whether the current consumption
exceeds the rated maximum current.
● Operation when using duplexed power supply modules

A duplexed power supply consists of two parallel power supply modules, each
provided with a backflow preventer diode so that power will be supplied to the internal
circuit as long as one of the two power supply modules is working.

1.2.2 Analyzing Operating Status LEDs of FCN/FCJ

Three LEDs (HRDY, RDY and CTRL) for indicating the operating status of the
FCN/FCJ are located above the CPU module of an FCN, and on the front panel of an
FCJ.
For more details on the LEDs of the FCN/FCJ, you may also see the following IM and
online help documentation.
- “STARDOM FCN/FCJ Guide” (IM 34P02Q01-01E)
Section B1.5, “Operation Status of FCN/FCJ Autonomous Controllers”
- Online help documentation of Resource Configurator:
FCN/FCJ Maintenance – FCN/FCJ Operation (Status Transition and LED
Lighting)

● FCN/FCJ operating status versus LED states

Each of the HRDY, RDY and CTRL LEDs has four states:
- on
- off
- slow blink: lit for one second and off for one second periodically
- fast blink: lit for 100 ms and off for 100 ms periodically
The table below maps operating states of the FCN/FCJ to display patterns of the
HRDY, RDY and CTRL LEDs.
If the LEDs display a pattern that is not listed in the table below, it may be due to
incorrect DIP switch setting on the base module or an FCN/FCJ system failure.
Table FCN/FCJ Operating States versus LED States

FCN/FCJ State HRDY RDY CTRL State Description
Online state, task execution (for single On On On Normal operation
CPU FCN, control-side CPU of duplex
FCN, or FCJ)
Online state, task stop (for single CPU On On Slow The task was successfully stopped, or the
FCN, control-side CPU of duplex FCN, or blink task was stopped because there is no
FCJ) project.
Online state, task irregular stop (for single On On Fast The task was stopped by the exception.
CPU FCN, control-side CPU of duplex blink
FCN, or FCJ)
Online state (for standby-side CPU of On On Off Normal operation
duplex FCN)
IP address setup state Fast Slow Off IP address setup is allowed in this state.
blink blink
Maintenance state Slow On Off FCN/FCJ maintenance (e.g. configuration)

blink is allowed, OS functions run but control
applications stop running.
APC running state, task execution (control Fast On On Contents of the control CPU of a duplex
CPU) blink FCN is being copied to the standby CPU.
APC running state, task stop (control Fast On Slow
CPU) blink blink
APC running state, task irregular stop Fast On Fast
(control CPU) blink blink
APC running state (standby CPU) Fast Fast Off
blink blink
APC waiting state (standby CPU) On Fast Off Waiting for APC startup request
blink
Ready for power down state or system Off Off Off The FCN/FCJ can be safely powered down
down state or the FCN/FCJ has encountered a failure
and is down.
Boot mode selection state Fast Fast Off Allows selection of the boot mode from IP
blink blink address setup, maintenance and online
states using the Shutdown switch. The
system stays in this state for 3 seconds
before transiting to loading state.
Loading state On Slow Off The operating system is being loaded into
blink memory.
Loading completed state On On Off FCN/FCJ startup is in progress.

● LED display under normal operation

When an FCN/FCJ is operating normally, the LED display indicates an online state as
shown in the table above.
Online state only means that the operating system is running. The LED display
indicates an online state even in the presence of a watchdog timeout error, CPU
overflow error or PLC error.

● Analyzing LED display patterns

If the LEDs display a pattern that is not listed in the preceding table, consider the
following causes.
- A system failure has occurred.

The FCN/FCJ has encountered an internal failure and cannot operate normally.
- The DIP switch settings of the base module of the FCN are invalid.
The base module of the FCN has two DIP switches: unit number setting and
duplex CPU module setting.
If any of these settings are invalid, the FCN cannot operate normally and the
LED display will appear strange.
Examples of invalid DIP switch settings:

- A base module is configured as unit 2 using the DIP switch but is installed with a
CPU module.
- The base module is configured as an extension unit but is used as a control unit.
- A base module is configured as a single CPU system using the DIP switch but is
installed with two CPU modules.
● LED display of duplex FCNs

The table below lists is an example of LED display patterns and operating states
under non-error conditions on condition that duplex FCN system with the left CPU as
the control CPU and the right CPU as the standby CPU. The operating status of the
system for each pattern is described in detail on subsequent pages.
Table LED Display of Duplex FCN

Left CPU Right CPU
Operating Operating
[HRDY] [RDY] [CTRL] [HRDY] [RDY] [CTRL]
Status Status
Pattern 1 Lit Lit Lit Online state Lit Lit Off Online state
Pattern 2 Lit Lit Lit Online state Lit Fast blink Off APC waiting state
Ready for power
Pattern 3 Lit Lit Lit Online state Off Off Off
off state
Pattern 4 Lit Lit Off Online state Lit Lit Lit Online state
APC waiting
Pattern 5 Lit Fast blink Off Lit Lit Lit Online state
state
Ready for power
Pattern 6 Off Off Off Lit Lit Lit Online state
off state
- Pattern 1
This is the normal operating state where the left CPU has control in online state while
the right CPU is in standby online state.

- Pattern 2
In this state, the left CPU has control in online state, while the right CPU is in APC
waiting state.
This state happens if the standby (right) CPU goes down but as its failure is
recognized as transient, the CPU restarts and boots up in APC waiting state.
It may also happen if the right CPU is restarted but APC is not executed or APC
execution fails once.
- Pattern 3
In this state, the left CPU has control in online state, while the right CPU is in ready-
for-power-down state.
This state happens if the right CPU goes down twice within a week and does not
restart because the failure is recognized as an CPU failure.
It may also happen if the right CPU fails to restart after going down or if APC fails
twice consecutively.
- Pattern 4
In this state, the right CPU, which was previously the standby CPU, takes control in
online state while the left CPU, which was previously the control CPU, enters online
standby state.
This state happens if the left control CPU goes down, control is switched to the right
CPU, and APC is executed.
- Pattern 5
online state while the left CPU, which was previously the control CPU, enters APC
waiting state.
This state happens if the left control CPU goes down, control is switched to the right
CPU, the left CPU restarts as its failure is recognized as transient and it boots up in
APC waiting state.
It may also happen if the left CPU is restarted but APC is not executed or APC fails
once.
- Pattern 6
online state, while the left CPU, which was previously the control CPU, enters ready-
for-power-down state.
This state happens if the left CPU goes down twice within a week and does not restart
because the failure is recognized as an CPU failure, or the left CPU fails to restart
after going down or if APC fails twice consecutively.

● Analyzing FCN/FCJ boot failures

1. Monitor FCN/FCJ boot process
When the FCN/FCJ boots up due to power on or a reset operation, it transits
from ready-for-power-down state to online state. The state transition conditions
and the changes in the LED display during boot up are described in the IM and
online help documentation mentioned earlier.
If the FCN/FCJ fails to boot up, activate the boot up process by powering down
and then powering up the FCN/FCJ or by pressing the RESET push button.
By monitoring the changes of the LED display, you can determine the stage at
which boot up was aborted and thus identify possible causes of the failure.
2. Check power supply to CPU

By checking the communication status LEDs of the FCN/FCJ as described in
Section 1.2.3, you can verify whether power is supplied to the CPU of the
FCN/FCJ.
If the FCN/FCJ fails to boot up despite power being supplied, it may be due to an
internal FCN/FCJ failure or system card failure.
If no power is supplied to the CPU despite the LED of the power supply module
indicating normal status, it may be due to a failure in the power supply system.

1.2.3 Analyzing Communication Status LEDs of FCN/FCJ

There are two LEDS located at the network interface (LAN port) of the FCN-500,
FCN-100 and FCJ, namely, a green LINK LED and an orange ACT LED. These LEDs
indicate the following status when they are lit:
LINK : Lit when the connection to a hub is normal

ACT : Blink when the transmission/reception is on
There are two LEDS located at the network interface (LAN port) of the FCN-RTU,
namely, a green ON LED and a green LINK&ACT LED LED. These LEDs indicate the
following status when they are lit:
ON : Lit when the network function is enabled

Off when the network function is disabled
LINK&ACT: Lit when the connection to a hub is normal
Blink when the transmission/reception is on
If the LINK LED is off, check the following items:
- Power supply status of the FCN/FCJ

See Section 1.2.1, “Analyzing States of LEDs of Power Supply Module”
- Power supply and operating status of connected devices
- LAN cable
Verify that the cable type (straight or cross) is correct, the cable is not broken and
connection is proper.
● Checking status of power supply to FCN/FCJ

You can check the status of the power supply to the FCN/FCJ using the LINK LED of
the LAN port of the FCN/FCJ.
If the FCN/FCJ is properly connected to a hub and the connected hub is operating
normally, the LINK LED will be lit so long as power is supplied to the CPU of the
FCN/FCJ regardless of the operating status of the FCN/FCJ.
If the LINK LED is off despite connection being normal, it means that no power is
supplied to individual CPU cards.

1.2.4 Analyzing Status LEDs of I/O Modules

Three LEDs (STATUS, ACT, DX) for indicating the status of an I/O module are located
on the upper part of the front panel of the I/O module.
These LEDs indicate the following status when they are lit:
STATUS : Lit when the hardware is normal
ACT : Lit when I/O actions are carried out
DX : Always off (not used)
● States of STATUS LED

When an I/O module is operating normally, its STATUS LED is lit regardless of
whether the module is defined in Resource Configurator. The STATUS LED is off only
when the I/O module is not operating normally due to some failure.
Therefore, if the STATUS LED is off, you can conclude that there is an I/O module
failure.
● States of ACT LED

When I/O actions are carried out, the ACT LED is lit and I/O values are updated.
If the ACT LED is off, it means that I/O actions are not carried out. (For some I/O
cards, this may indicate that 24V external field power is not supplied.)
The conditions listed below must be fulfilled for I/O actions to be carried out.
Therefore, if the ACT LED is off, check the following conditions first. (The ACT LED,
once lit, remains lit even if I/O actions cease to be carried out.)
- Verify that definition data has been downloaded from Resource

Configurator
Verify that definition data has been downloaded to the I/O module from Resource
Configurator. For details on how to do so, see Section 1.4.1, “Analyzing Data of
System Global Variables.”
In addition, ensure that device label names in the definition data are identical to
device label names defined in Logic Designer.
- Verify that I/O is not disconnected by Logic Designer

If I/O is disconnected and the FCN is rebooted, the CPU module of the FCN will
not communicate with I/O modules so I/O actions are not performed.

1.2.5 Analyzing Status LEDs of SB Bus Repeat Module

Three LEDs (STATUS, SND, and RCV) for indicating operating status and
communication status of the SB bus are located on the upper part of the front panel of
the SB bus repeat module.
These LEDs indicate the following status when they are lit:
STATUS : Lit when hardware is normal

SND : Lit when sending data
RCV : Lit when receiving data
The STATUS LED is lit when the SB bus repeat module is operating normally. If the
STATUS LED is off, it means that the SB bus repeat module has encountered a
failure.
The SND and RCV LEDs are lit when the module is sending and receiving data
respectively. In practice, as data transmission and receiving are intermittent, the SND
and RCV LEDs blink.
If the SND and RCV LED do not blink despite the STATUS LED being lit, check the
following items.
- Unit number setting of base module

The unit number hardware switch of a base module is set to 1 at the factory. If a
base module is used as an extension unit, verify that its unit number switch is set
to unit 2 or unit 3.
- Condition of SB bus cable

Check the integrity of the SB bus cable by exchanging the cable with the cable of
another SB bus repeat module that is operating normally and see whether the
problem disappears.
- Installed slot of SB bus repeat module

Verify that the SB bus repeat module is installed in a proper slot.
For a single SB bus configuration, the SB bus module must be installed in slot
10. For a duplex configuration, the SB bus modules must be installed in slots 9
and 10. An SB bus module will not operate if installed in any other slot.
- Duplex setting of SB bus

Single/duplex configuration of the SB bus is carried out using Resource
Configurator. If configured as a single SB Bus, an SB bus repeat module will not
operate if it is installed in slot 9.

1.2.6 Analyzing Status LEDs of Serial Communication

Module
There are three LEDs (STATUS, ACT, DX) for indicating the status of a serial
communication module (NFLR111 or NFLR121), and four LEDs (SND1, RCV1, SND2,
RCV2) for indicating the communication status of its two ports. The LEDs are located
on the upper part of the front panel of the module. These LEDs indicate the following
status when lit.
SND1 : Lit when sending data via port 1
RCV1 : Lit when receiving data via port 1
SND2 : Lit when sending data via port 2
RCV2 : Lit when receiving data via port 2
The STATUS, ACT and DX LEDs of a serial communication module operate the same
way as those of an I/O module. For details, see Section 1.2.4, “Analyzing Status
LEDs of I/O Modules.”
and RCV LEDs blink.
If the SND and RCV LED do not blink despite the STATUS and ACT LED being lit,
perform the following checks.
- Check cable specification

Check the pin assignments and type of cables.
- Check transmission settings of each port

Check the transfer specification, wiring system, transmission mode, baud rate and
other settings of each port using Resource Configurator.
- Check communication applications

Check no error was occurred in application on Logic Designer.
- Check results of communication trace

Trace communications using the Remote Shell software tool as described in Section
1.7.3 and check the trace results.
TIP
The RCV LED of an NFLR121 module may be lit when sending data on 2-wire communication.

1.2.7 Analyzing Status LEDs of FOUNDATION Fieldbus

Communication Module
There are three LEDs (STATUS, ACT, DX) for indicating the status of a serial
communication module (NFLR111 or NFLR121), and eight LEDs (RCV1 to 4, SND1 to
4) for indicating the communication status of its four ports. The LEDs are located on
the upper part of the front panel of the module. These LEDs indicate the following
status when lit.
DX : Lit when the module is duplexed
SND1 to 4 : Lit when sending data via port 1 to 4
RCV1 to 4 : Lit when receiving data via port 1 to 4
The STATUS and ACT LEDs of a serial communication module operate the same way
as those of an I/O module. For details, see Section 1.2.4, “Analyzing Status LEDs of
I/O Modules. The DX LED is lit when used as a duplex pair of NFLF111 modules.
TIP
The FCN-RTU does not support duplexed FOUNDATION fieldbus communication modules.
and RCV LEDs blink. If the SND and RCV LED do not blink despite the STATUS and
ACT LED being lit, perform the following checks.
- Check the wiring and type of cables

Check the type of cable and terminator and wiring.

Check master (NFLF111) and slave device configuration on Resource Configurator
and FF Configurator.
- Check system alarm and communication error

Check system alarm and communication error from FOUNDATION Fieldbus
communication module (NFLF111). For details, see the “FOUNDATION Fieldbus
communication” (IM 34P02Q52-02E).


1.2.8 Analyzing Status LEDs of CANopen Communication

Module
There are three LEDs (STATUS, ACT, DX) for indicating the status of a CANopen
communication module (NFLC121), and two LEDs (RUN, COM) for indicating the
communication status of its one ports. The LEDs are located on the upper part of the
front panel of the module. These LEDs indicate the following status when lit.
ACT : Lit when the module is running normally
RUN : Lights when the communication function is ready and normal.
Flashes when the communication function is being started.
COM : Lights in OPERATIONAL state. Flashes (200ms ON / 200ms OFF) in
PRE-OPERATIONAL state. Flashes (200ms ON / 1000ms OFF) in
STOPPED state.
way as those of an I/O module. For details, see Section 1.2.4, “Analyzing Status
LEDs of I/O Modules.”
When an I/O module is operating normally, its COM LED is lit regardless of whether
the module is defined in Resource Configurator. The COM LED is off only when the
I/O module is not operating normally due to some failure. Therefore, if the COM LED
is off, you can conclude that there is an I/O module failure.
The COM LED is lit when the module is sending and receiving data respectively.
If the COM LED do not lit despite the STATUS and ACT LED being lit, perform the
following checks.
- Check cable and terminator specification

Check the type of cable and terminator

Check master (NFLC121) and slave device configuration on CANopen Configurator.

Check system alarm and communication error from CANopen communication module
(NFLC121). For details, see the “CANopen communication”(IM 34P02Q58-01E).


1.2.9 Analyzing Status LEDs of PROFIBUS-DP

Communication Module
There are three LEDs (STATUS, ACT, DX) for indicating the status of a PROFIBUS-
DP communication module (NFLP121), and two LEDs (RUN, COM) for indicating the
communication status of its one ports. The LEDs are located on the upper part of the
front panel of the module. These LEDs indicate the following status when lit.
ACT : Lit when the module is running normally
RUN : Lights when the communication function is ready and normal.
Flashes when the communication function is being started.
COM : Lights when communication is established.(*1) Flashes periodically
when configuration by PROFIBUS-DP Configurator is completed and
system is waiting for instruction to start bus communication. Flashes
randomly when configuration by PROFIBUS-DP Configurator is
underway.
*1: If any of the slave devices defined using PROFIBUS-DP Configurator is disconnected, the COM LED is off.
way as those of an I/O module. For details, see Section 1.2.4, “Analyzing Status LEDs
of I/O Modules.”
When an I/O module is operating normally, its COM LED is lit regardless of whether
the module is defined in Resource Configurator. The COM LED is off only when the
I/O module is not operating normally due to some failure. Therefore, if the COM LED
is off, you can conclude that there is an I/O module failure.
The COM LED is lit when all of the slave devices defined using PROFIBUS-DP
Configurator is sending and receiving data respectively.
If the COM LED do not lit despite the STATUS and ACT LED being lit, perform the
following checks.
- Check cable and terminator specification

Check the type of cable and terminator

Check master (NFLP121) and slave device configuration on PROFIBUS-DP
Configurator.

Check system alarm and communication error from PROFIBUS-DP communication
module (NFLP121). For details, see the “PROFIBUS-DP communication”
(IM 34P02Q57-01E).


1.2.10 Analyzing Status LEDs of Serial Communication

Port on CPU Module for FCN-RTU
There are three LEDs (HRDY, RDY, CTRL) for indicating the status of a CPU module,
and eight LEDs (SND1 to SND4, RCV1 to RCV4) for indicating the communication
status of its four ports on CPU module (NFCP050) for FCN-RTU. These LEDs
indicate the following status when lit.
SND1 to SND4 : Lit when sending data via port 1 to 4
RCV1 to RCV4 : Lit when receiving data via port 1 to 4
and RCV LEDs blink.
If the SND and RCV LED do not blink despite the HRDY, RDY and CTRL LED being
lit, perform the following checks.
- Check cable specification

Check the pin assignments and type of cables.

Check the transfer specification, wiring system, transmission mode, baud rate and
other settings of each port using Resource Configurator.

- Check results of communication trace

Trace communications using the Remote Shell software tool as described in Section
1.7.3 and check the trace results.

1.3 Analyzing CPU Status

1.3.1 Execution Duration of Tasks
The execution duration of each control task can be calculated from the Duration_Cur
values of Logic Designer’s “GSD_Task_**” system global variables where “**” in the
variable names range from 1 to 16, and map to individual tasks in the order of task
assignment.
For details on how to gather the required information, see Section 1.4.2, “Execution
Duration of Tasks” of “STARDOM Troubleshooting Guide: Information Gathering”
(TI 34P02K03-02E).
● Tick count
Control tasks of FCN/FCJ are executed in 10msec intervals. These 10msec cycles
are known as ticks. The duration of a control task is determined by counting ticks.
The Duration_Cur value of each “GSD_Task_**” system global variable indicates the
current control execution duration of the corresponding task in units of ticks.

● Execution duration of control task as tick count

The relationship between tick count and execution duration of a task is explained
below using an example.
Example: Task cycle=200ms, Duration_Cur=10
200 ms
1 tick=10 ms
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Control execution
Read Control application Write Idle time
I/O execution DO/AO
100 ms
110 ms
1. The tick count is recorded at the beginning of control execution.

For ease of explanation, the tick count at the beginning of the control task is
assumed to be 0 in this example.
2. Control computation did not end at the time of the 10th tick.
3. Control computation ends before the 11th tick so no control computation is done
from the 11th tick onwards. This is the idle time until the next control task starts.
At this time, the tick count at the end of the control computation is recorded as
10.
4. The execution duration of the control task is calculated as the difference between
the tick count at the beginning of control execution and the tick count at the end
of control execution, and is displayed as Duration_Cur of system global variable
“GSD_Task_**.”
Duration_Cur=10 – 0=10
- Interpreting Execution Duration of Control Task from Duration_Cur

Examples:
Duration_Cur=10 Control computation ends 100 ms or later but before 110
ms.
(As in the example shown in the above figure)
Duration_Cur=9 Control computation ends 90 ms or later but before 100
ms.
Duration_Cur=0 Control computation ends in less than 10 ms.
For details on the system behavior when the processing of a control task does not
end within one control cycle, see Section 1.3.3, “Watchdog Timer Error.”

1.3.2 Analyzing CPU Load

Clicking the [Info] button on the Project Control dialog of Logic Designer opens a
dialog window displaying CPU load and other resource information.
For details on how to gather the required information, see Section 1.4.1, “CPU Load”
of “STARDOM Troubleshooting Guide: Information Gathering” (TI 34P02K03-02E).
● Calculation and update interval of CPU load

The FCN/FCJ checks the operation status of a control application task at every
10msec tick.
If a control task is running when a check is done, the task is considered to be using
the CPU and its RUN count is incremented by one.
This check is repeated continuously 1024 times (for 1024×10 ms=10.24 s) and the
CPU load is calculated as shown below.
Example:
If the RUN count of a control task at the time of the 1024th check is 100,
CPU load = 100 times / 1024 times x 100% =9.765・・・・≒ 10%
● Interpreting CPU Load

Example: Task cycle=200 ms, CPU load= 37%
The CPU load of 37% reflects the percentage out of 1024 checks that the control
task was found to be running. It does not mean that the control task is executed
74 ms (=200 ms x 37%) in every cycle.
- Number of control task executions

Over the 10.24 checking interval, the control task having task cycle of 200 ms
was executed 51 times
10.24 s / 200 ms = 51.2 = 51 times
- RUN count of control task

From the CPU load of 37%, we know that the control task was found to be
running 380 times out of 1024 checks.
1024×37% = 378.88 = 380 times

- Interpreting CPU load

1024 ms
200 ms : cycle 1 200 ms : cycle 2 ..... 200 ms : cycle 51

1019 1021 1023
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 1020 1022 1024
〜
〜
1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4
Control Control ..... Control Control

execution Idle time execution Idle time execution Idle time execution
RUN count RUN count RUN COUNT
RUN count=7
=14=7+7 =376=369+7 =380=376+4
Let’s assume that the CPU load did not vary and stayed approximately constant
throughout the checking interval of 10.24 s.
We can then assume that the 380 RUN counts of the control task were evenly
distributed among the 51 times task executions.
We can consider that the RUN count was 7 for 28 task cycles and 8 for 23 task
cycles as shown below:
Total RUN count for 28 cycles =7×28 =196
Total RUN count for 23 cycles = 8×23 =184
Number of control task executions = 51 = 28 + 23
Total RUN count for control task =380 =196 +184
To summarize, if the task cycle is 200 ms and the CPU load is 37%, it means that
over the 10.24 s period used for CPU load calculation, the control task was
executed 51 times, and the duration of the control computation was 70 ms or
longer but shorter than 80 ms for 28 executions and 80 ms or longer but shorter
than 90 ms for 23 executions.
IMPORTANT
The above calculations assume that the CPU load did not vary and so processing
time for each cycle stayed approximately constant, which may not be the case in
reality.
For instance, the CPU load in the above example will remain as 37% even if out of the
51 times control task executions, the RUN count was 7 for 49 executions and due to a
surge in CPU load, the RUN count was 18 for 2 task cycles.
To check for variance of the CPU load, add global variable “GSD_Task_**” to the
Watch window of Logic Designer and visually monitor the value of Duration_Cur.
You may also assign the value of Duration_Cur to a UINT-type variable and analyze
the variable using Logic Analyzer.

1.3.3 Watchdog Timer Error

Logic Designer’s Task Setting dialog window allows you to define a watchdog time
(hereinafter abbreviated as WDT).
If WDT is defined and a control execution fails to complete within the specified WDT, a
WDT error is generated and recorded in the log file.
Example:
200*/**/****:**:**, • • (omitted) • • , Msg=Msg=Exception(Watchdog) in Task0,
● WDT error reporting

Example: System behavior when task cycle=200 ms, WDT=200 ms
200 ms : cycle 1 200 ms : cycle 2 200 ms : cycle 3 200 ms : cycle 4
Control execution Idle time Control execution Idle time
WDT error reported WDT error reported
In the above figure, processing of the control task requires approximately 250 ms and
cannot be completed within one control cycle. Processing of the first task cycle is
completed within the second task cycle.
First task cycle Control computation is not completed within the task cycle so a WDT error is
reported at the end of the task cycle.
Second task cycle Remaining computation not processed in the first task cycle is performed.
The computation ends about 50 ms later, leaving 150 ms idle time. The next
control computation is not started.
Third task cycle The next control computation is executed. The computation is not completed
within the task cycle so a WDT error is reported at the end of the task cycle.
Fourth task cycle Similarly to the second task cycle, the computation ends about 50 ms later,
leaving 150 ms idle time.
In this example, WDT errors are reported because control computation fails to end
within a 200msec ask cycle. Control computation which is supposed to be executed 4
times within a 800msec period is actually executed only 2 times so that the actual
taskcycle is 400msec, which is double of the defined task cycle.
● Watchdog time setting (WDT)

- You can set the WDT to any value in units of 10 ms.
- All of the following values for WDT are valid:
Task cycle = WDT，
Task cycle > WDT，
Task cycle < WDT
- Setting the WDT to zero disables the watchdog timer so that no WDT error will
be reported.

● Precautions
Logic Designer’s Target Setting dialog has a checkbox for “The task aborts when the
execution time of a task exceeds a watch dog time.” This checkbox can be used to
define the behavior of a control task in the event of a WDT error.
Checked: When a WDT error is detected,Tthe control task stops execution at WDT error.
Unchcked: Tthe control task continues execution at WDT error and checking, it is recorded in
the log file.
By default, this checkbox is unchecked. Beware that checking the checkbox will
cause a control task to stop execution in the event of a WDT error.
On the other hand, specifying a non-zero WDT value but leaving the checkbox
unchecked will allow monitoring of WDT errors without stopping task execution.
TIP
Uncheck this check box for a duplexed CPU configuration.

1.3.4 CPU Overload

When CPU load increases such that there is no CPU idle time for a continuous
duration of 1 second (for FCN-500)/ 10 seconds (for FCN-100, FCN-RTU and FCJ), a
CPU overload error is reported and recorded in the log file.
Example:
200*/**/****:**:** , • • (omitted) • • , Msg=Exception(CPU Overload) in Task0,
Consider two different cases of CPU overload error described below. The figures and
descriptions describe for FCN-100, FCN-RTU and FCJ. For FCN-500, change the
control computation time from "10 seconds" to "1 second" as appropriate.
● Case 1: control computation is completed within one task cycle

In the following figure, control computation barely fits within a task cycle such that
there is no CPU idle time.
When this state continues for 10 seconds, a CPU overload error is reported.
Even though WDT is set to the value of the task cycle, no WDT error is reported as
the control computation is completed within one task cycle.
10 s
〜
〜
Control cycle Control cycle Control cycle Control cycle
Control execution Control execution ..... Control execution Control execution
Control application Write Control application Write Control application Write Control application Write
Read I/O Read I/O Read I/O Read I/O
execution DO/AO execution DO/AO execution DO/AO execution DO/AO
WDT error reported
In this case, CPU load is persistently high as the defined task cycle is considered
short for the amount of control computation processing required.
● Case 2: control computation is not completed within one task cycle

In the following figure, one round of control computation processing is executed
continuously for a prolonged period exceeding 10 seconds. When the continuous
control computation execution reaches 10 seconds, a CPU overload error is reported.
Moreover, in the example shown below, WDT is set to the value of the task control
cycle so a WDT error is reported at the end of each task cycle.
10 s
Control cycle Control cycle Control cycle Control cycle
〜
〜
Control execution Control execution ..... Control execution Control execution

Read I/O Control application execution Write DO/AO
WDT error WDT error WDT error CPU overload reported WDT error
reported reported reported WDT error reported reported
In this case, consider the following possible causes for failure of the control
computation to complete within one task cycle.

- Repetitive processing of a control application fails to end

Example:
Errors in the use of FOR statements of ST language or jumps and labels may
cause an application to enter into an infinite loop so that one round of control
computation processing exceeds 10 seconds.
- Prolonged execution of a process of higher priority than control tasks

Example:
In FCN/FCJ, CPU processing for Ethernet communication has higher priority
than control tasks.
When communication with Ethernet devices continues under high FCN/FCJ load
conditions for whatever reason, a control task may be put in wait state for more
than 10 seconds as the FCN/FCJ gives priority to Ethernet communication
processing.
Note: A good example of this would be broadcast communication.
● System operation when a CPU overload error occurs

When a CPU overload error occurs, the CPU idle time is 0. As a result, the following
processes which are normally executed during the CPU idle time cannot be executed.
This behavior is common to cases 1 and 2.
- Execution of tasks having lower priority than the task causing CPU overload
- Communication with VDS data servers
- Inter-FCN/FCJ communication
- Modbus communication, Ethernet or serial communication between devices
- InfoWell function
- Duolet user applications
● Difference in system operation between case 1 and case 2

- Case 1
Although CPU idle time is 0, calculation processing is completed within each task
cycle. Thus, analog and digital input and output processing is performed within
each task cycle.
Moreover, even if WDT is set to the value of the control cycle, no WDT error will
be reported.
- Case 2
As calculation processing is not completed within one task cycle, no analog and
digital input and output processing is performed within task cycles for more than
10 seconds. Since this exceeds the loss of line access time limit of 4 seconds for
detecting a CPU error, the I/O module performs output fallback.
Moreover, if the WDT is set to the value of the task cycle, a WDT error will be
reported at the end of every task cycle.

1.4 Logic Designer Information

1.4.1 Analyzing Data of System Global Variables
Besides the “GSD_Task_**” system global variables described earlier in Section
1.3.1, there are other system global variables indicating system status.
● GS_RAS_IOStat
The GS_RAS_IOStat global variable indicates the status of an installed I/O module.
The following figure shows status information for the I/O module installed in slot 5 of
the control unit (unit1). Of the displayed information, we shall describe the IomStatus,
ErrDetail and SbbusStatus, which are enclosed within the rectangle in the figure.
For details on how to gather the required information, see Section 1.4.3, “Data of
System Global Variables” of “STARDOM Troubleshooting Guide: Information
Gathering” (TI34P02K03-02E).

- IomStatus
The IomStatus WORD-type data represents the status of an I/O module. The table
below describes the meaning of each IomStatus bit, when set.
These bits, when combined, indicate normal status. For instance, 16#0011 indicates
normal operation with definition data present and 16#0013 indicates downloading in
progress with definition data present.
Table IomStatus
Value Description
16#0001 Normal operation
In this state, no system alarm is reported in the I/O module.
System alarm conditions such as whether there is external power supply vary
with the I/O module type.
16#0002 Downloading in progress
In this state, definition data is being downloaded from Resource Configurator.
16#0010 Definition data present

In this state, definition data is already downloaded from Resource Configurator.
16#0100 Standby state
This is displayed only with duplexed NFLF111 modules.
- ErrDetail
The ErrDetail WORD-type data stores error information of an I/O module.
Table ErrDetail
Value Description
16#0000 Normal state
This value is also displayed when no module is defined.
16#0001 Error state
This value is displayed for any other error not listed below.
16#0002 Configuration error
This value is stored in ErrDetail when a normal I/O module is replaced by
a module of the same type but with different configuration.
If automatic loading is enabled, this state will trigger automatic loading,
and clear the error.
16#0003 I/O module type error

This value is stored in ErrDetail when a normal I/O module is replaced by
a different type of module.
16#0004 Firmware is not loaded in the I/O module
16#0005 Inconsistent firmware version in the I/O module

- SbbusStatus
The SbbusStatus WORD-type data indicates the status of the SB bus connected to an
I/O module. The table below describes its bit representation.
Table SbbusStatus
Value Description
16#0001 SB bus A is operating normally.
16#0002 SB bus B is operating normally.

For single SB bus configuration, only bus B is used so this value is
displayed.
16#0003 Both SB bus A and SB bus B are operating normally (for dual-redundant
SB bus)
If the SbbusStatus value is not equal to any of the normal values listed in the table
above, it indicates an error somewhere on the SB bus.
This SB bus includes not only the internal SB bus of the base module, the SB bus
repeat module, the SB bus cable, but also the internal SB bus of the I/O module.
Thus, an I/O module unit failure may also result in the SbbusStatus of the module
indicating an error value.
Therefore, when the SbbusStatus indicates an error value, you need to determine
whether it is due to an SB bus error or an I/O unit failure.
For this purpose, check the SbbusStatus value of other I/O modules installed in the
same base module.
If the SbbusStatus of all I/O modules installed within the same base unit indicate an
error value, it indicates that the error is on the internal SB bus of the base module, the
SB bus repeat module or the SB bus cable.
If the SbbusStatus of the other I/O modules installed on the same base module
indicate a normal value, it signifies a unit failure of the corresponding I/O module.
● GS_RAS_Current
The GS_RAS_Current system global variable stores current RAS information.
Such information includes the serial number or revision of the system card, the CPU
operating status and system down information, and is displayed collectively as RAS
information in Resource Configurator.
For details on the displayed information, see Section 1.5.3, “Analyzing RAS
Information.”

1.4.2 POU Error Information

Input/output processing POUs and various communication POUs of NPAS_POU have
output terminals for reporting errors and indicating error status.
If you connect to the variable associated with such a terminal, and then switch Logic
Designer to debug mode, the variable value will be displayed.
For details on error codes, see the online help documentation of the corresponding
POU.
Input/output POU Example Communication POU Example
In particular, when communication is not normal, the error code displayed in the
communication POU is useful for pinpointing the cause of the problem.
In order to gather information when a communication error is encountered, we
recommend assigning a variable each to the ERROR terminal and STATUS terminal
of a communication POU beforehand.
1.4.3 Analyzing Logic Designer Log Data

Logic Designer stores its log files with date information included in the filenames in
the following folder:
<Logic Designer installed path>\LogicDesigner\Mwt\Log
With standard installation, the log files are stored in the following folder:
C:\YOKOGAWA\FCN-FCJ\LogicDesigner\Mwt\Log
The date and time when a project is “make” or compiled is recorded in the log file as
follows: (for R1.70 and later versions)
Example:
20**/**/** **:**:** TRACE,0x000f, C:\BuildEnv\VC\Src\LogicDesigner
\SdcsWriteGenInfo\CSdcsEngLog.h:106,"---- Writing generational information
FCX01----"

1.5 Analyzing Resource Configurator

Information
1.5.1 Basic Settings of CPU Module
Basic settings of the FCN/FCJ are displayed on Resource Configurator’s General tab
screen.
● Enable SB Bus Redundancy

When this checkbox is selected, the SB bus is dual-redundant.
For details on SB bus dual redundancy, see Section 1.2.5, “Analyzing Status LEDs of
SB Bus Repeat Module.”
● Enable Hard-backup for Retained Data

When this checkbox is selected, retained data is stored on the SRAM (non-volatile
memory) of the CPU.
If a retained data related failure is reported, check this setting.
● Use Duolet Program

Select this checkbox to use Duolet programs in a single FCN-100, FCN-RTU or FCJ
system.
If this checkbox is deselected, Duolet functions will not run even if a Duolet runtime
license is registered on the CPU module or the system card.
If Duolet programs do not run, check this setting.

● Enable I/O Module Auto-Load

If this checkbox is selected, settings defined in Resource Configurator will be
automatically reloaded after an I/O module is replaced.
If an I/O module fails to run after a replacement, check this setting.
For details about I/O module, see Section 1.2.4, “Analyzing Status LEDs of I/O
Modules” and Section 1.4.1, “Analyzing Data of System Global Variables.”
● Configure CPU Duplex (NFCP500)

If this checkbox is selected, the CPU duplex of FCN-500 is enabled.
If duplex CPU of FCN-500 related failure is reported, check this setting.
● Enable APC Auto-Start

If this checkbox is selected, the auto-APC feature of duplex FCN-500 or FCN-100 is
enabled.
If a duplex FCN-500 or FCN-100 related failure is reported, check this setting.

1.5.2 License Information on System Card

Licenses registered in the FCN/FCJ system card (FCN-100, FCJ) are listed on the
License tab screen of Resource Configuator.
When a project including an APPF not listed here is downloaded from Logic Designer,
a license error message is displayed in Logic Designer’s message window.
Right-click on the displayed error and select message help to display the controller
error message online help documentation. The help documentation contains a list of
APPF numbers, which can help identify the application portfolio corresponding to the
APPF number displayed in the license error message.
Table List of Application Portfolios (1/2)

Number Model Application Portfolio
505 NT730AJ Software License for Duplexed Field Network Module
101 NT8001J PAS Portfolio License
102 NT8002J SAMA Portfolio License
105 NT8005J General-purpose Portfolio A License

110 NT8010J Webmetry Basic Library Portfolio License
112 NT8012J InfoWell Web Application Portfolio License

113 NT8013J InfoWell E-mail Application Portfolio License
114 NT8014J InfoWell Graphic Portfolio License
115 NT8015J Graphic Application Portfolio License
116 NT8016J Logging Portfolio (InfoWell)

117 NT817J InfoWell Licencs
120 NT8020J FA-M3 Communication Portfolio License
121 NT8021J MELSEC-A Communication Portfolio License
122 NT8022J SYSMAC Communication Portfolio License

Table List of Application Portfolios (2/2)
Number Model Application Portfolio
130 NT8030J Power Monitor Communication Portfolio License
131 NT8031J Temperature Controller Communication Portfolio License
132 NT8032J JUXTA VJ Communication Portfolio License
133 NT8033J PR488 Communication Portfolio License

135 NT8035J Modbus Communication Portfolio License
136 NT8036J DNP3 Communication Portfolio License

140 NT8040J Time Synchronization Server Portfolio License
201 NT8101J Boiler Control Portfolio License

202 NT8102J Boiler Auxiliary Control Portfolio License
203 NT8103J InfoEnergy Time Scheduler Portfolio License
205 NT8105J Gas Flow Calculation Portfolio

700 NT8600J InfoEnergy Demand Monitoring Portfolio License
979 NT8885J Additional InfoEnergy Software License
980 NT8880J InfoEnergy Software License
981 NT8885J InfoEnergy Software License Yokogawa Power Monitor: 0→62 monitors
InfoEnergy Software License Yokogawa Power Monitor: 62→124 monitors (Only
982 NT8885J
For FCN)
983 NT8885J InfoEnergy Software License Direct Analog Input: 0→6 Inputs (Only for FCJ)
984 NT8885J InfoEnergy Software License Direct Analog Input: 0→16 Inputs (Only for FCN)
985 NT8885J InfoEnergy Software License Direct Analog Input: 16→32 Inputs (Only for FCN)
986 NT8885J InfoEnergy Software License Direct Digital Input: 0→16 Inputs (Only for FCJ)
987 NT8885J InfoEnergy Software License Direct Digital Input: 0→64 Inputs (Only for FCN)
988 NT8885J InfoEnergy Software License Direct Digital Input: 64→128 Inputs (Only for FCN)
From the above online help documentation, we know from the “Application portfolio:
121” error message displayed in the above figure that the error occurs because
MELSEC-A Communication portfolio license is not registered on the system card.

1.5.3 Analyzing RAS Information

Data of Logic Designer’s system global variable GS_RAS_Current is displayed on
Logic Designer’s [RAS information-Current] tab screen
● Hardware Related Information

The displayed CPU module configuration information includes serial number, year
and month of manufacture, operation status, CPU temperature, revision and build
number of the basic software and APC information.
In particular, the revision and build number of the basic software is required for
analyzing problem symptoms.
● Error and System Down Related Information

Table Error and System Down Related Information of RAS Information
Parameter Description
SramError The total number of SRAM single-bit errors reported since power on.
SramErrCnt The total number of SRAM single-bit errors reported since the date of manufacture.
DownStatus Bit flag indicating the previous system down status.
DownCode If DownStatus indicates a forced shutdown by software, DownCode stores an error

code.
LogDate The date and time of shutdown

ErrorString Character string indicating the cause of the error
From LogDate and DownCode, you can tell when and why the FCN/FCJ went down.
For details on the above information, see [FCN/FCJ Setting]-[Confirming the RAS
Information] in the online help documentation of Resource Configurator.

● RAS information-Current, RAS information-Old(1) and RAS

information-Old(2)
Current: Displays current RAS information.
In the above screen capture, the system down time is displayed as
"1970/01/01 09:00:00” because the FCN/FCJ is running.
Old(1): Displays the RAS information at the previous FCJ startup.
Old(2): Displays the RAS information at the second previous FCJ startup
Information is copied from current to Old(1) and from Old(1) to Old(2) when:
- Transition is made to Ready-for-power-down state by shutdown processing of
FCN/FCJ.
DownStatus, DownCode and LogData are assigned values by shutdown
processing.
- FCN/FCJ restarts after power interruption without shutdown processing.
This happens when power is restored after power supply to FCN/FCJ is cut off
suddenly due to power failure. As shutdown processing is not performed,
DownStatus and DownCode are assigned zero values while LogDate is assigned
the date and time of the FCN/FCJ startup.
- FCN/FCJ is rebooted without shutdown processing.
This happens if the RESET button is activated when FCN/FCJ is running or the
FCN/FCJ is rebooted from the FCN/FCJ maintenance page.
DownStatus is assigned a RESET-button-on event while LogData is assigned the
date and time of the FCN/FCJ startup.

1.5.4 Project Information

Project information displays not only the name and date of the active project but also
the names and dates of the boot project and the compressed project (project source).
The displayed time items are described below.
- Date of Active Project

This indicates when the active project is “make” or compiled. It does not indicate
when the project is downloaded.
- Date of Boot Project

This indicates when the boot project is “make” or compiled. It does not indicate when
the boot project is downloaded.
- Date of Zipped Project

This indicates when the project is compressed.
As project source is compressed when it is downloaded, the date/time of compression
is the same as the date/time of downloading.
IMPORTANT
The above information is updated 15 or more minutes after downloading a project,
boot project or project source.
Moreover, the information will not be updated while a Resource Control dialog window
of Logic Designer is displayed, or while Logic Designer is in Debug mode.

1.5.5 Resource Configurator Definitions

Clicking DevLabelVar in Resource Configurator’s tree pane displays a list of device
label variables included in the active project of the FCN/FCJ.
When definition data is downloaded from Resource Configurator, DevLabelVar data

and Resource Configurator’s definition data are compared, and a warning will be
displayed in the message area if any discrepancy is detected.
- Undefined device label variable

If a device label variable included in the active project on the FCN/FCJ is not defined
in Resource Configurator, the following warning will be displayed.
Example:
WARNING=0026: The device label variable (AI001) used by the IEC control
application is not assigned to I/O Module.
On the contrary, if a device label variable defined in Resource Configurator is not

included in the active project on the FCN/FCJ, no warning will be displayed.
- Inconsistent signal type of device label

If the data type of a device label variable included in the active project on the
FCN/FCJ is inconsistent with its signal type defined in Resource Configurator, the
following warning will be displayed.
Example:
WARNING=0027:The data type(I_Sts) of the device label variable(DI001) used
by the IEC control application is not suitable for the signal type of I/O
Module.:I/O Module=1(AI/AO),signal type=AI

1.5.6 Analyzing Loop Check Tool Information

The Loop Check Tool can be used to display input/output values of I/O modules.
The displayed values are the values before digital to analog (D/A) conversion by the
I/O module for output signals and the values after analog to digital (A/D) conversion
by the I/O module for input signals.
CPU module I/O module

Electrical
Normalized data D/A
signal
Analog output con-
(engineering unit) version
Electrical
Analog input Normalized data A/D
signal
con-
(engineering unit) version
Electrical
BOOL-type data signal
Digital output
(BOOL-type data)
Electrical
Digital input BOOL-type data signal
(BOOL-type data)
Values displayed by
Loop Check Tool
The Loop Check Tool was originally designed for I/O wiring check of FCN/FCJ but can
also be used for first-level isolation of the cause of an I/O related problem.
■ If no value is displayed by Loop Check tool

If the Loop Check Tool displays grey asterisks ‘*’ instead of values, check the
following items.
- 24V analog field power supply

For details, see Section 1.2.1, “Analyzing States of LEDs of Power Supply Module.”
- Connection of each terminal

Verify that cable connections of all terminals are correct and secure.
- 2-wire/4-wire system setting of analog input module

Some input modules allow configuration for 2-wire or 4-wire system connection to a
transmitter. Verify that the setting is correct.
- I/O disconnection
If Logic Designer’s global variable GS_NFIO_DISCONNF is set to ON, I/O is
disconnected and the CPU module does not communicate with I/O modules so
naturally no data will be displayed by Loop Check Tool.

■ If actual I/O values differ from device label variable values

If actual I/O values differ from device label variable values, consider the following
three possible cases.
- If values of Loop Check Tool and device label variables tally but differ
from actual I/O values
This is likely caused by output inversion in Resource Configurator. Since the values of
the Loop Check Tool and device label variables tally, it means that things are normal
from the CPU module up to D/A conversion or A/D conversion by the I/O module as
shown in the figure on the previous page.
The cause of the problem is, therefore, not on the application side so check the
connections between the I/O module and devices and their hardware settings.
- If values of Loop Check Tool and actual I/O tally but differ from device
label variable values
Since the values of the Loop Check Tool and actual I/O tally, it means that things are
normal from D/A conversion or A/D conversion by the I/O module up to the device.
The cause of the problem, therefore, lies in data setting by the application so check
the application including Resource Configurator’s settings and Logic Designer’s
device label variable definitions.
- If values of Loop Check Tool, device label variables and actual I/O all
differ
The problem is likely due to both application definitions or settings and hardware
connections or settings.

1.6 Analyzing Information from Maintenance

Page
1.6.1 Analyzing Information on the Top Page
The Top Page of the maintenance page of the FCN/FCJ displays information on the
memory capacity and free space on the system card.
The free space on the system card varies with the size of the boot project, the size of
the ADLST file, the size of the retained data file and the size of Duolet applications
stored on the system card.
If this free space falls too low, system card revision upgrade will not succeed.
If revision upgrade fails, check the free space on the system card.
At least 7 MB of free space on the system card is required for revision upgrade to
FCN/FCJ R1/R2.
At least 10 MB of free space on the system card is required for revision upgrade to
FCN/FCJ R3 or later.
1.6.2 Analyzing FCN/FCJ Log Data

● Types of log data
Log data displayed on the maintenance pages includes the following items:
- System Log
The system log contains text output of Duolet applications.
If no Duolet application is running, no log is output.
(Duolet applications here refer to APPFs using Duolet function and user Duolet
applications)
- Kernel Log
These are information logged by drivers, runtime engines and various APPFs as
internal codes.
For details on internal codes, check the online help documentation.

● Analyzing system log

The system log stores messages generated by Duolet application and APPFs along
with date/time, log message type and internal code information.
One line of the above information is recorded per event in chronological order of
occurrence. Except for Duolet application messages, system log messages generally
report internal system information and may be understandable only by users with
system knowledge.
● Analyzing kernel log

The kernel log records date/time, log message type and internal code information.
Error or warning information may also be recorded as text instead of an internal code.
One line of the above information is recorded per event in chronological order of
occurrence and can thus be used to perform chronological analysis of internal
FCN/FCJ events.
● Analyzing internal codes

We describe below how to analyze internal codes using some examples.
A comment prefixed by an (*) asterisk in the examples below describes the internal
code displayed on the same line or its preceding line. These descriptions can be
found in the online help documentation.
Example 1: 08:23:29,*,INFO ,STARDOM,JEROS(JRS:R2.04.12) starting in Online state

08:23:29,*,INFO ,STARDOM,JEROS(JRS:R2.04.12) starting in Online state
* This message is logged when the FCN/FCJ is powered up.
08:23:34, ,INFO ,SYS_EVENT,3408,AUTO,
* Memory equalization between the control and standby sides of dual-
redundant system is started.
08:23:34, ,INFO ,SYS_EVENT,3406, * File system equalization between the control and standby sides is
started.
08:24:20, ,INFO ,SYS_EVENT,3407, * File system equalization completed.
08:24:21, ,INFO ,SYS_EVENT,3409, * Memory equalization completed.
08:24:21, ,INFO ,SYS_EVENT,3405,RIGHT, * After APC is completed, standby (right) CPU operation begins.
08:24:26, ,INFO ,SYS_EVENT,3402,LEFT, * Control (right) CPU operation begins.
08:24:26, ,INFO ,SYS_EVENT,3509, * Windup begins.
08:24:36, ,INFO ,SYS_EVENT,3510, * Windup ends.
08:24:36, ,WARNING ,SYS_ALARM,3218, * Control function starts (Warm Start)
Explanation: At 08:23:29, duplex FCN is powered up and APC is started. At 08:24:36, the left FCN starts control
processing as the control FCN. At this time, a warm start message is logged, which indicates that the boot project
on the system card has been loaded into the memory and the system has been warm started. From the log data,
we know that restart processing after power up has completed successfully.

Example 2: 09:58:29, ,WARNING ,SYS_ALARM,3219, * Control function stops

09:58:35, ,WARNING ,SYS_ALARM,3001,1,7, * I/O module self-diagnosis error (UNIT1, SLOT7)
09:58:36, ,WARNING ,SYS_ALARM,3001,1,6, * I/O module self-diagnosis error (UNIT1, SLOT6)
09:58:40, ,INFO ,SYS_EVENT,3501, * Control application is loaded
09:58:44, ,INFO ,SYS_EVENT,3503, * Boot project is loaded
09:59:08, ,INFO ,SYS_EVENT,3509, * Windup begins.
09:59:10, ,WARNING ,SYS_ALARM,3002,1,6, * Recovery from I/O Fail (UNIT1, SLOT6)
09:59:10, ,WARNING ,SYS_ALARM,3002,1,7, * I/O recovery (UNIT1, SLOT7)
09:59:18, ,INFO ,SYS_EVENT,3510, * Windup ends.
09:59:18, ,WARNING ,SYS_ALARM,3216, * Control function started (Cold Start)
Explanation: At 09:58:29, control function stopped so communication between FCN and I/O modules stopped and I/O
module errors were reported.
From the log data, we know that the control application and boot program were downloaded immediately after, so
it is likely that the control function was stopped because of downloading so there was no real system problem.
After downloading, the FCN/FCJ was cold started so all retained data was initialized.
If a problem related to loss or initialization of retained data occurs thereafter, it is likely caused by the cold start
recorded here.
● Analyzing text information in kernel log

Text information in kernel log is composed of date/time, log message type, source of
generation and message text.
Date information: The date and time of the FCN/FCJ when the log record is generated
Log type: Log message type (ERRRO, INFO, etc.)
Location of log event: The location of the logged event within the FCN/FCJ
Message: Logged information displayed as text
Example:
20**/**/** **:**:**, ,ERROR ,ERROR,MID=0x201a,ErrNo=0x7,File=
SdcsPcException.c,Line=308,Msg=Exception(Watchdog) in Task0, Ignore
The above log record can be broken down in meaningful pieces as shown in the table
below.
Date information: 20**/**/** **:**:**
Log type: ERROR
Location of log event: ERROR,MID=0x201a,ErrNo=0x7,File=SdcsPcException.c,Line=308
Message: Msg=Exception(Watchdog) in Task0, Ignore
The message describes the logged event, the name of the task associated with the
event and the operation of the task when the event occurred.
In the above example, a WDT error is reported for Task0.
From the word “Ignore” in the message, we know that Task0 did not stop but
continued control execution despite the WDT error.
On the contrary, if the task had stopped execution when the logged event occurred,
“Terminate Task” instead of “Ignore” would be logged.
When analyzing text information in a log file, besides the message itself, you should
also check preceding and subsequent logged information.

● Representative text log messages

The table below describes in detail some representative text log messages.
Table Representative Text Log Messages

Message Description See Also:
STARDOM,JEROS(JRS:R2.04.12)starting in Online This message is logged when the FCN/FCJ is
state(Option:None) powered up.
Msg=Exception(Watchdog) in Task0, Ignore Section
A WDT error is reported in Task0.
Msg=Exception(Watchdog) in Task0, Terminate Task 1.3.3
Section
Msg=Exception(CPU Overload) in Task0, Ignore A CPU overload is reported in Task0.
1.3.4
A division by zero exception is reported during
Msg=Exception(DIV0) in Task0, Terminate Task
calculation processing of Task0.
Msg=Exception(String Error) in Task0, Ignore A string manipulation error is reported by Task0.

Section
Msg=Heart beat timeout has occurred (chan=1) An inter-FCN/FCJ communication error is reported.
1.8.4
Msg=MISCMP Task0:200c0200:0/80 100 1060101 0 Analog/digital outputs of the control and standby Section
10 sides of a duplex FCN differ. 1.8.5

1.6.3 Analyzing Date and Time Information of FCN/FCJ

● Operation and error of internal clock of FCN/FCJ
The internal clock of the FCN/FCJ is powered by the battery of the CPU module and
so will continue to run even if the FCN/FCJ is powered down.
As the clock has an error of -17.5 to +12.0 seconds per day, perform time
synchronization if accurate time information is required.
● Relationship between FCN/FCJ clock and time zone setting

The internal clock of the FCN/FCJ handles time as GMT (Greenwich Mean Time)
data.
If the time zone of the FCN/FCJ is set to JST (Japan Standard Time), the internal
clock time itself remains unchanged but 9 hours is added to the time value before it is
displayed as the current FCN/FCJ time.
For instance, if the time zone of an FCN/FCJ is set to JST and the displayed time is
09:00:00, the internal clock time of the FCN/FCJ is stored as the equivalent GMT time
of 00:00:00.
Moreover, if the JST time zone setting is now changed to CTT (+8 hours), the internal
clock value remains unchanged as 00:00:00 but the displayed time becomes
08:00:00.
● Problem caused by setting FCN/FCJ clock time to local time without

first changing time zone setting from GMT to local time zone
Always change the time zone setting of the FCN/FCJ from its default GMT time zone
to the local time zone before setting the FCN/FCJ clock time to local time.
Otherwise, the displayed time may be incorrect after the system card is replaced.
Example:
FCN/FCJ clock time is set to JST local time with GMT time zone
setting
Consider an example where the FCN/FCJ is set to JST local time (current GMT time +
9 hours) without first changing the time zone setting from its default of GMT to JST.
The internal clock now holds a time value equivalent to current GMT time + 9 hours. If
the time zone setting of the FCN/FCJ remains as GMT, the displayed clock time will
seem to reflect the local time correctly as no time correction for time zone is
performed before display.
If the system card of the FCN/FCJ is then replaced and the time zone setting saved
on the new system card is JST, the system will perform GMT to JST conversion
before displaying the time by adding 9 hours to the time value of the FCN/FCJ internal
clock.
However, as the internal clock already holds the value of current GMT time + 9 hours
before the card is replaced, the displayed time after the card is replaced will be the
current GMT time + 18 hours, which is incorrectly ahead by 9 hours.

1.7 Problem Analysis Using Remote Shell

(FcxRsh) Software Tool
1.7.1 Description of Remote Shell (FcxRsh) Software Tool
The remote shell (FcxRsh) software tool allows commands to be executed on an
FCN/FCJ from the PC command prompt. It allows FCN/FCJ commands to be
executed directly from a PC without first logging in to the FCN/FCJ using telnet.
It can be used with all FCN/FCJs, regardless of system revision and CPU style.
You can obtain the FcxRsh software tool from the maintenance homepage of the
FCN/FCJ or from the FCN/FCJ R1.40 or later system CD-ROM.
1.7.2 Getting Remote Shell (FcxRsh) Software Tool

● How to get FcxRsh from FCX Maintenance homepage
1. Open the FCX Maintenance homepage using the following URL address,
username and password:
URL address : http://<IP address>/mnt
user name : stardom
password : YOKOGAWA
2. Click “Maintenance Menu.”
3. Select “Download the Backup Tools” to download the required file.
4. Uncompress the downloaded “FCXTOOL.EXE” file.
The “FcxRsh.exe” file is included among the uncompressed files.
● How to get FcxRsh from CD-ROM for FCN/FCJ R1.40 or later revision
1. Insert the CD-ROM for R1.40 or later revision into the PC’s CD-ROM drive. If the
screen is automatically regenerated, exit from the program.
2. From the File Explorer, right-click the CD-ROM, and select [Open] from the
displayed pop-up menu.
3. From the displayed folder, execute the "Pkg_FCX.exe" file below “Pkg_FCX,”
and specify an installation path. A folder named "FCX" is created at the specified
installation path, with the “FCXTOOL.EXE” file stored within the folder.
File location: FCX\Install\jeros\SCRIPT
4. Uncompress the “FCXTOOL.EXE” file. The “FcxRsh.exe” file is included among
the uncompressed files.
IMPORTANT
When uncompressing "FCXTOOL.EXE," the specified destination pathname for the
uncompressed folder must not contain any space character. For instance,
"Documents and Settings" would not be a valid destination pathname.

1.7.3 Executing Remote Shell (FcxRsh) Software Tool

This section describes how to execute a command using FcxRsh, assuming the
following conditions:
Folder where FcxRsh.exe is stored: C:\tmp\FCXTOOL

IP address of FCN/FCJ: 192.168.0.1
Filename of the BAT file to be created: TEST.BAT
1. Open a command prompt window, and make the folder where FcxRsh.exe is
stored the current directory by typing:
C:\>cd tmp\FCXTOOL
2. Execute the command by typing “FcxRsh” followed by the IP address of the
FCN/FCJ and the command to be executed on the FCN/FCJ as shown below:
C:\tmp\FCXTOOL>FcxRsh 192.168.0.1 <command to be executed>
3. The specified command is executed on the specified FCN/FCJ and the execution
result is displayed.
IMPORTANT
As FcxRsh affects CPU operation, its use during production operation is generally not
recommended. If its use is absolutely necessary for information gathering, we
recommend testing on an alternative machine first. Moreover, using FcxRsh directly
by typing commands at a Windows command prompt carries risk of mistyping
resulting in problems so always create a BAT file containing the required FcxRsh
command(s) and test its execution on a debugging machine before executing it on the
production machine. Moreover, do not press the Ctrl-C keys during command
execution as this will cause a temporary surge in CPU load on the FCN/FCJ.
We describe below some specific examples of remote shell tool execution.
● To “ping” another FCN/FCJ from an FCN/FCJ

In this example, we will “ping” FCN2 (with IP address 192.168.0.2) from FCN1 (with IP
address 192.168.0.1) three times using FcxRsh. (Always specify the number of times
to ping.)
1. In Notepad or some other text editor, type the following command:
FcxRsh 192.168.0.1 ping \"192.168.0.130\",3
Specify “FcxRsh” followed by the IP address of the FCN/FCJ and the command
to be executed on the FCN/FCJ.
The above command “pings” another FCN/FCJ three times.
Save the above command into a file with filename “TEST.BAT” in the following
folder where the FcxRsh software tool is stored:
C:\tmp\FCXTOOL

2. Execute the created command.
C:\tmp\FCXTOOL>TEST.BAT
3. The specified command is executed on the specified FCN/FCJ and the execution
result is displayed as shown below.
TEST.BAT
ping "192.168.1.2",3
PING 192.168.1.2: 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0. time=0. ms
----192.168.1.2 PING Statistics----
3 packets transmitted, 3 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0
value = 0 = 0x0
logout
● Tracing Ethernet communication

In this example, we will use the remote shell (FcxRsh) software tool to trace
communication events (other than inter-FCN/FCJ communication events) of an
FCN/FCJ communicating via Ethernet.
IMPORTANT
Beware that executing communication trace commands will increase the CPU load of
the FCN/FCJ.
- Trace command
By executing the SdcsPlcComFbTrace command on the FCN/FCJ using the remote
shell tool, we can display the trace results on a PC. Mode, communication channel
and number of traces are passed as command arguments.
- Argument 1: mode
1: Text Trace ON → If FCN/FCJ is running as a client
2: Bin Trace ON → If FCN/FCJ is running as a client
3: Text&Bin Trace ON → If FCN/FCJ is running as a client
11: ModTcpSvrTrace ON → If FCN/FCJ is running as a server
- Argument 2: Communication channel
If the FCN/FCJ is running as a client, specify the CH terminal number of the
OPEN communication POU.
If the FCN/FCJ is running as a server, execute the following command to check
the client IP address and specify the task number.
FcxRsh 192.168.0.1 SdcsModTcpSvrInfoShow

> FcxRsh 192.168.0.1 SdcsModTcpSvrInfoShow
SdcsModTcpSvrInfoShow
---------- Modbus/TCP server status --- (DateTime=2017/09/25 13:07:37.883) --
MainTask = OPEN
......
-----------------------------------------------------------------------------
CommTask1 = OPEN
CurtVIP : (ClientIP=192.168.000.002)
CurtSTS : (SocketID=0x0000004c) : (DateTime=2017/09/25 13:07:18.666)
Recv- : (CurtToutIndx=00.000/10.0)
ToutIDX : (MaxToutIndex=00.400/10.0) : (DateTime=2017/09/25 13:07:21.666)
-----------------------------------------------------------------------------
CommTask2 = OPEN
CurtVIP : (ClientIP=192.168.000.003)
CurtSTS : (SocketID=0x0000004c) : (DateTime=2017/09/25 13:07:18.666)
Recv- : (CurtToutIndx=00.000/10.0)
ToutIDX : (MaxToutIndex=00.400/10.0) : (DateTime=2017/09/25 13:07:21.666)
-----------------------------------------------------------------------------
CommTask3 = CLOSE
-----------------------------------------------------------------------------
CommTask4 = CLOSE
---------- Modbus/TCP server status -----------------------------------------
- Argument 3: Number of traces

Specify the number of traces to perform. Be sure to specify more than 2 times.
- Argument 4: Timestamp
0: No timestamp (default)
!0: With time stamp
- Argument 5: Error stop (default)

0: No error check
!0: Stop with 10 traces after error occurrence

- Executing trace command

1. Create a text file coded with the required trace command.
Example: Assuming binary mode (1), communication channel 1 and performing
30 traces, the trace command will be:
SdcsPlcComFbTrace 2,1,30
#
taskDelay 5000
#
- Arguments for taskDelay

In the case of FCN-500: * 1 ms
In the case of FCN-100: * 10 ms
The text file can be given any arbitrary name but must be saved in the same
folder as the remote shell (FcxRsh) tool. In this example, “Trace_Ether.txt” is
assumed as the filename.
2. Create a BAT file for remote shell tool execution.
Specify “FcxRsh,” followed by filename “Trace_Ether.txt” as the “-f” option and
the IP address of the FCN/FCJ to be traced.
Example: Assuming the uncompressed remote shell (FcxRsh) tool is stored in
folder “C:\temp\FCXTOOL” and the IP address of the FCN/FCJ is 192.168.0.2,
the BAT file will contain:
FcxRsh -f Trace_Ether.txt 192.168.0.2
(TIP) If R3.20.01 or earlier, tracing will continue if trace count is omitted. Please end
with the above method. If R3.30.01 or later, tracing stops, so it is unnecessary.
3. When you execute the BAT file, the trace results will be displayed as shown
below:
TEST.BAT
SdcsPlcComFbTrace 2,1,30
value = 0 = 0x0
taskDelay 500
CH= 1 S=12 OK : 00000000 00060101 00000014
CH= 1 R=12 OK : 00000000 00060101 03000000
CH= 1 S=12 OK : 00000000 00060102 00000014
：
：
CH= 1 S=12 OK : 00000000 00060101 00000014
CH= 1 R=12 OK : 00000000 00060101 03000000
value = 0 = 0x0
logout

● Tracing serial communication

In this example, we will use the remote shell software tool to trace serial
communication processing by an FCN/FCJ.
IMPORTANT
Beware that executing communication trace commands will increase the CPU load of
the FCN/FCJ.
- Trace command
By executing the SdcsRsmFbTrace command on the FCN/FCJ using the remote shell
(FcxRsh) software tool, we can display the trace results on a PC. Mode and
communication port name are passed as command arguments.
- Argument 1: mode
1: Text Trace ON
2: Bin Trace ON
3: Text&Bin Trace ON
- Argument 2: Commmnication port name

Modes 1 to 3: Port names of COM1/COM2/COM3/COM4/RS communication
module
- Argument 4: Timestamp
0: No timestamp (default)
!0: With time stamp
- Argument 5: Error stop

0: No error check
!0: Stop with 10 traces after error occurrence

- Executing the trace command

1. Create a text file coded with the trace command for starting tracing.
Example: Assuming binary mode (=2) and tracing serial communication port of
FCN (=COM1), the trace command will be:
SdcsRsmFbTrace 2,"COM1",30
#
taskDelay 500
#
The text file can be given any arbitrary name but must be saved in the same
folder as the remote shell (FcxRsh) tool. In this example, “Trace_Serial_Start.txt”
is assumed as the filename.
2. Create a TEST.BAT file with the following content for execution.
FcxRsh -f Trace_Serial_Start.txt 192.168.0.2
3. Create an END.BAT file with the following content for ending tracing.
FcxRsh SdcsRsmFbTrace
#
4. Execute TEST.BAT to start tracing by typing:

C:\temp\FCXTOOL>TEST.BAT
The trace results are displayed.
TEST.BAT
SdcsRsmFbTrace 2,"COM1",30
value = 0 = 0x0
-> COM1 S=8 OK : 01010000 00143c05
COM1 R=8 OK : 01010300 00003c4e
COM1 S=8 OK : 01020000 001ef802
COM1 R=9 OK : 01020400 000000fb e2
COM1 S=8 OK : 01030000 00044409
COM1 R=13 OK : 01030800 00000000 00000095 d7
COM1 S=8 OK : 01040000 00067008
COM1 R=17 OK : 01040c00 00000000 00000000 00000095 b7
COM1 S=8 OK : 01050064 ff00cde5
COM1 R=8 OK : 01050064 ff00cde5
COM1 S=8 OK : 01060064 04d24a88
COM1 R=8 OK : 01060064 04d24a88
：
：
5. Execute END.BAT to terminate tracing on the FCN/FCJ.

Example: Assuming the uncompressed remote shell (FcxRsh) tool is stored in
folder “C:\temp\FCXTOOL” and the IP address of the FCN/FCJ is 192.168.0.2,
type:
C:\temp\FCXTOOL>END.BAT
6. Usage information of the SdcsRsmFbTrace trace command is displayed and its

execution on the FCN/FCJ is terminated.

END.BAT
-------------------------------------------------------------------------------
Usage : SdcsRsmFbTrace mode, "PortName", NumberOfTrace, timeStamp,
errorStop
-------------------------------------------------------------------------------
mode : 1: Text Trace ON
2: Bin Trace ON
3: Text&Bin Trace ON
：
：
-------------------------------------------------------------------------------
value = 0 = 0x0
logout

1.8 Case Analysis of FCN/FCJ Problems

Depending on the type of FCN/FCJ error reported, combined analysis of multiple
types of information is often required. We describe analysis of some case examples in
this section.
These examples are provided as reference to illustrate how to go about analyzing
problems and are by no means exhaustive.
1.8.1 Case Analysis: Retained Data Related Problems

● Problem Encountered
- Retained data is initialized
- Or retained data is reverted to older values.
● Required Information for Analysis

Information See Section:
1. General settings of CPU module 1.5.1
2. Date and time of retained data 1.6.3
of “STARDOM Troubleshooting Guide:
Information Gathering” (TI34P02K03 02E)
3. Log data of FCN/FCJ 1.6.2
● Case Analysis
First of all, check whether the “Enable Hard-backup for retained data” checkbox of the
General Settings of the CPU module is selected to determine whether retained data is
stored on the SRAM.
- If retained data is stored on SRAM (default FCN/FCJ setting)

When the FCN/FCJ is powered off and then powered on or after a warm start,
retained data stored on the SRAM will be used.
If this data is initialized or reverted to older data, it means either retained data was
initialized or retained data was restored from the system card for some reason.
- If retained data is not stored on SRAM

When the FCN/FCJ is powered off and then powered on or after a warm start,
retained data will be restored from the system card.
If this data is initialized or reverted to older data, it means either no retained data was
saved on the system card or the saved data was old.

Next, check the log files of the FCN/FCJ to see whether the following internal codes
were logged to perform chronological analysis of the state of the FCN/FCJ.
For more details, see Section 1.6.2, “Analyzing FCN/FCJ Log Data.”
3505 Retentive data saving begins

3506 Retentive data saving ends
3507 Retained data restoration begins
3508 Retained data restoration ends
3216 Control function starts (Cold Start)
If internal codes 3507 and 3508 indicating retained data restoration were logged, it
means retained data on the SRAM was overwritten by data on the system card then.
If internal code 3216 indicating FCN/FCJ cold start was logged, it means retained
data was initialized then.
If it was confirmed that retained data has been restored, determine when the data was
saved by checking the date and time information of retained data.

1.8.2 Case Analysis: I/O Signal Related Problems

- I/O data of FCN/FCJ differ from data of actual I/O
- IOP or OOP was reported

1. States of Status LEDs of I/O module 1.2.4
2. States of LEDs of power supply module 1.2.1
3. Data of system global variables 1.4.1

4. Resource Configurator definitions 1.5.5
5. Loop Check Tool information 1.5.6
● Case Analysis
First, from the states of the status LEDs of the I/O module, check whether the I/O
module is operating normally. (See Section 1.2,4, “Analyzing Status LEDs of I/O
Modules.”)
Similarly, from the states of LEDs of the power supply module, check whether power
is supplied to an I/O module that requires 24V analog field power supply and verify
that current consumption is equal or less than the rated 4A. (See Section 1.2.1,
“Analyzing States of LEDs of Power Supply Module.”)
From the data of system global variable GS_RAS_IOStat, check the status and error
status of the I/O module. (See Section 1.4.1, “Analyzing Data of System Global
Variables.”)
If there is no problem with the status of the I/O module, check whether any warning
has been reported. If no warning has been reported, use the Loop Check tool to
perform first-level isolation of the cause of the problem into connection-related
problem or application-related problem (See Section 1.5.6, “Analyzing Loop Check
Tool Information.”).
When you have identified the cause, rectify the problem.

1.8.3 Case Analysis: Time Measurement Related

Problems
Time measurement on FCN/FCJ using Timer function block (TP, TON, TOP) or
NPAS_TM was incorrect.

1. Execution duration of tasks 1.3.1
2. Watchdog timer (WDT) error events 1.3.3

3. Control application －
● Case Analysis
The Timer function block (abbreviated as TM FB hereafter) or NPAS_TM measures
time based on the control cycle of a control task and the number of times the TM FB
or NPAS_TM is executed.
For instance, every time TON is executed by a control task having control cycle of 100
ms, it increments the elapsed time by 100 ms.
Assuming the preset time is defined as 1 second, timeout is recognized when TON is
executed 10 times (1 second = 10 times x 100 ms) instead of when exactly 1 second
has elapsed since operation began.
1. Analyze the execution duration of the control task

If measurement of elapsed time is incorrect, first check the execution duration of the
control task. (See Section 1.3.1, “Execution Duration of Tasks.”)
If the execution duration is longer than the control cycle, time measurement will be
incorrect. In the above example, the control task is expected to be executed 10 times
within 1 second. However, if the duration of one of the ten executions is 110 ms
(execution duration > control cycle), the control task will instead be executed 9 times
only and the elapsed time will be recognized as 900 ms.
Executing the task 10 times would require 1.1 second, which unfortunately is longer
than the preset time. (See Section 1.3.3, “Watchdog Timer Error.”)
Moreover, if a watchdog timer is defined with timeout interval equal to the control
cycle, a WDT error will be recorded in the log file when the execution duration
exceeds the control cycle so the log data is also useful for analysis.
2. Analyze the application

If investigation shows that there is no problem in the execution duration of the control
task, check the control application.
Check whether IF or CASE conditional statements, JUMP processing, RETURN
processing, etc. may have caused execution of TM FB or NPAS_TM to be skipped. If
so, time measurement will be incorrect.
FOR-NEXT statements may also cause TM FB or NPAS_TM to be executed more
than once within one control cycle. In this case, timeout will occur before the preset
time.

1.8.4 Heart Beat Timeout Error

A heart beat timeout error indicating an inter-FCN/FCJ communication error was
found in the FCN/FCJ log file.
● Description of Error
When an error is encountered in inter-FCN/FCJ communication, a heart beat timeout
error is recorded in the log file as shown below.
Example:
200*/**/** **:**:** ,ERROR,ERROR,MID=0x2025,ErrNo=0,File=Sdcs_commfb.c, Line=1681,
Msg=Heart beat timeout has occurred (chan=1).(sent=2674433, now=2674753)
200*/**/** **:**:** ,ERROR,ERROR,MID=0x2025,ErrNo=0,File=Sdcs_commfb.c, Line=4411,
Msg=doHBTout()/resetC() called. (chan=1) P=/inet/ -ip 192.168.1.1 -p 20001 -srv
An FCN/FCJ performing inter-FCN/FCJ communication waits for data to arrive from

the remote FCN/FCJ. If no data arrives within 1.5 seconds, the FCN/FCJ sends a
heart beat request to check the status of the remote FCN/FCJ.
Normally, a reply to a heart beat reply is returned immediately to the sender FCN/FCJ
but if no reply is received within 2 seconds for whatever reason, a heat beat timeout
error will be reported.
In the sample log shown above, the IP address of the remote FCN/FCJ in error is
indicated as 192.168.1.1.
Moreover, once a heart beat timeout error is reported, subsequent heart beat timeout
errors will not be reported unless inter-FCN/FCJ communication resumes and then a
communication error occurs again.
For example, if the control network connecting two FCN/FCJs is broken, a heart beat
timeout error will be reported once but no more heart beat timeout error will be
reported while the network remains broken. A heart beat error will be reported again
only if the control network is restored but breaks again.

1. FCN/FCJ log data 1.6.2
2. CPU load 1.3.2
● Case Analysis
Consider the following possible causes of a heart beat timeout error.
- Transmission path failure

- Communication error due to physical failure such as broken LAN cable or HUB
failure
- Communication error due to noise
- Communication error due to increased network load

- Failure of remote FCN/FCJ

- Communication error due to remote FCN/FCJ system down
- High CPU load on remote FCN/FCJ

- Control application processing has higher execution priority than inter-FCN/FCJ
communication so high CPU load on the remote FCN/FCJ may cause inter-
FCN/FCJ communication processing to be delayed, leading to a communication
error.
Next, check the log file of the FCN/FCJ to see whether the heart beat timeout error
was a single occurrence or a frequent occurrence.
A single heart beat timeout error occurrence may be caused by temporary increase in
network load or CPU load.
If the heart beat timeout error was a frequent occurrence, this means that inter-
FCN/FCJ communication failed and resumed repeatedly as explained earlier under
“● Description of Error.” Thus, the error may be caused by permanent increase in
network load or CPU load, noise, LAN cable problem or HUB malfunction.

1.8.5 MISCMP Error

A MISCMP error was found in the log file of an FCN with duplexed CPU, indicating
different outputs between the control side and standby side.
● Description of Error
In a duplex FCN, output values of device labels of the control side and standby side
are compared.
Normally, outputs of the control side and standby side are identical. If they are found
to differ for whatever reason, a MISCMP error will be recorded in the log file.
Example:
200*/**/**
**:**:** , ,ERROR,ERROR,MID=0x2007,ErrNo=0x20080013,File=SdcsRedcyTskSyncQ.c,
Line=1178,Msg=MISCMP Task0:200c0200:2c/80 100 1060101 0 1 0
When the outputs of the control side and standby side differ, control processing
continues with output values of the control side.
If the control CPU fails under this condition and control is switched to the standby
side, sudden changes in outputs may occur.
Consider an example where both control and standby CPUs are operating normally
but the output of a certain DO is ON on the control side but OFF on the standby side.
In this case, the FCN outputs the ON value of the control CPU.
If the control CPU fails in this state, control will be switched to the standby CPU and
the output of the DO will become OFF.
Moreover, as the previous standby CPU now becomes the control CPU, internal data
is updated and the output of the DO immediately reverts to ON.
Thus, as explained above, when control is switched to the standby CPU under
MISCOMP error condition, there may be sudden changes in output values and
momentary inversion of DO outputs, which may affect control adversely.

1. FCN log data 1.6.2
2. Logic Designer’s project －

● Case Analysis
From the data in the log file of the FCN, identify the device label associated with the
MISCMP error and amend the application if necessary.
In the sample MISCMP error log of “Msg=MISCMP Task0:200c0200:0/80 100
1060101 0 1 0” shown above, the “100 1060101 0 1 0” part identifies the source of the
MISCMP error.
“100 1060101 0 1 0” consists of five information parts.

100 1060101 0 10
Part 1 Part 2 Part 3 Parts 4 and
5
- Information part 1
This information part indicates the hexadecimal address of the device label
associated with the MISCMP error.
From information part 1 of “100” of the sample log, we know that the address of the
device label is 100 in hexadecimal, which is equivalent to 256 in decimal.
Next, search for the device label corresponding to the address by displaying Logic
Designer’s device label definitions, which list addresses of device labels sequentially
regardless of device label type.
From the figure shown below, we know that address 256 corresponds to device label
“DO001,” which is the source of the MISCMP error.

This information part indicates the hardware corresponding to the error device label.
It displays sequentially the unit, slot, port and channel associated with the MISCMP
error.
Unit: 1: control unit
2: expansion unit 1
3:expansion unit 2
Slot: Slot number where the I/O module is installed
Port: Always 1
Channel: Channel number of the device label in hexadecimal
In the sample log, information part 2 of “1060101” can be interpreted as follows:

1 06 01 01
Unit Slot Port Channel
Thus, we know that the MISCMP error was reported for channel 1 of the I/O module
installed in slot 6 of the control unit.
This information part contains internal information, which is not useful for problem
analysis.
- Information parts 4 and 5

This part displays the output value of the own CPU followed by the output value of the
other CPU. The own CPU refers to the CPU displaying the log data, which is normally
the control CPU.
In the above example, parts 4 and 5 combined is “1 0” which can be interpreted as
follows:
1 0
Output of own CPU Output of other CPU
From the sample log, we know that the output of the own CPU (control CPU) is 1
(ON) while the output of the other CPU (standby CPU) is 0 (OFF).
- Result
Based on the above analysis, “100 1060101 0 1 0” of the sample log indicates that
the following MISCMP error
Output of control CPU: ON
Output of standby CPU: OFF
was reported for the following device label.

Address of device label: %QB256 or DO001
Installed location: Channel 1 of slot 6 of control unit

1.8.6 Communication Failure between FCN/FCJ and PC

On a PC connected to an FCN/FCJ, all communication attempts with the FCN/FCJ
fail, including data exchange with ASTMAC/VDS, uploading using Logic Designer’s
Debug mode, Logic Designer’s Project Control dialog or Resource Configurator and
display of FCN/FCJ maintenance page in Internet Explorer.
Case 1
Not only did communication attempts between the FCN/FCJ and the PC fail, control
also stopped.
However, ping commands between the FCN/FCJ and the PC succeed.
Case 2
All communication attempts between the PC and FCN/FCJ fail after the IP address of
the FCN/FCJ was modified. However, control processing continues.
Ping commands between the FCN/FCJ and PC are also unsuccessful.

1. States of LEDs of power supply module 1.2.1
Note: As communication between FCN/FCJ and PC cannot succeed, other information cannot be gathered.
● Analysis of Case 1
From the phenomena observed, we conclude that either there is a CPU overload or
the CPU is approaching overload conditions as described in Section 1.3.4.
From the states of the LEDs of the FCN/FCJ and the fact that ping commands
between the FCN/FCJ and PC succeed, we conclude that the FCN/FCJ itself is
operating normally.
If communication fails despite the FCN/FCJ operating normally, it is likely due to high
control application load on the FCN/FCJ, leaving no or little CPU idle time.
As the various communications mentioned earlier have lower execution priority than
control applications, they are performed during CPU idle time. When control
application load is high, leaving no CPU idle time for communication processing,
communication timeout will arise.
On the other hand, replies to ping commands from a PC have high execution priority
than control applications so ping commands will succeed even if there is no CPU idle
time.
Consider the following possible causes for low CPU idle time:
- Prolonged execution of a task of higher execution priority than control tasks
- Short task cycle
- Repetitive processing of a control application fails to end
(For details, see Section 1.3.4, “CPU Overload.”)

- Prolonged execution of a task of higher execution priority than

control tasks
A typical cause of prolonged execution of a task of higher execution priority than
control tasks is broadcast communication on Ethernet. (See Section 1.4.3, “Analyzing
Logic Designer Log Data.”)
To confirm this cause, disconnect all machines other than the FCN/FCJ concerned
from the control network so that the FCN/FCJ concerned and the PC are the only
machines on the network. Alternatively, connect the PC and FCN/FCJ directly using a
cross cable. If the FCN/FCJ is connected to an internal data LAN, disconnect it from
the LAN too.
Check communications between the FCN/FCJ and PC in this state. If communication
recovers, check the log data of the FCN/FCJ for CPU overload errors or WDT errors.
- Short task cycle

Repetitive processing of a control application fails to end
These two causes arise from a control task setting and a control application
respectively.
To confirm these causes, stop control application execution on the FCN/FCJ and
check whether communication recovers.
To stop control application execution, delete the boot project from the system card
using the boot project deletion (FcxDeleteProject) software tool and reboot the
FCN/FCJ. The FCN/FCJ will boot up in a state without any control application running.
If communication failure is due to a control task setting or a control application, by
stopping control application execution, communication should recover.
If communication recovers, check the log file of the FCN/FCJ for CPU overload errors.
After checking the log file, amend the application causing the problem using Logic
Designer and then download the amended project to the FCN/FCJ. Remember to
also download the amended project to the deleted boot project.

- How to execute the boot project deletion (FcxDeleteProject) tool

1. Get the Boot Project Deletion (FcxDeleteProject ) software tool.
Follow the procedure described in Section 1.7.1 for getting the FcxRsh tool.
Beware that the specified destination folder pathname for storing the software
must not contain any space character. For instance, "Documents and Settings"
would not be a valid destination pathname.
2. Shut down and reboot the FCN/FCJ.

When the FCN/FCJ enters boot mode selection state, select to boot up in
Maintenance mode.
3. Run the Boot Project Deletion (FcxDeleteProject) tool.

Open a command prompt window and run the Boot Project Deletion
(FcxDeleteProject) tool by typing:
C:\<folder containing tool>FcxDeleteProject <IP address>
The following sample trace assumes that the FcxDeleteProject tool is stored in
the “tmp\FCXTOOL” folder and the IP address of the FCN/FCJ is “192.168.0.2”
C:\tmp\FCXTOOL>FcxDeleteProject 192.168.0.2
remove "/JEROS/STARDOM/PROCONOS/BOOTFILE.PRO"
value = 0 = 0x0
logout
“logout” is displayed when command execution ends.
4. Restart the FCN/FCJ.

After execution of FcxDeleteProject ends, reboot the FCN/FCJ or power down
and then power up the FCN/FCJ.
● Analysis of Case 2
From the observation that ping commands are unsuccessful, we suspect that the IP
address of the FCN/FCJ may have been modified. One possibility is that the IP
address was set by a DHCP server.
If a DHCP server is present on the network connected to the FCN/FCJ, depending on
when the FCN/FCJ transits to IP address setup mode, the IP address of the FCN/FCJ
may someitmes be set by the DHCP server before it can be set by Resource
Configurator. If an IP address is set by the DHCP server, it is unknown to the PC and
thus the PC cannot properly address the FCN/FCJ and all communication attempts or
ping commands will fail.
In this case, unlike case 1, however, control continues because there is no CPU
overload error on the FCN/FCJ.
To fix this problem, disconnect the FCN/FCJ from the control network, connect the
FCN/FCJ and PC directly and define the IP address. After verifying that
communication between the PC and FCN/FCJ has recovered, connect the FCN/FCJ
to the control network.

Blank Page
< Appendix A Performance Data> 67
Appendix A. Performance Data

Appendix A.1 Estimating Communication Time
● Estimating communication time from VDS
Communication time from VDS depends largely on the CPU load of the FCN/FCJ.
Each data access is estimated to take about 50 ms to 100 ms.
The following graph plots CPU load of the FCN/FCJ against the turnaround time per
packet based on actual time measurements for registering ten PAS_PID objects with
a data server.
2K bytes (2,048 bytes) of data can be accessed per communication. The number of
data items readable per communication varies with data type. Values for some typical
data types are shown below.
Data Type Number of Data Items Readable

per Communication
BOOL
BYTE 512
* All data types smaller than 32 bits
INT are expanded to 4-bytes.
REAL
CDataReal (32 bytes) 64

NPAS_PVI (124 bytes) (*1) 16
NPAS_PID (196 bytes) (*1) 10
*1: The number of bytes for NPAS objects given in the table are obtained by adding bytes for types of “normal scan”
only. Different NPAS objects have different number of bytes for normal scan data.
To calculate the number of bytes accessed for an individual NPAS object, see Chapter C5, “PASPOU Objects” of
“VDS Engineering Manual” (IM 34P02D02-01E).
TI 34P02K03-03E 8th Edition: Jan. 22, 2019-00

< Appendix A Performance Data> 68
The table below shows the number of data items accessible per second for different
data types under different CPU loads (indicative values only):
20% 40% 60%

(50 ms) (*1) (70 ms) (*1) (100 ms) (*1)
PAS_PVI 320 (*2) 224 160
PAS_PID 200 140 100
*1： A value within parentheses ( ) indicates the access time per communication (2 K bytes).
*2： Number of data items per second = Number of data items per communication ×1000 / access time per
communication

i
Revision Information
Document name : STARDOM Troubleshooting Guide: Information Analysis
Document No. : TI 34P02K03-03E
Sep. 2009/First edition/

New issue
Jun. 2012/2nd edition/R3.20

Add new module information（NFLF111,NFLC121,NFLP121）
Sep. 2012/3rd edition/R3.20

・Error corrections
Jun. 2015/4th edition/R3.50

Jul. 2015/5th edition/R4.02

・Added FCN-500
May 2017/6th edition/R4.10

・Added Duolet function on FCN-500
Jun. 2018/7th edition/R4.20

Jan. 2019/8th edition/R4.20

■ For Questions and More Information

If you have any questions, you can send an E-mail to the following address.
E-mail:stardom_info@cs.jp.yokogawa.com
■ Written by Yokogawa Electric Corporation
■ Published by Yokogawa Electric Corporation
2-9-32 Nakacho, Musashino-shi, Tokyo 180-8750, JAPAN

Technical Information: STARDOM Troubleshooting Guide: Information Analysis TI 34P02K03-03E

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Technical Information: STARDOM Troubleshooting Guide: Information Analysis TI 34P02K03-03E

Încărcat de

Drepturi de autor:

Formate disponibile

Technical STARDOM Troubleshooting Guide:

Information Information Analysis

Unit & Integration Test

System Operation &

TI 34P02K03-03E 6th Edition: May 31, 2017-00

■ Organization of This Manual

TI 34P02K03-03E 6th Edition: May 31, 2017-00

Copyright and Trademark Notices

■ Trademark and License Software

TI 34P02K03-03E 6th Edition: May 31, 2017-00

STARDOM Troubleshooting Guide:

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

● Documents describing PC operating environment prerequisites

● FCN/FCJ development/maintenance tools and APPFs

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

1.1.2 Revisions of FCN/FCJ, Development and

● All latest versions of software

● Different versions of software

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

1.2 Analyzing LED States

● 5V system power supply

● 24V analog field power supply

NFAI143 16 points, current input

NFAI841 8/8 points current I/O

NFAI835 4/4 points, current input/current output

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

● Operation when using duplexed power supply modules

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

1.2.2 Analyzing Operating Status LEDs of FCN/FCJ

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

● FCN/FCJ operating status versus LED states

Table FCN/FCJ Operating States versus LED States

Maintenance state Slow On Off FCN/FCJ maintenance (e.g. configuration)

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

● LED display under normal operation

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

● Analyzing LED display patterns

- A system failure has occurred.

Examples of invalid DIP switch settings:

● LED display of duplex FCNs

Table LED Display of Duplex FCN

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

● Analyzing FCN/FCJ boot failures

2. Check power supply to CPU

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

1.2.3 Analyzing Communication Status LEDs of FCN/FCJ

LINK : Lit when the connection to a hub is normal

ON : Lit when the network function is enabled

If the LINK LED is off, check the following items:

- Power supply status of the FCN/FCJ

● Checking status of power supply to FCN/FCJ

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

1.2.4 Analyzing Status LEDs of I/O Modules

● States of STATUS LED

● States of ACT LED

- Verify that definition data has been downloaded from Resource

- Verify that I/O is not disconnected by Logic Designer

TI 34P02K03-03E 8th Edition:Jan. 22, 2019-00

1.2.5 Analyzing Status LEDs of SB Bus Repeat Module

STATUS : Lit when hardware is normal

- Unit number setting of base module