Dome error status

[Stephane Basa]

Dear Bob,

I have new questions about ACP logic.

In my startup script, I open the dome automatically. Sometimes I have an error message (just an example):

17:20:34 Send command: OPEN DOME SHUTTER.
17:20:34 ** #domeopen - Unexpected shutter status 4

The last number, 4, is just the property of Dome.ShutterStatus.

The ACP button managing the dome is also in error.

With the manufacturer of the dome, Astelco, we tried to understand, but without success: looking at the ASCOM log, we realized that ACP did not seem to read the status of the dome at that time. It's quite disturbing and could you say how you handle that?

Thank you very much,
Stéphane

[Bob Denny]

I need more information. Please post the Startup Script. Is this a script based on the sample startup script supplied with ACP Scheduler? If so, then there are no dome opening commands in that script, so this is confusing. Is this message coming from ACP Scheduler itself as part of its operation? Nowhere in Scheduler is there a "Send Command: OPEN DOME SHUTTER." I assume this is part of the code in your script?

But the value 4 is a shutter status of ShutterError. I don't recognize the form of the error

** #domeopen - Unexpected shutter status 4

Is this from the startup script code monitoring the dome ShutterStatus property?

The ACP button managing the dome is also in error.

I'm certain this is a language barrier and I apologize. I don't understand how a button can be "in error". Is it "dimmed" or unavailable?

With the manufacturer of the dome, Astelco, we tried to understand, but without success: looking at the ASCOM log, we realized that ACP did not seem to read the status of the dome at that time. It's quite disturbing and could you say how you handle that?

Again I cannot picture what is happening or not happening. Can you provide me with the ASTELCO ASCOM log as well? Perhaps I can understand it enough to know.

Overall I do not understand the sequence of events, the components involved, etc. I apologize.

[Stephane Basa]

Bob,

I clearly posed the problem incorrectly and there are other elements:

• The ACP log.
• The ASCOM trace log.
• The Startup script I am using (I could not attach it, so I copied it) in this message.

Here are the symptoms:

• I do an Error reset on the dome controller: it is required after a weather alert. The dome is directly connected to the weather stations for more security and I have to reset it. This reset is successful (visible on the ASCOM log).
• Despite that, I have an error 4 that appears (from Dome.ShutterStatus). This error seems to be reported by the ACP dome control button: it also indicates an error (I can access the button without any problem).
• Still looking at the ASCOM logs and accessing the dome controller, we can see that the dome is in fact operational.

With Michael from Astelco we ask ourselves many questions (we worked on it last night!):

• If you look at the ASCOM log, this information is not requested to the controller by ACP. Is-it possible to understand how you managed the situation?
• Is there known issues with ASCOM with the domes (I am using V6.2)?

Thanks for you help.

[edit: Script moved into attached file StartupObsUnformatted.js.txt (.txt to allow attaching)]

[Bob Denny]

Hi -- I moved the script into a file and attached it. In the future could you also attach scripts. Pasting without [code] tags destroys the indentation. And even with [code] it is hard to read with a huge script in the middle of the "heart" of the message :-)

• Is there known issues with ASCOM with the domes (I am using V6.2)?

6.2? Do you mean ACP 6.2? There is no ACP 6.2. There is a 6.0 from 2011 and a 7.2 from 2014... I reviewed all changes related to "Dome" since 2011 and cannot find any changes of basic functionality ir bug fixes. There was a safety fix in 2011 relating so rotating with the shutter closed and geometry for non-flipping German mount. No known "big problems" and many people are running with various domes.

I believe the part that is having problems is this (which I reformatted since it was squashed by unformatted paste):

// ================================================== ================
// THEN WE CAN OPEN DOME SHUTTER
// ================================================== ================ 
try {
    Console.PrintLine("Send command: OPEN DOME SHUTTER.");
    MyOpenShutter(); 
} catch(ex) {
    Console.PrintLine("**Failed to open the Dome Shutter");
    throw new Error(0x80040001, "==== Cannot continue");
}

Which calls this ( I did my best to restore the indentation so that I can understand it):

