ErrorFlags and ResetErrorFlags

Can anyone give me a quick intro to how ResetErrorFlags should work from within a terminal session?

Eg: I have a unit reporting error flags 9:

Code:

get p/25/115 ErrorFlags
  300 //PROJ/25/p/115 errorflags=9

.. which I understand to mean "Power-on reset has occurred since flags last reset" (bit 0) and "Power-up or watchdog reset has occurred since flags last reset" (bit 3).

If I then try:

Code:

do p/25/115 ResetErrorFlags

I get:

Code:

202 Done: //PROJ/25/p/115

However:

Code:

get p/25/115 ErrorFlags

.. still returns 9.

 

I tried both psync and qsync with no effect (I didn't mention it because by that point I was just guessing and tried all sorts of things, but it's good to know that my guesses were along the right lines). I've tried this on two different sites with the same (lack of) results.

If I wanted to experiment with this in the office, what's the easiest way to generate an error on a unit that I can then try to reset?

 

I'm on site again so performing some more tests.

On arrival, network 21 unit 241 is reporting an error.

Code:

get p/21/241 ErrorFlags
300 //PROJ/21/p/241: ErrorFlags=13
do p/21/241 ResetErrorFlags
202 Done: //PROJ/21/p/241
get p/21/241 ErrorFlags
300 //PROJ/21/p/241: ErrorFlags=13
do p/21/241 psync
408 Operation Failed: //PROJ/21/p/241 ()
do p/21/241 qsync
202 Done: //PROJ/21/p/241

psync works fine on other units on the same network.

The only way I can clear the errors seems to be to flush the network:

Code:

net flush 21
200 OK.
net sync 21
...
120-Net Sync: synchronizing unit 41 of 49 at address 241
120-Net Sync: Sync failed for unit 241
...
200 OK.
get p/21/241 ErrorFlags
300 //PROJ/21/p/241: ErrorFlags=0
do p/21/241 psync
408 Operation Failed: //PROJ/21/p/241 ()

This suggests a problem in the unit? I assume that the fact that ErrorFlags=0 after the flush/sync has more to do with C-Gate not knowing any different after the flush than being accurate?

I'll do similar tests on other errors I find to see if this is a one-off. Assuming the problem is in the unit however, what should I do next?

 

Thanks, that's useful to know.

The unit is a mono touch screen, I can check what firmware version when I'm back on site tomorrow. However I have seen this on multiple unit types, including switches and relays.

I can email level 9 logs from the above tests if you like?

If there are any specific tests you'd like me to perform when I'm back on site tomorrow let me know - I can't promise there'll be a unit in fault to test against but if there is I'm happy to experiment.

 

I've done additional tests this morning.

I have two units in error (different networks, both ErrorFlags=9). In both cases psync is failing so although reseterrorflags completes without error, get errorflags continues to return the old value.

For one of the units, net close/net open/net flush/net sync clears the error and psync works afterwards. (The close/open might not have been needed, but net sync alone wasn't sufficient. However see below.)

On the other network I tried net flush/net sync and the unit remained in error (ErrorFlags=9), and psync continued to fail. I then tried close/open/flush/sync and the unit came in fine (no errors, psync worked afterwards).

My conclusion from these tests, contrary to my previous conclusions, is that whatever the issue is it's in C-Gate not the unit, as I can't see why closing and re-opening the network would make the difference otherwise?

I have level 9 logs for this if you want them.

 

I have found very similar things with C-Gate, units being in error in C-Gate and not refreshing, but if you query them from a programming laptop for example they are fine. Haven't had the time to investigate fully though so will be interested in what comes out of your investigations!

 

Useful to know it's not just me!

 

Hi Mark, Just wondering what the system you have is that you are seeing these issues with CGate not refreshing units that have come out of error?

ie,

What is connected to C-Gate? SP+ or ect?
How many networks do you have?
Do you find that you have networks going into error because CGate keeps accumulating units that have gone into error but doesn't clear the units that have returned from being in error?

Thank you!

 

In this case Citect (aka C-Lution). Because we like to be different

36

I'm not sure but I don't think so. I'm not based on site so I only get to see the status periodically so it's hard to be sure, but what it looks like is that issues/works on site will kill power to units temporarily and they'll come back in error, but those errors won't clear so they sit there like that until the server is rebooted (or I do the net close/open steps described above). Generally however the network itself is not going into fault and everything seems to work OK, except that we're getting alarms in the lighting system that don't/won't clear.

A lot of our monitoring is via our own tools that communicate with C-Gate via TCP/IP so we can provide an interface to the ResetErrorFlags/psync command sequence, except that it isn't reliable for the reasons above.

 

Ok that is good to know thanks, we are in a very similar position, but use Schedule Plus, which will stop talking to units when there are to many in error. I can confirm for a fact that the network and units are ok. Restarting C-Gate clears them fine, until they build up again. I guess I could do something like flushing the project when it happens, but the problem is that I like that to be a supervised thing.

I might try and talk to Tech Support again, as I think we might be getting somewhere...

 

My problem with a flush is that when Citect can't get a value for a group address it assumes a value of zero, and that happens for the duration of the close/open/flush/sync. During that time the Citect application will react to those zeros causing unwanted side effects (including switching lights off).

That said we don't have any operational issues with having large numbers of units in error so it's almost a cosmetic issue (although I don't like telling people to ignore alarms).

I have forwarded some logs to support so hopefully they can make some sense of this. I'm more than happy to do more tests if it'll help.