Modbus Appendix; Data Management; Writing Settings; Snapshot Events - GE Multilin G650 Manual

B.4 MODBUS APPENDIX
B.4MODBUS APPENDIX
The different sizes of data to be managed in ModBus and their functionality make it necessary to manage them in different
ways. Depending on the functionality and importance of certain data, the use of ModBus is optimized in time for real time
processes, as in the case of events.
Although configuration settings, such as GRAPHIC, PLC equations, TEXTS and ALARM and LEDS configuration, etc. can
be read and written using ModBus protocol, formats are not shown because these are considered important design
B
information subject to optimization, expansion and in short to changes. For their management, the user can use EnerVista
650 Setup program to manage and format them in a friendly way
The writing process of settings GROUP is formed by two phases: writing of any zone and confirmation. The target is to
guarantee the protections functionality and offer versatility for possible legacy programs.
The process of changing protection functionality will almost always involve the change of several settings at the same time,
requiring a "time point" for new settings operation. The combination of numbers, enums, etc, which cooperate in fulfill a
determined function is called GROUP.
The memory map of a setting GROUP includes: the stored settings at the beginning of its settings zone and a temporary
hole for new settings and confirmation.
When settings are changed, we must write in the selected settings zone, in any order or quantity of written zone, and finally,
to give a reference point we must write a register in the last position of the group, (this is called CONFIRMATION by some
protocols).
For safety reasons, there is certain limitation when CONFIRMING settings GROUPS; the time period from the last settings
writing to CONFIRMATION, cannot exceed 15 seconds.
Nowadays, event retrieval is completely compatible with UR family. In the G650, the NEW EVENTS concept has been
extended, providing additional functionality. These are the events created after the last request.
a) SNAPSHOT EVENT READING IN ASCII FORMAT
The events capture process is based on the opening and reading of a pseudo-file. This process is made in two steps:
1º.- A writing message in the '0xfe00' address, where desired opening file name is written:
- "EVE .TXT":
- "NEW_EVE.TXT": to obtain events created from the last request of this same file
- "EVE0234 .TXT ": to obtain events starting, for example, from 234 rating
2º.- The second and following ones are messages of reading on 0xff00 address, where 244-byte strings are read
from the open file. As this process is a request process, if there was a response string with error, the last string can be
requested again, by a reading message on 0xff02 address.
The first reading message shows the events format, information is transmitted in the rest of messages. In the same string,
the first four bytes indicate the file reading position and the following two bytes form a short with the quantity of useful bytes
sent (if it is lower than 244, this indicates that it is the last message).
In the second step, many BUSY responds may be produced, because internally the ASCII format file is being created.
b) SNAPSHOT EVENTS READING IN BINARY FORMAT:
Write a message in address 0xfe00 to open the file.
B-8
to obtain all
G650 Generator Protection & Control System
APPENDIX B

B.4.1 DATA MANAGEMENT

B.4.2 WRITING SETTINGS
B.4.3 SNAPSHOT EVENTS
GEK-113285A