// - - - - - - - - - - - - - - - - - - - - - - - - - - - -
// To open the dome shutter
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
function MyOpenShutter()
{
    if(Dome.Available && Dome.CanSetShutter)
    {
        if(Dome.ShutterStatus == 1)                     // 1 = shutterClosed
        {
            Console.PrintLine(" Opening dome shutter");
            Dome.OpenShutter();
            Util.WaitForMilliseconds(15000);
            for(var i = 0; i < 6; i++)                  // Wait for up to 1 minute
            {
                if(Dome.ShutterStatus == 0)
                {
                    Console.PrintLine(" Shutter now open.");
                    break;
                }
                else if(Dome.ShutterStatus == 4)
                    Console.PrintLine(" ?? Shutter error being reported, still waiting for open ??");
                Util.WaitForMilliseconds(10000);        // Check every 10 seconds
            }
            if(i >= 6) 
            {
                Console.PrintLine("** #domeopen - Shutter failed to open after 1 minute");
                return false;
            }
        }
        else if(Dome.ShutterStatus == 0) { // 0 = shutterOpen
            Console.PrintLine(" Shutter already open.");
        } else {                                        // Some other (bad) status
            Console.PrintLine("** #domeopen - Unexpected shutter status " + Dome.ShutterStatus);
            return false;
        }
    }
}

The way the dome is supposed to work per the ASCOM specification is

1. Program (your script through ACP) calls Dome.OpenShutter(). If it returns without throwing an error, then ACP assumes that it has succeeded in starting the shutter opening.
2. Dome must immediately show ShutterStatus = ShutterOpening, and continue to report ShutterOpening until the shutter is open or fails.
3. When the shutter has completely opened, ShutterStatus must be ShutterOpen.

In other words, the dome controller must do the right thing and tell the truth or throw an error.

Looking at your logic, it appears that you are trying to program around behavior that is not conforming to the ASCOM specification.

You are expecting a shutter error to appear during a normal opening process? If ACP sees a Shutter error it will immediately stop with a thrown error. This may disable the dome button as well, as ACP is protecting the "failed" dome controller from additional problems. A ShutterError should never be indicated unless something serious has happened.

OK, with that issue identified, I am looking at the StartupObs log and the ASTELCO trace. In the logI see

17:20:34 Send command: OPEN DOME SHUTTER.
17:20:34 ** #domeopen - Unexpected shutter status 4

and in the trace file, at the same time I see

2017-12-15 17:20:34.410 I => execution(Telescope.CommandString(..))                    arguments('CABINET.STATUS.LIST', 'false')     (classes.ck a:77)

2017-12-15 17:20:34.410 I <= execution(Telescope.CommandString(..))                    arguments('CABINET.STATUS.LIST', 'false') return(class java.lang.String:)     (classes.ck a:77)

This has nothing to do with the Dome, in fact I see almost no Dome traffic at all in the ASCOM log.

2017-12-15 17:20:07.454 I => execution(Dome.setConnected(..))                          arguments('true')     (classes.ck a:77)
2017-12-15 17:20:07.454 I <= execution(Dome.setConnected(..))                          arguments('true') return()     (classes.ck a:77)
2017-12-15 17:20:07.454 I => execution(Dome.canFindHome())                                 (classes.ck a:77)
2017-12-15 17:20:07.454 I <= execution(Dome.canFindHome())                             return(class java.lang.Boolean:true)     (classes.ck a:77)
2017-12-15 17:20:07.454 I => execution(Dome.canPark())                                     (classes.ck a:77)
2017-12-15 17:20:07.454 I <= execution(Dome.canPark())                                 return(class java.lang.Boolean:true)     (classes.ck a:77)
2017-12-15 17:20:07.454 I => execution(Dome.canSetShutter())                               (classes.ck a:77)
2017-12-15 17:20:07.454 I <= execution(Dome.canSetShutter())                           return(class java.lang.Boolean:true)     (classes.ck a:77)
2017-12-15 17:20:07.454 I => execution(Dome.canSetAzimuth())                               (classes.ck a:77)
2017-12-15 17:20:07.454 I <= execution(Dome.canSetAzimuth())                           return(class java.lang.Boolean:true)     (classes.ck a:77)
2017-12-15 17:20:07.454 I => execution(Dome.canSetAzimuth())                               (classes.ck a:77)
2017-12-15 17:20:07.454 I <= execution(Dome.canSetAzimuth())                           return(class java.lang.Boolean:true)     (classes.ck a:77)
2017-12-15 17:20:07.454 I => execution(Dome.canSetAltitude())                              (classes.ck a:77)
2017-12-15 17:20:07.454 I <= execution(Dome.canSetAltitude())                          return(class java.lang.Boolean:false)     (classes.ck a:77)
2017-12-15 17:20:07.454 I => execution(Dome.getName())                                     (classes.ck a:77)
2017-12-15 17:20:07.454 I <= execution(Dome.getName())                                 return(class java.lang.String:NTM)     (classes.ck a:77)
...
2017-12-15 17:25:26.095 I => execution(Dome.Park())                                        (classes.ck a:77)
2017-12-15 17:25:26.095 I <= execution(Dome.Park())                                    return()     (classes.ck a:77)

