Applies To:
  • CitectSCADA 5.40
Summary:
1. When Citect starts up and you have redundant diskdrv devices, does Citect actually copy the diskdrv device over from the active server or does it request all disk tag values from the active IO Server and update it's own file?

2. If a diskdrv file gets corrupted and causes Citect to go offline with that device will Citect just copy over the good file from the redundant device? It appears that it will not and you have to manually delete the file and restart the IO Server.

3. If you delete the disk file I believe Citect will recreate the file. Does it copy over the backup file from the redundant device or does the IOServer create the file on its own with copying over the redundant file? The reason I ask this is because the customer is saying that if this scenario happens then the newly create file is different in structure than the standby file. They are using some binary comparison between the two files. Any reason why the files are structured different? Are tags organized within the disk file differently if they are created at runtime like this?

4. How is a diskdrv device determined to be online or not? Does Citect try to read all tags?

 

Solution:
1. Citect reads the entire disk PLC file from the other server and then writes the values back to it's file.  When the active server is a primary server, it will copy over to the standby server

2. Citect will not copy the redundant file over the top when it detects a corrupted file. It's designed this way because we may not be able to reliably detect a corrupted file. I expect it would not be a lot of trouble to make it copy the file from the other server if a corrupted file is detected. But the real problem is why the file is being corrupted in the first place. I expect we don't copy the file, because we should be just fixing the corrupted file bug first.

It should look like the following when it reads a disk file

Status is set to DRIVER_BAD_FILE_HEADER, DRIVER_BAD_READ, DRIVER_BAD_SEEK

when the selected file fails validity test three times.

The following scenarios are imagined under these circumstances

Either

1) Another server is writing to the selected file - this might happen for example if this is the primary server, and it has been shut down and is starting up again, and is addressing the secondary ioservser's primary file for the latest data, but the secondary ioserver is just finishing off writing to the file (because the secondary does not call stopunit and therefore the secondary backend may write out a changed unit after the primary takes over). In this situation the file probably will not be corrupt, and the validity check should be retried a couple of times, in case the file becomes free.

2) The file is genuinely corrupt. In this case the 2 retries wont do any good but they wont do much harm either.

If the retries fail then one of the above errors will be returned. These error will be documented in a KB article and the help, as well as added to proterr.dbf, to indicate the file is corrupted and should be deleted. I think automatic deletion or renaming of the file may cause confusion to the user.

If the unit on startup finds no file with good data to read from, it will write out the bare bones file it has created in memory.

If the unit on startup finds a file with good data to read from and it is the primary file for the unit, it will only read the file into memory.

If the unit on startup finds a file with good data to read from and it is not the primary file for the unit, it will read the file into memory, and write it out to the first available file (which should be the primary file). This situation will occur for instance if the secondary IOServer starts some time after the primary. In this case we would like the secondary IOServer to have an immediate hard record of the primary's data, in case something goes wrong with the primary.

3. The redundant file is read on startup. But I think it is also read sometimes while the system is running. Just because the files are binary different does not mean that the data is different. The same data can be stored in the file in different orders. The customer should check if the tag values are different.

4. If the file is not corrupted then it is online. Citect reads the entire file, so all the tags in the file are loaded.

 
Keywords:
 

Attachments