D
Hi guys,
Hopefully somebody on here will be able to help me. I'm a graduate so please bear with me, but I will explain the issue I am having trouble getting my head around as clearly as I can, although it might be a bit lengthy. Here goes...
We have 2 Schneider Quantum PLC's, configured as master/standby. To be clear, I am told these are not the hot standby versions of the Quantum. for reasons I won't go into, we cannot use them on this project (or at least so I am told). Because of this, there is a lot of manual configuration being done both within the PLC and SCADA. It is the SCADa side of things I am struggling to understand.
I have the task of modifying/refurbishing a current Citect SCADA project to communicate with the new hardware upgrades which are currently being put in place. This gives me a starting block, as I am told that the current master/standby config within Citect is similar to what needs to be done with the upgraded equipment.
Currently, there is a Cicode document containing 1 function which looks at each PLC's heartbeat/watchdog, and uses IODeviceControl() to disable/enable IODevices (or 'routes' as they are referred to in the comments) depending on which device is deemed to be most healthy/isn't suffering from a fault.
To each IOServer, there are 4 devices added, which covers 2 PLC's out in the field (ie 2 devices added per PLC). My only explanation for this sort of configuration/IODdevice structure would be so that individual data from each PLC can be read (heartbeat, comms status etc) through one device, and plant data can be read through another device. Although looking at the tags, it doesn't appear to be this black and white.
To attempt to illustrate what I mean, here is the structure of the IODevices and their configuration:
IOServer1:
- IODevice1 (192.168.1.1) <Primary, Priority1
- IODevice2 (192.168.1.2) <StandbyWrite, Priority2
- IODevice3 (192.168.1.1) <Primary, Priority1
- IODevice4 (192.168.1.2) <Primary, Priority1
The CiCode document which deals with the route switching simply uses IODeviceControl () to disable/enable IODevice1 and IODevice2. My confusion comes when I find in there are tags declared for IODevice1, 3 and 4, but not IODevice2.
Obviously, this project functions perfectly and is in use. In the event that IODeviceControl() is called to disabled IODevice1, and enable IODevice2, how does Citect manage to read plant data when there are no tags declared for this device?
The thoughts tell me it must have something to do with the fact that the two devices are configured with Primary and StandbyWrite paramaters, with different priorities, and that Citect will read the same tag names as declared for IODevice1, from IODevice2.
Wow... that was an essay
Really sorry if I have gone into two much depth there but I am pretty confused. I figured the more detail, the better!
If anyone could help in anyway at all, I would massively appreciate it.
Thanks DB
Hopefully somebody on here will be able to help me. I'm a graduate so please bear with me, but I will explain the issue I am having trouble getting my head around as clearly as I can, although it might be a bit lengthy. Here goes...
We have 2 Schneider Quantum PLC's, configured as master/standby. To be clear, I am told these are not the hot standby versions of the Quantum. for reasons I won't go into, we cannot use them on this project (or at least so I am told). Because of this, there is a lot of manual configuration being done both within the PLC and SCADA. It is the SCADa side of things I am struggling to understand.
I have the task of modifying/refurbishing a current Citect SCADA project to communicate with the new hardware upgrades which are currently being put in place. This gives me a starting block, as I am told that the current master/standby config within Citect is similar to what needs to be done with the upgraded equipment.
Currently, there is a Cicode document containing 1 function which looks at each PLC's heartbeat/watchdog, and uses IODeviceControl() to disable/enable IODevices (or 'routes' as they are referred to in the comments) depending on which device is deemed to be most healthy/isn't suffering from a fault.
To each IOServer, there are 4 devices added, which covers 2 PLC's out in the field (ie 2 devices added per PLC). My only explanation for this sort of configuration/IODdevice structure would be so that individual data from each PLC can be read (heartbeat, comms status etc) through one device, and plant data can be read through another device. Although looking at the tags, it doesn't appear to be this black and white.
To attempt to illustrate what I mean, here is the structure of the IODevices and their configuration:
IOServer1:
- IODevice1 (192.168.1.1) <Primary, Priority1
- IODevice2 (192.168.1.2) <StandbyWrite, Priority2
- IODevice3 (192.168.1.1) <Primary, Priority1
- IODevice4 (192.168.1.2) <Primary, Priority1
The CiCode document which deals with the route switching simply uses IODeviceControl () to disable/enable IODevice1 and IODevice2. My confusion comes when I find in there are tags declared for IODevice1, 3 and 4, but not IODevice2.
Obviously, this project functions perfectly and is in use. In the event that IODeviceControl() is called to disabled IODevice1, and enable IODevice2, how does Citect manage to read plant data when there are no tags declared for this device?
The thoughts tell me it must have something to do with the fact that the two devices are configured with Primary and StandbyWrite paramaters, with different priorities, and that Citect will read the same tag names as declared for IODevice1, from IODevice2.
Wow... that was an essay
Really sorry if I have gone into two much depth there but I am pretty confused. I figured the more detail, the better!If anyone could help in anyway at all, I would massively appreciate it.
Thanks DB
