PAC with PICED 4.8.0 Power Failure Restore

There has. There will be two changes in the upcoming PICED service pack:
1. The new PAC firmware should no longer get into this state
2. PICED will have a new menu item which can be used to stop the PAC from going into this re-start cycle and then allow you to transfer new firmware and/or project to the PAC.

We are just testing PICED and PAC at the moment.

 

Darren,

This is indeed good news. Life without the unit for so long has been painful.

 

Ditto on that.

Thanks Darren.

 

Downloaded the Service Pack, recovered my PAC.

Thank you CIS.

Regards
Josh

 

Every time we have power failure (for whatever reason, which happens a lot) for an extended time, I have to manually reset the time because of the PAC setting time to the time we lost power.

Why is the PAC assuming the role of Time Master at power-up?

Clearly a device that has backup power (like Comfort) should be the Time Master or another scheme should be employed like maybe checking the network time first, and if anything other than 0:00 is returned not set the time to the last known PAC time.

 

The PAC has an internal clock which will maintain the correct time for up to a 24 hour power failure. When power is applied again, the time should be within a few seconds of the correct time. It will not be the time of the power failure. If the power failure is longer than 24 hours, then the results are a little unpredictable.

All C-Bus devices which use the time arbitrate to determine which will be the time master following a power failure. Generally, the most "accurate" device will win.

I am not sure whether the Comfort device participates in time mastering.

 

I think Comfort does indeed send time updates. From my Monitor software I see the following:

Unfortunately I cannot see who is sending it but from the explanation below it must be Comfort because I only have a PAC on my network.

 

Thanks Darren for your speedily response.

I have removed Comfort from my network and simulated a power failure by cutting power for a few minutes at a time, and every time the PAC restarts (powers up), it will wait a few seconds and then broadcast the downtime, which indicates that the internal clock might not be coming into play.

The same applies when we have a real power failure, the system time is always reset to the time we had the power failure.

 

I have just tested this with PAC firmware V3.51 and it works correctly. The steps I took were:
1. Connect a PAC to a C-Bus network with no other time related units
2. Connect the C-Bus Diagnostic Utility to the network
3. Use C-Bus Diagnostic Utility to set the C-Bus time (and hence PAC time) to match the PC time
4. Disconnect the PAC
5. Wait for 5 minutes
6. Reconnect the PAC
7. After a delay of about a minute, the PAC broadcasts the time and it is within a few seconds of the correct time. This can be seen in the C-Bus Diagnostic Utility log.

Can you follow these steps and let us know the results?

 

Will do, am in the US at the moment, will test as soon as I get back to South Africa.

 

Darren,

I am back in SA, and have done the test as suggested (multiple times).

I have followed your steps after updating both Toolkit and PICED to the latest versions. I removed Comfort from the network. Unit 5 is PAC, GA 42 is the light in the room I was doing the testing in. The Green Time Change is via the C-Bus Diagnostic Utility, and the RED is Unit 5 after 10 minutes of being disconnected.

This was done multiple times, with Comfort disconnected, and both Toolkit and PICED updated. Blue is the second C-Bus Diagnostic Time Change and Silver the second PAC reconnect.

Code:

