Reply to Thread

Thank you, but there is an issue... this was an example. the panel has main MBC box and extension with 24 module box. This issue happening on the extension only and in random modules. Not just 61. And the rate is about 10 minutes. I replaced extension module, extended panel Power module and some modules.
It use pressure control modules as Outputs and about 11 input modules.

so how should i troubleshoot the Z8 on this extended panel if it shows random Z8 errors there ?

And they are all Apogee modules with keys. I see it in Insight and we didn't have problem with that in last 15yrs. started recently 6 months ago. It is throwing alarms to a console but they are SYS acknowledged immediately when posted. It just makes a mess.

Z8 failure refers to the Zilog 8 Chip that was used in legacy MCC-Powers Landis and Gyr and later Siemens acquired controllers. Z8 chips are not in the new products. The address you mentioned is off the MBC, not on a FLN. Look for a address key with 61 and that will be your pt module with the issue. If the address key is white, it's a pre Apogee key format, if it's black it's Apogee format.

Originally Posted by mberan

How did you find them? So I have to disconnect the modules one by one and eliminate the module and then check all sensors/devices? But it is random so how the pressure sensor be tested for +/- issue?

Sorry, I should’ve been more clear, +/- was referring specifically to the FLN COMM wires landed at the device.

How did you find them? So I have to disconnect the modules one by one and eliminate the module and then check all sensors/devices? But it is random so how the pressure sensor be tested for +/- issue?

Originally Posted by mberan

Hello, I know this is an old thread, but maybe someone can help me with hint to troubleshoot my issue with Insight and Z8 errors.

I have a MBC panel which has extension starting with module nr. 37. it is running Apogee FW 2.3 and is connected via AEM200 to Insight server.
It has 1 FLN with VFD on it.

And it is showing random errors in the Alarm log :
Z8 Failure in Field Panel 29 0 61
Z8 RETURN from failure in Field Panel 29 0 61
...
...

it usually takes 2-5 seconds only to return from failure but it's annoying and operators are getting "false alarms" that gets Normal before they even acknowledge them.
I replaced power modules, also replaced CPU module on this one and it didn't help.
half of the modules are pressure meters and half just IO modules but the issue is very random and only happens on the extended panel modules.
We were about to replace all modules, but not sure if this can fix the issue. We tried few and no change.

Any hint how to debug the error or where to go next to troubleshoot it ?

Looking forward to the responses to this. I have always believed Z8 failures were due to wiring issues, I have found several devices on FLN trunks with the +/- shorted causing these. Could be a coincidence but they did go away.

Hello, I know this is an old thread, but maybe someone can help me with hint to troubleshoot my issue with Insight and Z8 errors.

I have a MBC panel which has extension starting with module nr. 37. it is running Apogee FW 2.3 and is connected via AEM200 to Insight server.
It has 1 FLN with VFD on it.

And it is showing random errors in the Alarm log :
Z8 Failure in Field Panel 29 0 61
Z8 RETURN from failure in Field Panel 29 0 61
...
...

it usually takes 2-5 seconds only to return from failure but it's annoying and operators are getting "false alarms" that gets Normal before they even acknowledge them.
I replaced power modules, also replaced CPU module on this one and it didn't help.
half of the modules are pressure meters and half just IO modules but the issue is very random and only happens on the extended panel modules.
We were about to replace all modules, but not sure if this can fix the issue. We tried few and no change.

Any hint how to debug the error or where to go next to troubleshoot it ?

Originally Posted by lpeterson

Thanks for the reply,
I'm able to releas them from the front end, and by putting a releas statement in the code the problem is kind of solved. I don't like it but at least it isn't raining.
Thanks
Larry

I've run into this issue frequently, my advise:
1) have a coffee. Relax. It's not going away any time soon.
2) Assuming you are on insight, run Panel Point Address report for the Panel / FLN in question:
- Back in the day, you could only manually unbundle TEC points. (ie: use point editor, create a point for a sub-point. Example: BOB.RM.TEMP 52.1.30.4). The new firmware conflicts with this. Typically this will come across as "failed points", but maybe it will show overrides.
3) Release the sub-point, Delete from system profile, wait a bit for everything to sync up, re-add to system profile and then try an initialization of the device to see if occurs again. (this just worked for me).
4) As a last ditch effort, and a rotten one at that. Try re-naming the device and/or re-addressing the device.

