What does coldstarting a panel do?

[stomachbuzz]

Now I'm curious

When in training for Siemens, if there was one thing the veteran techs would pounce on, it was cold starting a panel.
In the beginning, it seemed like just about anything I wanted to do was met with "NO NO NO. You can't do that! It will cold start the panel!"

uhm...okay...?

What various people tried to explain to me is what I now realize is just RAM vs ROM.

After reading Siemens documentation, it clearly laid out the memory break down of their modern field panels. Even though the Big Brains Boy on the block has a staggering 80mb of memory (with a 133mHz processor ), only 16mb is ROM with the remainder being RAM.
Well that's weird, I originally thought. Because computers have storage media many times larger than their RAM. Maybe a 500gb hard drive and 8gb of ram.

The documentation went on to state that the entirety of the database is stored in RAM, which is volatile, meaning it will be completely wiped upon even the slightest flicker of power loss.
Hmm...that's inconvenient.

And it IS. Massively. Which is why those veteran techs would slap my hands away like mosquitos on the annoying guy's forehead.

Siemens panels store only the essentials in the [serial] EEPROM, such as the IP address, name, instance number, and that's pretty much it. There's actually a very small amount of this memory.
Then the newer panels have a bit of flash memory, which is the 16mb.
This is where they store their operating systems and do have the ability to save a backup of their database to be restored upon a power loss or any other time.
Upon powering up, their entire database is then moved into RAM from ROM and it stays there, for eternity, or until the next power cycle.

This is why the preservation of the AA battery is so important, to keep juice on that volatile memory.

Even worse, many functional processes will cold start a Siemens panel, such as a loading a new database to it. As procedure, the loader tool will wipe the panel clean, so it knows that the incoming database is all that's on there.
Even though it's intentional and predicted, it's still frowned upon because that panel is offline for some time.

This entire whacky and massively inconvenient characteristic revolves around one simple issue: the life span of ROM. Every type of ROM media has a finite number of write cycles. From solid disk HDDs, to modern flash memory, CDs, etc. They all have limited write cycles, which is abundantly critical for something like BAS controllers that operate 24/7, 365 for decades sometimes.

WOW! What a hurdle.

While in training today with my new ALC gig, I thought to ask my manager "what does it mean to coldstart these panels?" And he didn't quite know what I was getting at when I tried to relate it to Siemens.

So, this got me curious...

What does cold-starting YOUR panel do?

Interested to see how this varies between vendors.

[numbawunfela]

Distech doesn't care about a power cycle one teensy bit. Nor Johnson, nor Delta.
Schneider continuum might. I know they have a menu option to warm start and coldstart their controllers.... and they have a 'backup to flash' command...

[numbawunfela]

While in training today with my new ALC gig....

Good for you getting training... that seems like a good start.

[MaxBurn]

ALC program and parameters are stored in that module to flash. The LGR line that's getting phased out now updates the flash once in a while (LED indicating that) and most recent running copy is stored in RAM that is battery backed (Module alarm if bad). The newer Optiflex modules utilize a supercap to save running config to flash on a power down. ZN and S modules can get memory wiped if the battery dies and see a power loss, they also don't have a realtime clock so after a power cycle need to see a time master to get back on schedule even if they have memory.

In the event that any of the above fails you are a download away from working again regardless if a battery is dead or not.

OEMCtrl ALC modules change things a little, some modules have a running config that gets backed to flash AND a "default factory settings" state you can restore to with some combination of dip/address settings.

Legacy CMnet TNI and UNI are also different than all the above, in general they are remote controlled over the wire from the TNI/UNI and don't have memory in the field controllers.

[stomachbuzz]

Distech doesn't care about a power cycle one teensy bit. Nor Johnson, nor Delta.
Schneider continuum might. I know they have a menu option to warm start and coldstart their controllers.... and they have a 'backup to flash' command...

Knowing what I now do about computer science, there's something else going on there.
RAM being volatile without a power supply is a universal issue with computers from the dawn of the transistor.
Those controllers must either have batteries to bridge the gap of discontinuous power supply, or a capacitor that allows them to save their database in flash before shutting down.

To clarify, you can power cycle a Siemens panel without issue if it has a good AA battery. It will come back immediately with no downtime. The issue is when it does not have a good AA battery, or the controller is 'intentionally' cold started as required when changing parameters such as Instance #, IP address, object name, etc.
Additionally, the modern controllers do have flash memory that provides autosave and auto-restore functionality.

I suppose power cycling it with a good battery would be 'warm starting'.

ALC program and parameters are stored in that module to flash. The LGR line that's getting phased out now updates the flash once in a while (LED indicating that) and most recent running copy is stored in RAM that is battery backed (Module alarm if bad). The newer Optiflex modules utilize a supercap to save running config to flash on a power down. ZN and S modules can get memory wiped if the battery dies and see a power loss, they also don't have a realtime clock so after a power cycle need to see a time master to get back on schedule even if they have memory.

In the event that any of the above fails you are a download away from working again regardless if a battery is dead or not.

