| Posted: Wednesday Mar 23rd, 2016 12:10 am |
|
1st Post |
lms
Member
back to top
|
I have an output which I need to set to ON as soon as possible after restarting Comfort but this doesn't appear to function if placed too soon in the Startup Response. If I put in a Wait for 10 seconds before the Output command, then it does what it's supposed to. Without much experimenting I can't really be sure that a 10-second delay will always be sufficient, or whether a shorter delay would also be OK. The output I'm setting is on a SEM - I'm also not sure if a RIO output would behave differently.
A further issue is that I normally get the "Security Off" announcement cut off after "Security" - probably something in my Startup Response that's causing this, although I have no further announcements for some time . And related to this, even if I disable broadcasts to specific keypads early in Startup, I sill get the "Security" message on the disabled keypads - subsequent messages are prevented.
I'm assuming that some system functions, like polling for or initialising hardware, may be preventing the output action (or other commands) from being executed as the output may not yet have been detected by the system. I could play around with other delays, etc., but was wondering if there are any guidelines as to how soon within the Startup Response one can reliably make use of outputs/inputs/flags/counters/sensors as well as X10/IR/keypad functions and other IF conditions like NightTime.
Current setup is firmware 7.077 with Comfigurator 3.10.11.0, three SEM, 4 LEMs, 6 RIOs.
|
| Posted: Wednesday Mar 23rd, 2016 12:54 am |
|
2nd Post |
Swiss-Toni
UCM Pi Users
back to top
|
Its not really clear what you what you want the output to do, if it is a Cytech relay that you are using and want it to be on straight away after a reset (or whatever it is that you want it to do), change the cabling position to NC or NO on the relay for the function! I am only guessing that this is the issue as you have not made it clear what the output is controlling.
|
| Posted: Wednesday Mar 23rd, 2016 07:20 am |
|
3rd Post |
lms
Member
back to top
|
Thanks for your response Swiss-Toni.
Yes, I could certainly do something like your suggestion (and have done so) in some cases. But the specific application is not really my focus here - the main point is in trying to understand what goes on immediately after and during a restart.
|
| Posted: Wednesday Mar 23rd, 2016 08:04 am |
|
4th Post |
slychiu
Administrator
| Joined: | Saturday Apr 29th, 2006 |
| Location: | Singapore |
| Posts: | 5807 |
| Status: |
Offline
|
back to top
|
At reset, all the outputs are switched off on the Comfort and Slaves
It takes a few seconds for a slave to be polled and commands to be sent to them. There is no fixed time as it depends on how many modules there are on the system, UCMs, Slaves, RIOs, Keypads. At reset, slaves and keypads establish communications and exchange data eg the zones handled by each
However 10 seconds delay is more than enough. Anything that happens in other modules need some delay. Anything in the main controller should not need the delay
Your "security off " may be cut off because something perhaps in a response is switching off the keypad speakers
|
| Posted: Wednesday Mar 23rd, 2016 08:53 am |
|
5th Post |
lms
Member
back to top
|
Thanks slychiu. This is as I expected.
I have experimented with disabling all keypad functions in my responses, but still get the partial "security" message - must be something I've missed - but this isn't really important - may have another go at this some time.
It seems like there's nothing I can do about disabling the "security off" on some keypads as this happens very early after the reset and the command to disable broadcast to specific keypads may be occurring before the specific keypads are polled, or something like that. In addition to your confirmation that polling is dependent on the number of modules, I also assume that polling could take longer if there is perhaps a communication problem with another module or other bus activity, making it impossible to predict a reasonably exact delay?
I was thinking that the system should perhaps delay starting of the Startup Response until all "system" activity (establishing comms, etc.) is complete, but I guess this would cause more problems than it solves!
|
|
