GSV module status of EN2TR in secondary chassis.

[lijochrn]

Hello, I have a question regarding the status checking of the module in the secondary chassis in a redundancy setup.


CHASSIS 1 : CPU/EN2TR1/RM/EN2TR2
CHASSIS 2 : CPU/EN2TR1b/RM/EN2TR2b

Using GSV I can check Chassis 1 EN2TR1 & EN2TR2 status for module errors.

But how can I monitor the EN2TR1b & EN2TR2b status using GSV?
GSV Instance Name asks for only one instance name and that is always Chassis 1.

or does it mean always only the primary chassis is always being monitored?

if CHASSIS 1 is PRIM then I will get its own module status?
if CHASSIS 2 is PRIM then I will get its own module status?

Simualtaonus GSV monitoring for all modules is not possible?

 

[lijochrn]

Update after lot of searching I found the fix.
Secondary chassis can be monitored using GSV by entering the IP address of the secondary Comm module.

CHASSIS 1 : CPU/EN2TR1/RM/EN2TR2
CHASSIS 2 : CPU/EN2TR1b/RM/EN2TR2b

GSV parameter for RM in PRIM module as 1,2
GSV parameter for RM in SECO module 1,1,2,192.168.10.2,1,2

IP address 192.168.10.2 = EN2TR1b which is the ring network connecting both CPU

 

[Operaghost]

As long as the module is in the I/O Config you can select it in the Instance Name field.

I usually put the GSV instructions into Periodic Task which I usually setup at 500ms. You could also use a timer to call the GSVs in a subroutine.

There is no need to trigger GSVs for all modules all the time. I sort of do a cascade where I start by looking at the controller's status (GSV checking LEDStatus). If it is ok, then I don't bother triggering GSVs for any other modules. If I detect the OK light is not solid green, then I trigger GSVs for modules in the local chassis. Then if an Ethernet module is not "running" I trigger GSVs for the remote ENET modules connected to it.

OG

 

[Tim Ganz]

There is no need to trigger GSVs for all modules all the time. I sort of do a cascade where I start by looking at the controller's status (GSV checking LEDStatus). If it is ok, then I don't bother triggering GSVs for any other modules. If I detect the OK light is not solid green, then I trigger GSVs for modules in the local chassis. Then if an Ethernet module is not "running" I trigger GSVs for the remote ENET modules connected to it.

OG

Can you explain this further? I would think if the ok light is not solid green the GSV all modules in local chassis and if all are good then GSV modules in the remote chassis?

If an ethernet module in the main chassis is not running as you said and if it's what connects the local chassis to the remote chassis how could you GSV modules connected to it in the remote chassis as the connection would not be active if it's faulted?

 

[Operaghost]

Can you explain this further? I would think if the ok light is not solid green the GSV all modules in local chassis and if all are good then GSV modules in the remote chassis?

If an ethernet module in the main chassis is not running as you said and if it's what connects the local chassis to the remote chassis how could you GSV modules connected to it in the remote chassis as the connection would not be active if it's faulted?

An Ethernet module can detect that there is a fault with a connected device but still continue to function. Lets say that the problem we have is with a digital input module in one of my remote chassis. Yes, my CPU, local Ethernet, and remote Ethernet modules will all show that we have a problem. However, the fault that remote I/O module is experiencing doesn't render my local and remote Ethernet modules useless. They are still functioning. We are still communicating successfully with all the other modules in the system.

In the end, we have a GSV for every module I wish to monitor. I am simply adding logic to only execute the specific GSVs we need ay a given time. Having these instructions executing all the time is a waste of CPU cycles. You could certainly have every GSV executing every scan, or use timers to trigger them.

Explaining a little more, if the CPU I/O light is solid green, then all connected modules (local and remote) are running. No need to run GSVs (MODULE) for anything other than the CPU (LEDStatus). If the I/O light is flashing green then at least one module has failed. We need to identify which module(s) and where those modules are located. So first, we run a GSV for each module in the local chassis, including the local Ethernet module. We want to see a result that tells us the modules are running. That will be represented by a value of 16#4000. If we detect that our local Ethernet module is returning a value that is not equal to 16#4000, then we need to drill into that network to locate the problem. That problem doesn't necessarily mean the Ethernet module is non-functional. The problem might be with a digital input module in a remote chassis. That doesn't mean that the local and remote Ethernet modules stop functioning.

Once I have identified that the problem is connected to my local Ethernet module, then I enable a GSV to check the remote Ethernet modules. Assuming I have more than one remote Ethernet device. Let's say I have three remote chassis. I will enable a GSV for each of those three devices so we can locate which of those three chassis have the problem. Once I determine which remote Ethernet module has the problem, then I enable a GSV for each module in that remote chassis. Now we should be able to identify which specific module has the issue.

If I run a GSV on my local module and it determines a problem on my local Ethernet module and I then enable the GSVs for my three remote Ethernet devices and they all fail. that tells me the problem is likely somewhere from my local Ethernet module possibly to the switch it connects to. If however only one remote module reports an error, and then I enable a GSV for each remote module in that chassis and they all error, then the problem is probably somewhere from the switch to the remote Ethernet module.

OG

 

[Tim Ganz]

An Ethernet module can detect that there is a fault with a connected device but still continue to function. Lets say that the problem we have is with a digital input module in one of my remote chassis. Yes, my CPU, local Ethernet, and remote Ethernet modules will all show that we have a problem. However, the fault that remote I/O module is experiencing doesn't render my local and remote Ethernet modules useless. They are still functioning. We are still communicating successfully with all the other modules in the system.

In the end, we have a GSV for every module I wish to monitor. I am simply adding logic to only execute the specific GSVs we need ay a given time. Having these instructions executing all the time is a waste of CPU cycles. You could certainly have every GSV executing every scan, or use timers to trigger them.

Explaining a little more, if the CPU I/O light is solid green, then all connected modules (local and remote) are running. No need to run GSVs (MODULE) for anything other than the CPU (LEDStatus). If the I/O light is flashing green then at least one module has failed. We need to identify which module(s) and where those modules are located. So first, we run a GSV for each module in the local chassis, including the local Ethernet module. We want to see a result that tells us the modules are running. That will be represented by a value of 16#4000. If we detect that our local Ethernet module is returning a value that is not equal to 16#4000, then we need to drill into that network to locate the problem. That problem doesn't necessarily mean the Ethernet module is non-functional. The problem might be with a digital input module in a remote chassis. That doesn't mean that the local and remote Ethernet modules stop functioning.

Once I have identified that the problem is connected to my local Ethernet module, then I enable a GSV to check the remote Ethernet modules. Assuming I have more than one remote Ethernet device. Let's say I have three remote chassis. I will enable a GSV for each of those three devices so we can locate which of those three chassis have the problem. Once I determine which remote Ethernet module has the problem, then I enable a GSV for each module in that remote chassis. Now we should be able to identify which specific module has the issue.

If I run a GSV on my local module and it determines a problem on my local Ethernet module and I then enable the GSVs for my three remote Ethernet devices and they all fail. that tells me the problem is likely somewhere from my local Ethernet module possibly to the switch it connects to. If however only one remote module reports an error, and then I enable a GSV for each remote module in that chassis and they all error, then the problem is probably somewhere from the switch to the remote Ethernet module.

OG

Thanks for explaining further that makes a lot of sense now. If you ever have a copy of similar logix from a past program you could share I would love to take a look at it.

Sounds like a great way to keep all the GSV from tasking the system so hard.

Thanks OG

 

[JeremyM]

GSV for module status has a minimal impact.