Good luck.

Thanks for the reply,
I'm able to releas them from the front end, and by putting a releas statement in the code the problem is kind of solved. I don't like it but at least it isn't raining.
Thanks
Larry

I may have missed this....
If the TEC is commanded from the MMI port, I have found that no matter how much releasing or what- have- you you do from the front end, the point will still appear in OVD.
If the person who started these controllers did so from a template or "blasted" them, you could find this very problem.
Plug directly into one and release everything and check again. And at least there are only 30.

We have someone from Siemens comming soon. I'll see what he says.
Thanks
Larry

Hi Larry,

I'm sorry that I wasn't clear:

Some of the TEC firmware and some of the older panel firmware would do strange things. i.e command priority would not be displayed correctly.

However, I'm at a loss here. If you have checked both initial values (cabinet and controller) and these points are not commanded in PPCL. The outcome will be most interesting. Please keep us posted.

Originally Posted by lpeterson

Thanks for the reply,
If anyone commanded these points they they should be in "OPER" proirity not "OVRD". I've checked both tec and panel initial values, updated the controllers and reloaded the cabinet. I have bandaged the problem by writting releas commands in the PPCL, but it's a bandage.
Thanks again
Larry

Thanks for the reply,
If anyone commanded these points they they should be in "OPER" proirity not "OVRD". I've checked both tec and panel initial values, updated the controllers and reloaded the cabinet. I have bandaged the problem by writting releas commands in the PPCL, but it's a bandage.
Thanks again
Larry

I'm going to take a stab here:

Is it possible that there is a graphic for the 2051 (fan coil) application? If so, are these points displayed on the graphic that someone may be commanding with the point commander as opposed to the global commander?

If this is the case I have found it just as easy to remove the TEC from the system profile and re-add it. Try a couple and see what happens. Or you could just check initial values at the cabinet to confirm what I suspect.

Originally Posted by lpeterson

I have several "tec" subpoints that keep changing to priority "ovrd" this happens when ppcl comands a subpoint. However there are no ppcl statements in the code commanding these points.
Can anyone help?
thanks Larry

Ahhh, didn't know you had 30 of them doing it.
Hmm, maybe the initial value table in the panel has all the heat.cool points in OVRD and the TEC's are reloading periodically? There would have to be severe problems on the FLN for that but it's worth checking.

Verify that your panel is not periodically coldstarting and reloading. There is a rare condition that can cause what you are describing. If your panel firmware is above 2.5.2, this isn't your problem.

Daramoe would have better info than I but I'd suggest removing the panel that the TEC's are connected to from the BLN. If the problem continues, coldstart the panel. Not a warmstart, but a true, from the command line coldstart.

Are the heat.cool points on a graphic or are they regularly commanded?
What version firmware in the panel and version of Insight?

I like mysteries

Thanks for the reply,
The FLN is plugged in when this happens. It's happening on about 30 TEC's. I'll try to bring it to a Siemens big shot.
Larry

Then my conclusion (assuming this happends with the FLN unplugged and this is witnessed from the TEC\Stat) is that RAM\EEPROM chip is faulty.

Next step is to swap this TEC with another (or install a new\spare) and see if the issue stays or moves.

Good luck, sounds like a mystery to be solved.

Thanks for the reply,
I know that PPCL is the only way these points are supposed to get into "ovrd". I've shown this to several Siemens techs. They don't understand it either.
Larry

The series 2000 stats are "intelligent" and will place the CTL STPT in OVRD during normal operation. However, the HEAT.COOL point would NOT go into OVRD without a command from the panel.

I'm assuming this is not wireless.

Thanks for the reply,
Application 2051. I've run point usage report, tec and panel initial value reports, point address reports. The two points subpoint two "heat.cool" and "ctl stpt" are the ones that change.

Originally Posted by lpeterson

I have several "tec" subpoints that keep changing to priority "ovrd" this happens when ppcl comands a subpoint. However there are no ppcl statements in the code commanding these points.
Can anyone help?
thanks Larry

Have you unplugged the FLN from the TEC to confirm this? Do you have an Insight workstation? If so, have you ran a point usage report to check all the panels? What is the TEC application?