OEMCtrl ALC modules change things a little, some modules have a running config that gets backed to flash AND a "default factory settings" state you can restore to with some combination of dip/address settings.

Legacy CMnet TNI and UNI are also different than all the above, in general they are remote controlled over the wire from the TNI/UNI and don't have memory in the field controllers.

Cool. When my manager told me how ALC had switched from capacitors to batteries back to capacitors, I had a hunch that the capacitor was really just to hold enough charge for the controller to realize it had lost main power and to save the database to flash.

The realtime clock thing is interesting since that is something I asked him.
I did not realize it, but that actually was a semi-fundamental thing in the relationship between Siemens field panels and the field devices.
The panels kept a real time clock, synchronized with the front end twice a year. This is essential as you can reference time of day in the programming. "Turn fan on at 06:00"
But the field devices, not so much. Especially true with the older ones, the only thing they were dependent on time of day for was switching from occ to unocc mode (day/night mode).
This schedule switchover was input at the front end and would propagate down to the supervisory level controllers which would then send it to their respective field devices. Because they could operate independently, a loss of comm was okay with the exception that they would stay in whatever day/night mode they were in when they lost comm.

I have a feeling that timekeeping is one of those once-very-worried-about aspects of computing that is now the most minor of concerns. I suspect that it is quite essential and probably rather complicated when getting into technicals. As you have to enter either 50 or 60hz mains power when setting the time on a Siemens panel, I assume it just keeps time that way, which probably many electronic devices do, further emphasizing the importance of dead-on generator speed by our electrical grid.

The Siemens panel is also just 'a download away' from being A-okay, too, but... the issue arises when 1) the front end has to detect the panel has a database that is out of sync, and 2) actually restore that panel's database via the network.

Usually it works okay, except when you have a large legacy campus that has 100s of controllers reporting in over a single twisted pair cable at 19.2 baud. Serial communication combined with multitasking can make that a slow task.

[MaxBurn]

ALC never used capacitors in the past I'm aware of before Optiflex. The modules either had batteries or they didn't have anything to lose because they were remotely controlled like T or U series zone controllers, where the controlling TNI/UNI had the program and battery backup.

Time in ALC world historically has been pushed out to modules with RTC once a day and they then serve as time masters for those without RTC. So a ZN or S with power blip and no comm is a problem.

ALC's newest controllers fwex/optiflex will eventually get gen5 drivers that will include NTP, Network Time Protocol. Modern analytics and BACnet/SC will require accurate clocks.

https://en.wikipedia.org/wiki/Network_Time_Protocol

[s2sam]

Knowing what I now do about computer science, there's something else going on there.
RAM being volatile without a power supply is a universal issue with computers from the dawn of the transistor.
Those controllers must either have batteries to bridge the gap of discontinuous power supply, or a capacitor that allows them to save their database in flash before shutting down.
<snip>

Good day stomachbuz,

Not all controllers are designed in the manner you present. Some controllers operate its firmware out of non volatile memory (Flash) and use RAM for general data storage. Thus a power bump, cycle, etc will not cause any issues other than rebooting the controller and perhaps creating an offline condition until the controller is back up and running. Other controllers copy their operating firmware from Flash to RAM in order to improve performance, etc and these are not usually sensitive to power loss issues, but this would depend upon their firmware design, etc. Controllers using more sophisticated operating systems (Windows, Linux, etc) have active memory intensive background tasks, etc in order to improve performance and to optimize things. The problem with these approachrd is that unless specific design considerations are made, the background memory gymnastics can cause memory corruptions during abrupt power losses. To minimize or prevent these type of corruptions various things have to do implemented... from on-board batteries, SuperCaps, or an external UPS to allow for a controlled shutdown, to making the file system read-only, or adding redundant or duplicated file system or system images that can be checked upon startup.

As for on-board real time clocks (RTCs)... A lot of RTC devices allow provisions for the inclusion of a small battery or SuperCap to be used to maintain the RTC's time keeping circuits functioning during short term primary power failures. These small external power sources are only fed into the RTC device and do not typically power the main controller. More sophisticated controllers with Ethernet capability can use Network Time Servers in order to resync their internal time clocks to these established time servers. There are several notable time servers on the Internet that the controller can access, or the controller can simply tickle the site's own time server if one is available. On my side I typically use a small battery in my controllers for time keeping needs, but also resync to a network time server either onsite or an Internet time server if IT Secruity will allow. This way I am covered no matter the site.

Cheers,

Sam

[Ctl-fool]

Had a couple of "learn the hard way" episodes of the coldstart thing with Siemens PXC controllers - set up a database and program only to have it wiped clean when I changed the IP address or device name.

The whole coldstart thing was one of my biggest pet peeves against Siemens...at least until I started on a DesigoCC 2.0 installation. Apogee Insight was way better than Desigo in my opinion.

Have worked on or installed several flavors of control systems, but Siemens seemed to be the most archaic of the bunch.

[numbawunfela]

The whole coldstart thing was one of my biggest pet peeves against Siemens...at least until I started on a DesigoCC 2.0 installation.

Its all about context eh?