Yet clearly the StartupObs script is calling Dome members. ACP is not "trapping" these calls, obviously, because your StartubObs log is showing ShutterError 4 and that must have come from the Dome yet there is no evidence of Dome activity in the ASCOM log at that time.

Is the time stamp in the ASTELCO log really UTC or is it perhaps local time? Also I can see nothing in StartupObs.js that is responsible for the logged message "Send command: OPEN DOME SHUTTER.". This is not coming from within ACP. So are ytou certain that the script you posted is actually the one that ran to produce the StartupObs.log? Furthermore I don't see the logged line in StartupObs.log that comes from this

Console.PrintLine(" Opening dome shutter");

It must precede the error

17:20:34 ** #domeopen - Unexpected shutter status 4

So I cannot at the moment piece together what is happening. What I can say is that the Dome object's functions and properties are passing through ACP into the Dome controller via ASCOM. It may be necessary for us to get together on the phone as I thing there is some misunderstanding and incomplete data.

[Stephane Basa]

Bob, I am confused for the script: I tried to attach it to the post, but without success. I thought it was due to the fact that it was a java file and that the forum doesn't accept them for safety reason (in our lab, it is the case). But you reformated it and I should have thought about it...

We had not paid attention, but indeed, it is weird that we do not see the order to order the opening. I will first check this with Michael. Depending on the answer, we will talk by Skype to try to analyze the logic. It can come from us or from somewhere else. The real problem is that this bug is coming from time to time, and that reproducing it is not easy!

This is the last problem I have: everything else works great.

Stéphane

[Stephane Basa]

Bob, here's some news.

With Michael, we looked at the process in more detail and the most likely explanation is this one:

• We start by connecting the telescope. When it's done, we reset the errors with a magic command send to the telescope (dome and telescope share the same controller).
• This means that the telescope may see the error when connected, which may put the system in a strange state.

To solve the issue, I write a small script to reset the error: it is called in the Startup before the telescope connection. Like this, the logic is better respected since the telescope connects in a healthy configuration.

Moreover it was the good opportunity to clean my Startup (I did not have the courage to do it before). It is now much simpler!

If that does not work, we can call ourselves (but I'm very optimistic ).

Stéphane

[Bob Denny]

Stéphane -- I am a little confused with what you and Michael are doing. If the dome and telescope share the same controller, does that mean the dome slaving is being handled by the ASTELCO controller? If so, then this could cause some confusion with the Scheduler (only) which wants to open the dome at times. But to open the dome it has to be connected to ACP. If it is connected to ACP then ACP will want to be the one to do the dome slaving.

Also, unless the dome is reporting the correct states for ShutterStatus (ShutterOpen when the shutter is open, ShutterOpening while the shutter is opening, ShutterClosing while the shutter is closing, ShutterClosed when the shutter is closed) then ACP will not act correctly and may raise an error unexpectedly.

I still think we could all benefit from a telephone conference.

[Stephane Basa]

Bob,

The situation is as follows: the same controller manages the mount and the dome. The weather station can directly trigger the controller, which allows to have a safety independent of a computer (we just added a small delay to avoid conflicts). Once this security has been activated, it is essential to reset it. This safety is managed by the controller as an error in order to force a decision: after a weather alert, we must decide if the system is reactivated or not.

We had the feeling that ACP sees the error maybe much earlier, before we clear the error OR that it is realted to the not-starting of the telescope tracking (a start tracking request can be seen, but the telescope does not start tracking in this case, maybe because of the pending shutter error). By removing the alerts before trying to connect to the telescope, it will be cleaner.

In any case, it's always a pleasure to talk with you. Wednesday or Thursday would be ideal.

Stéphane

[Bob Denny]

All right, Thursday. What time? And I have +49 xxx x935 for the number. Is this right?

[Stephane Basa]

Bob, for Thursday, I would say that it depends of you. For me it will the afternoon.

For the contact, +49 is not France (+33), but what about Skype, it allows to have the hand available.