LFEP ASCOM error handling

[gpaolo]

Hi all,
I've been using the LFEP for some time now and tonight I've encountered the first real issue with the ASCOM.
This is what happened: the system was taking picture autonomously, it performed the pier flip correctly and it finished the task at 6.43 AM.
Then it was supposed to park, waiting for the dawn to take flats, but it encountered a communication error with the controller: Wrong DEC answer detected: ###NoEMU. Then another error again on DEC, and finally it aborted the pier flip. I don't know what happened to the telescope, but the controller thought anyway that it was parked.
At 7.29 it tried to unpark the mount to reach the position for the flat, but when it performed the goto it thought that a pierflip was necessary (not true: if it was in the parking position, the pier flip would not be necessary), it detected an error on RA position, and it tried to slew anyway. After a few minutes I was running for the telescope, which was hitting the mount on the east side, pointing the ground and doing very nasty things...
Here is the log: (by the way, it would be very nice if it were possible to copy and paste the text in the log windows, I wasn't able to do it...)




I don't know where these errors came from, if it was some problem with the controller, with the USB/Serial converter or the PC, but in my opinion a fault condition should be handled in a safer way than "I will try it anyway...".
I understand that these errors in the log refer to a wrong transmission received from the LFEP.
In this case, I would expect at least a couple of retry, to see if the driver is able to restore correct communication with the controller and retrieve the informations. If it were not possible, the driver should enter in a sort of Safe Mode, aborting any further slew to avoid problem like to one I just had, until the user performs a manual sync or it is able to restore the link.
What is your opinion?
Today I was luck, because I was having breakfast watching the PC and I noticed that the slew was taking way too long and I jumped to catch the telescope right when the clutch on DEC was failing, but if something like that had happened during the night, I don't want to know what could have happened to the telescope...

Thanks for your support!

[gpaolo]

If you forgive my C-style programming  , what do you think of this function to retry to establish the correct communication?

Code: [Select]

                string resultx = CommandString("#:GD#", false, 7, 2);
                if (resultx.Length != 9 && resultx.Length != 6)
                {
                    tool.Log("Wrong Dec answer detected: " + resultx);
                    int i = 1;
                    int TransmissionOK = 0;
                    while ((i < 5) && (TransmissionOK == 0))
                    {
                        tool.Log("Dec retry: " + i);
                        string resultx = CommandString("#:GD#", false, 7, 2);
                        if (resultx.Length != 9 && resultx.Length != 6)
                        {
                            i = i + 1;
                        }
                        else
                        {
                            TransmissionOK = 1;
                        }
                    }
                    if (!TransmissionOK)
                    {
                        tool.Log("Wrong Dec answer detected: " + resultx);
                        try
                        {
                            return _Declination;
                        }
                        catch
                        {
                            return 0;
                        }
                    }

                }
Inside the

Code: [Select]

if (!TransmissionOK)
                    {
                     ...
                     }
I propose to add a flag, like "SlewNotAllowed", to be set TRUE. When a slew is requested, the flag is checked and eventually the action is aborted. The flag must be set to FALSE at unpark and at sync, for example. I have to study the code A LOT before trying to implement that...
Armando, could you check this proposal and tell me what is your opinion?

[Armando]

Hi gpaolo,

If you forgive my C-style programming  , what do you think of this function to retry to establish the correct communication?

I agree with you about the need to make the driver fail-safe and more robust.
I was never able to reproduce these communication issues and this is the reason why I'm tempted to think they are related to the FW in use (or maybe to the state of charge of the battery).
Anyway, giving a look at the logged wrong answer, you can see that starting from the issue the following responses are "mixed" and no more properly managed. So I think there is the need to discard all the available bytes before going to resend the command...

I propose to add a flag, like "SlewNotAllowed", to be set TRUE. When a slew is requested, the flag is checked and eventually the action is aborted. The flag must be set to FALSE at unpark and at sync, for example. I have to study the code A LOT before trying to implement that...
Armando, could you check this proposal and tell me what is your opinion?

I think a new flag could be used to prohibit slewing: it should be properly set in case of communication issues...

CS
Armando

P.s. I remember another user reported the internal serial converter not working; I suggested him to give a look at the cable and then (by the right soldering) the issue was solved...

[Armando]

I also want to point out that Rajiva didn't include LFEP_Communicator project sources in the LFEP ASCOM driver solution.
It could be useful to know if it's always the same command causing the communication issue.

CS
Armando

[Armando]

Hi gpaolo,

maybe DiscardInBuffer call is to be used after ReadExisting one, in case of timeout.
I'm not able to reproduce the issue but, if it still occurs with your LFEP, I can build a new driver and you can check...

Let me know.

CS
Armando

[gpaolo]

Hi Armando,
sorry if I'm not replying, but I'm traveling for work... I will give a look at it as soon as possible.
By the way, I tried to compile the project (I did get an error about the Communicator module, I though it was my fault... well, in my opinion Rajiva has gone a bit too far with this secrecy thing, I don't see the harm in releasing the full code of ASCOM driver...) but I got some error... Do you know it there is something more to do beside copying everything in one directory, opening the project and tell Visual Studio to compile?

[Armando]

Hi gpaolo,

Hi Armando,
sorry if I'm not replying, but I'm traveling for work... I will give a look at it as soon as possible.

Ok 

Do you know it there is something more to do beside copying everything in one directory, opening the project and tell Visual Studio to compile?

You need the ASCOM development package. You can also ignore the warnings. Nothing else is required.

CS
Armando

[gpaolo]

Hi Armando,

You need the ASCOM development package. You can also ignore the warnings. Nothing else is required.

Is it this one?
http://ascom-standards.org/Downloads/PlatDevComponents.htm

Bye!

[Armando]

Is it this one?

Yes, it is.

CS
Armando