Hi Amber

Stopping an element is indeed faster than starting an element. Internally, it simply needs to stop the polling and unregister from certain protocols.

Starting an element requires more actions, settings and templates need to be read out, parameters need to be initialized, same for timers, actions, QActions, triggers,…
But often, the delay will be in retrieving the data from the database.

• Quick example, looking at my Microsoft Platform element, it takes ~25s to read out everything it needs from the database.
• Elements with a lot of active alarms and/or elementdata usually take longer to start up, simply due to the data retrieval

You can check this for your use case as well by looking at the element log:

• Cube -> System Center -> Logging -> elements -> <your element>
• On the server -> C:/Skyline Dataminer/Logging -> <your element>.txt

When you see “Start|DBG|-1|Complete.“, then the element should have started up. So in your case, you should look for delays prior to this line.
As mentioned, my guess would be the reading of the database => search for “ReadDB|DBG|-1|** Read DB“.

Is this expected behaviour?

Yes, it’s normal that an element can take up 20 – 60 seconds, it depends on the content of the element.

Is there anyway to make the start-up time quicker?

To make the startup time faster, you would need to avoid alarm templates and not save any parameters (defined in the protocol itself). However, this is often essential for a proper operation.