2010/09/01 16:39:35.06  Tx : \053800012Ag<CR>
2010/09/01 16:39:35.06  Tx :  = Local Network, Multipoint, Lighting, GA 42 Off
2010/09/01 16:39:35.13  Rx : g.
2010/09/01 16:39:35.13  Rx :  = OK
2010/09/01 16:39:39.63  Tx : \053800792Ah<CR>
2010/09/01 16:39:39.63  Tx :  = Local Network, Multipoint, Lighting, GA 42 On
2010/09/01 16:39:39.69  Rx : h.
2010/09/01 16:39:39.69  Rx :  = OK
[COLOR="Green"]2010/09/01 16:39:53.10  Tx : \05DF000D0110273500i<CR>
2010/09/01 16:39:53.10  Tx :  = Local Network, Multipoint, Time, Clocks: Time: 16:39:53 Daylight Savings Offset: 0 hour(s)
2010/09/01 16:39:53.16  Rx : i.
2010/09/01 16:39:53.16  Rx :  = OK[/COLOR]
2010/09/01 16:40:04.76  Tx : \053800012Aj<CR>
2010/09/01 16:40:04.76  Tx :  = Local Network, Multipoint, Lighting, GA 42 Off
2010/09/01 16:40:04.82  Rx : j.
2010/09/01 16:40:04.82  Rx :  = OK
2010/09/01 16:40:10.29  Tx : \053800792Ak<CR>
2010/09/01 16:40:10.29  Tx :  = Local Network, Multipoint, Lighting, GA 42 On
2010/09/01 16:40:10.34  Rx : k.
2010/09/01 16:40:10.34  Rx :  = OK
2010/09/01 16:40:31.17  Rx : 0505380001C9017F02FEFA7A<CR>
2010/09/01 16:40:31.17  Rx :  = Local Network, Source Unit 5, Lighting, GA 201 Off; GA 127 Off; GA 254 Set to 250
2010/09/01 16:40:34.15  Rx : 0505D00009A17C<CR>
2010/09/01 16:40:34.15  Rx :  = Local Network, Source Unit 5, Security, Security: Status Report 2 Request
2010/09/01 16:40:34.55  Rx : 0505D00009A07D<CR>
2010/09/01 16:40:34.55  Rx :  = Local Network, Source Unit 5, Security, Security: Status Report 1 Request
2010/09/01 16:40:46.22  Rx : 050538000161015F12FD08013F6232005A2F0088<CR>
2010/09/01 16:40:46.23  Rx :  = Local Network, Source Unit 5, Lighting, GA 97 Off; GA 95 Off; GA 253 Ramp to 8 at 8s rate; GA 63 Off; GA 50 Ramp to 0% at 7m rate; GA 47 Ramp to 0% at 5m rate
2010/09/01 16:40:46.62  Rx : 050538004A21001A2C000A0F003A1700222D0054<CR>
2010/09/01 16:40:46.63  Rx :  = Local Network, Source Unit 5, Lighting, GA 33 Ramp to 0% at 2m rate; GA 44 Ramp to 0% at 12s rate; GA 15 Ramp to 0% at 4s rate; GA 23 Ramp to 0% at 1m rate; GA 45 Ramp to 0% at 20s rate
2010/09/01 16:40:46.75  Rx : 05053800322E005E<CR>
2010/09/01 16:40:46.76  Rx :  = Local Network, Source Unit 5, Lighting, GA 46 Ramp to 0% at 40s rate
2010/09/01 16:40:51.15  Rx : 0505380001FEBF<CR>
2010/09/01 16:40:51.16  Rx :  = Local Network, Source Unit 5, Lighting, GA 254 Off
[COLOR="Red"][B]2010/09/01 16:40:55.74  Rx : 0505DF00110303<CR>
2010/09/01 16:40:55.75  Rx :  = Local Network, Source Unit 5, Time, Clocks: Request Refresh
2010/09/01 16:41:37.81  Rx : 0505DF000E0207DA0901020D01101F1800C5<CR>
2010/09/01 16:41:37.82  Rx :  = Local Network, Source Unit 5, Time, Clocks: Date: Wednesday 1/9/2010; Clocks: Time: 16:31:24 Daylight Savings Offset: 0 hour(s)[/B][/COLOR]
[COLOR="Blue"]2010/09/01 16:42:07.59  Tx : \05DF000D01102A0700l<CR>
2010/09/01 16:42:07.60  Tx :  = Local Network, Multipoint, Time, Clocks: Time: 16:42:07 Daylight Savings Offset: 0 hour(s)
2010/09/01 16:42:07.67  Rx : l.
2010/09/01 16:42:07.67  Rx :  = OK
[/COLOR]2010/09/01 16:48:41.56  Rx : 0505380001C9017F02FEFA7A<CR>
2010/09/01 16:48:41.56  Rx :  = Local Network, Source Unit 5, Lighting, GA 201 Off; GA 127 Off; GA 254 Set to 250
2010/09/01 16:48:44.52  Rx : 0505D00009A17C<CR>
2010/09/01 16:48:44.53  Rx :  = Local Network, Source Unit 5, Security, Security: Status Report 2 Request
2010/09/01 16:48:44.92  Rx : 0505D00009A07D<CR>
2010/09/01 16:48:44.93  Rx :  = Local Network, Source Unit 5, Security, Security: Status Report 1 Request
2010/09/01 16:48:56.60  Rx : 050538000161015F12FD08013F6232005A2F0088<CR>
2010/09/01 16:48:56.61  Rx :  = Local Network, Source Unit 5, Lighting, GA 97 Off; GA 95 Off; GA 253 Ramp to 8 at 8s rate; GA 63 Off; GA 50 Ramp to 0% at 7m rate; GA 47 Ramp to 0% at 5m rate
2010/09/01 16:48:57.00  Rx : 050538004A21001A2C000A0F003A1700222D0054<CR>
2010/09/01 16:48:57.01  Rx :  = Local Network, Source Unit 5, Lighting, GA 33 Ramp to 0% at 2m rate; GA 44 Ramp to 0% at 12s rate; GA 15 Ramp to 0% at 4s rate; GA 23 Ramp to 0% at 1m rate; GA 45 Ramp to 0% at 20s rate
2010/09/01 16:48:57.11  Rx : 05053800322E005E<CR>
2010/09/01 16:48:57.12  Rx :  = Local Network, Source Unit 5, Lighting, GA 46 Ramp to 0% at 40s rate
2010/09/01 16:49:01.51  Rx : 0505380001FEBF<CR>
2010/09/01 16:49:01.52  Rx :  = Local Network, Source Unit 5, Lighting, GA 254 Off
[COLOR="Silver"]2010/09/01 16:49:06.12  Rx : 0505DF00110303<CR>
2010/09/01 16:49:06.12  Rx :  = Local Network, Source Unit 5, Time, Clocks: Request Refresh
2010/09/01 16:49:48.17  Rx : 0505DF000E0207DA0901020D01102B1E00B3<CR>
2010/09/01 16:49:48.18  Rx :  = Local Network, Source Unit 5, Time, Clocks: Date: Wednesday 1/9/2010; Clocks: Time: 16:43:30 Daylight Savings Offset: 0 hour(s)[/COLOR]
2010/09/01 16:50:51.57  Tx : \053800012Am<CR>
2010/09/01 16:50:51.58  Tx :  = Local Network, Multipoint, Lighting, GA 42 Off
2010/09/01 16:50:51.63  Rx : m.
2010/09/01 16:50:51.63  Rx :  = OK
2010/09/01 16:50:54.65  Tx : \053800792An<CR>
2010/09/01 16:50:54.65  Tx :  = Local Network, Multipoint, Lighting, GA 42 On
2010/09/01 16:50:54.72  Rx : n.
2010/09/01 16:50:54.72  Rx :  = OK

Let me know if you need anything else.

 

Darren, did you get a chance to look at the logs?

 

Anyone from CIS looking at this issue?

 

I have been on leave for three weeks (no Internet access), but I am back now. Please remember that this in an unofficial forum and there is no guarantee that anyone from CIS will respond to any particular issue. We do try our best though

It looks to me like it might be some sort of hardware problem but I can not work out exactly what is going on. The only things I can think of doing are:
1. Put a very simple project in the PAC (for example, just flashing the LED) to see whether the problem is related to the project somehow.
2. Try a different PAC.

 

Noted.

I do not have a second PAC, but I will try creating a simple project and seeing the results.

 

Hi Darren,

I tried a very simple project and I get the same problem.

Regards
Josh

 

It seems most likely that it is a hardware problem.

 

It seems I will have to retire the unit. Even if I add another PAC, both might try do TIME and the old unit might win. Unless if a feature to turn time broadcast off is added

 

We had power failure on Saturday for an hour. When power was restored, went to one of the DLTs to try set the time, and to my surprise, the system time was correct .