This guide is for logs that were collected with the default logging options. If you have changed the logging options, your logs may have more or less information in them.

How data gets to Hyperview

1. Hyperview asks CIUMon for the data.
2. CIUMon asks the CIU to find out what the data is, and then store it in one of 32 'keys'
3. CIUMon waits for however long its response check delay is. This gives the CIU time to get the data.
4. CIUMon asks the CIU to send the data. It asks for the data by key number.
5. The CIU sends CIUMon the data.
6. CIUMon sends the data to Hyperview.

Log Format

Rach log file begins with information about CIUMon's settings. If CIUMon was stopped and started while log file was being created, there will also be settings information in the middle of the log file.

After the settings information is the data. Remember that many logs begin while CIUMon is already getting data, so some requests may be partially in the log you are looking at and partially in the previous log or the next log.

Each line of logged data looks like this:

timestamp letter data

For CIUMon requests, the letter starts at Z and counts downward, so that timestamp Z is the first line of the request, timestamp Y is the second line, and so on.

For responses, the letter is incremented between lines of the same entry, so timestamp A is the first line of some entry, timestamp B is the second line, and so on. If a single entry has more than twenty-six lines, the last lines will all be marked with Z.

The data is either a sequence of bytes sent to or from the CIU (in hex), or a human-readable description of what is being sent to or from clients (eg Hyperview).

The following sequences of bytes have special meaning:

This	Means this
0D	End of line
1B 0E	0D
1B 1B	1B

Any time you see 1B in the log, it is part of one of the above sequences.

Most of the communication from CIUMon to the CIU will begin with either 14 or 50 (fetch data), 67 (bulk fetch data from RoviSys Turbo), 19 (send fetched data), or 45 (environment fetch). The responses from the CIU generally begin with either 01 (request acknowledged) or 00 (ok, sending data). Some of the other possible messages are explained in How does CIUMon respond to errors?.

Example

When "Alex" sends a request for a piece of data, it gets recorded in the log like this:

14:15:49.781 A read output 2 03 04 5 from IP Address 127.0.0.1 from Alex
14:15:49.781 A 14 01 02 03 00 04 00 05 23 0D 
14:15:49.812 A 01 01 0D 

Note that there may be other lines between these, depending what else CIUMon is doing.

The first line is CIUMon getting the request from Hyperview.

read output	2	03	04	5	from	IP Address 127.0.0.1 from Alex
Type of command	Loop number (in decimal)	PCU number	Module number	Block number	CIUMon is receiving the request	IP address and logon name of the user requesting the data.

The second line is the data CIUMon sent to the CIU. Remember that communication with the CIU is recorded in hex, so if you wanted to decode what was being asked for, and it involved numbers larger than 9, you would need to convert it.

14	01	02	03	00 04	00 05	23	0D
get some data	what key to use	loop	PCU	module (two bytes)	block (two bytes)	checksum	end of line

Note: The first byte in a request for data might sometimes be 50 or 67 instead of 14. A request that starts with a 50 works in a similar way to one that starts with a 14, but it can get more types of data. A request that starts with a 67 is a special type of request that CIUMon uses to communicate with RoviSys Turbo.

The third line is the response from the CIU.

01	01	0D
request acknowledged	checksum	end of line

CIUMon will now delay a bit to give the CIU time to fetch the data, then it will ask the CIU to send the data. It will look kind of like this in the log:

14:15:49.890 A 19 01 1A 0D 
14:15:49.921 A 00 01 28 13 01 3D 0D 

The first line is CIUMon asking for the data.

19	01	1A	0D
send data	key	checksum	end of line

The second line is the data from the CIU.

00	01	28 13 01	3D	0D
ok, sending data	type of value	requested value	checksum	end of line

Finally, CIUMon will send the data back to Hyperview, which is recorded like this:

14:15:49.921 A 			read output 2 03 04 5 to IP Address 127.0.0.1 to Alex
14:15:49.921 B 			OK REAL
14:15:49.921 C 			384.5 High Deviation

The first line contains the same information as the entry when CIUMon received the request, but now it's to the IP and user, because CIUMon is responding.

The second line specifies what kind of data is being sent. In this case, it's REAL.

The third line has the actual value that was sent to Hyperview.

Checksums

When CIUMon sends or receives a communication from the CIU, the last byte before the 0D (end of line marker) is a checksum. To find the checksum, add up all of the preceding bytes in the communication, then take the last two hexadecimal digits from the result. When a communication is received, the bytes in the communication can be added to make sure that result matches the checksum; if it does not, it usually means that the communication was somehow garbled during the transmission.

For example, suppose CIUMon receives a line like this from the CIU:

00 01 36 E8 32 0D 

Adding all of the bytes up to the checksum (that is, everything except the 32 0D) gives 01+36+E8=11F in hexadecimal. So, the checksum in this case should be 1F. Since the line shows 32 instead, this indicates that there was a communication problem. CIUMon would generate an error message if it encountered a line like this.

Note: In this particular case, the problem is that a 13 was missing from the line that the CIU sent to CIUMon. Adding in the 13 would make the checksum correct, since in hexadecimal 1F+13=32. If the checksum is off by exactly 13, this can sometimes indicate that CIUMon has been improperly configured to use XON/XOFF flow control.