Jump to content

Canada's top-tier Telescopes & Accessories
Be as specific as possible when reporting issues and *ALWAYS* include the full version number of the application you are using and your exact *CAMERA MODEL*
NEVER POST YOUR KEY IN ANY PUBLIC FORUM, INCLUDING THE O'TELESCOPE SUPPORT FORUM ::: IF YOU DO YOUR KEY WILL BE DEACTIVATED WITHOUT NOTICE!
  • 0

Permissions to ascom logs folder issue


Guest brownrb

Question

Guest brownrb

I have just downloaded the latest trial version 3.1 as users of my products (ascom focusers) are having issues with backyard eos.

I am running windows 10 64bit, my account has admin priviledges.

First time, when trying to run BackyardEOS, it comes with error messages about not being able to access D:\Pictures\BackyardTemp and exits

So I created that folder. Then it has same issue with permission for Pictures\BackyardTemp\Logs and exists. So I created that folder.

Then it runs. I access the ASCOM focuser dialog box, enable trace and guess what - Backyard EOS again generates an exception error about not being able to access Documents\ASCOM\xxxx where the trace logs are. Running as admin makes not difference. It will only work if I disable the trace on the ascom dialogbox (by using a different application first). I have tried removing and reinstalling etc as admin, still the same.

It appears the application is not running as my login account and thus has not access permissions to my folders. This is just crazy. Trying to change compatibility settings and as admin has zero effect - in other words the same errors persist.

I can run any other application without issue, Nebulosity, MaximDL, StarryNight, APT, FocusMax can all access the ASCOM focuser without issue and write to the trace log. Only Backyard EOS fails.

Any insights appreciated.

Robert Brown

brown_rb@yahoo.com

Link to comment
Share on other sites

  • Answers 6
  • Created
  • Last Reply

6 answers to this question

Recommended Posts

I have traced this to Bit-Defender and antivirus program. The exe files for Backyard EOS need to be added as trusted applications in order for this to work.

 

HOWEVER

Why is backyard EOS asking for a position update every second? That's nuts. Its not like the focuser position will change when its not moving. This refresh rate should be configurable for the user, its unnecessary and leads to such a high overhead on the focuser. There is absolutely no need for this.

Link to comment
Share on other sites

Hi Robert,

BYE does not run as an other user.  The BackyardTEMP folder was specifically chosen to prevent this.  Glad you found the cause though. 

As for BYE polling the focuser this is how it is designed, a 1 second polling in CPU cycles is an eternity,.  How would you know it if is moving if you do not poll for a position change... or any other ASCOM property for that matter.   These devices (for the most part at least) are not event based so the only way to know if a value has changed is to ask for it and since most devices do have property that changes regularly it needs to polled regularly.  

Take a telescope for instance, the coordinates RA/DEC and/or Alt/AZ are constantly changing and thus most application that interact with a telescope will display the coordinates at least one every second; this is not putting an overhead on the telescope.

Why do you think this is putting an overhead on the focuser, can you elaborate? 

Regards,

Link to comment
Share on other sites

Your statement "its not like the focuser position will change when its not moving" does not take into account that

1) if the driver supports multiple clients that one of the other clients could cause the focuser to move and BYE needs to show an accurate position, or

2) that having temperature compensation enabled in the focuser could cause the focuser to change position in response to an ambient temperature change.
 

Link to comment
Share on other sites

Actually this is caused by a lack of appreciation of how ASCOM actually works. ASCOM is a command response protocol. To know if a focuser has changed position is easy. Call Get Position.

BUT It does not have to that every second. The correct way is to

1. call is moving

2. is not waiting then send move else if moving wait predetermined time then abort

The focuser can even request the position before a move, though it should not have to. It does not have to ask for it every second.

You mention multiple clients that only accounts for such a small implementation of typical uses that it really is too small to measure. And it defies logic that you would make two clients send two different move sequences at the same time. Normally in cases  like this one client would be defined as a master controlling the moves and the other client a slave (simply monitoring the position).

Concerning temperature compensation - BYEOS does not support any mechanism that I can see to enable or disable temperature compensation as per ascom client requirements. A focuser must always start with temperature compensation disabled. Where is the mechanism in BYEOS to enable it? I so if I am mistaken please point me to where this feature is in BYEOS. There is a specific ascom call that a client uses to enable and disable temperature compensation. Without it, there is no way to turn it on. If its turned on when connecting, then every move request will be ignored by the focuser. One then has to resort to convoluted ways to disable it in a 3rd party app which should never be the case. This points to a misunderstanding of how temperature compensation should be implemented in ASCOM applications or client drivers.

In the early days serial comms was not as reliable as it is now. I asked Steve Brady about this polling when troubleshooting issues with FocusMax3.x and that was his reply.

You will note that in version4, the polling rate is now under user control. Even Steve agrees there is no need to poll at such a fast rate. It had more to do with keeping the connection alive than to display an updated position. Thats why its been changed in FM4.x

And if you were to analyze the many thousands of hours of logs available from every BYEOS user with an ASCOM focuser, it would tell the same story. There is no need or justification for polling every second.

Do you really think that if the update poll rate was 10s any user would actually notice?

At the end of the day you are a developer with a product. Its your decision as to how things get implemented. But it might also be good to take notice that other major developers have changed exactly this over the last year to a more flexible user defined approach.

Regards

Robert

 

Link to comment
Share on other sites

Hi Robert,

Thank you for your detail response but in step 1 you say to call IsMoving... there ya go.... you are polling to see if the focuser is moving.  Calling IsMoving or calling another property, say position, turns out to be the same thing.  This is polling plain and simple.

On top of this you assume that IsMoving is implemented by all ASCOM drivers.... I sorry to tell you that is not.  The good ASCOM driver developers will implement IsMoving but sadly not all do.

I guarantee 100% that if polling was every 10 seconds users would notice... as soon as the focuser would be moving it could take up to 10 seconds for the new position to be displayed in the UI... users will notice.  If the move could only be initiated from BYE/BYN then it could be polled only during a move and be done with it... but this is not the case as it can be initiated form the focuser hand pad (Moonlite for example) or by another app as Rick said.

Bottom line polling every second is not an issue at all and it does not put an overhead on the device; as I said earlier, 1 second is an eternity in terms of CPU cycles..  You have not elaborated on this with fact.  Is this causing issues for you? If yes please elaborate.  If this is just an opinion this is fine too.  I'm just curious.

Regards,

Link to comment
Share on other sites

Robert,

BYE/BYN does not provide the ability to enable Temperature Compensation from within its user interface, but as you noted it must disable temp comp in order to adjust the focuser position. So during a focuser move BYE/BYN must disable T/C if it is enabled, change the focuser position, wait until the focuser has reached the requested position, and then re-enable T/C if it was disabled. T/C is typically enabled in the ASCOM focuser properties dialog.

The other thing is that BYE does not know if the focuser driver is a local server that allows multiple connections or not, so it must assume that there are other applications that are also accessing the focuser. It is your responsibility to not ask multiple clients to move the focuser at the same time. There is no inherent master/slave relationship between clients for any ASCOM device.

So, the only way for a focuser client to display the current focuser position is to poll for it. Checking IsMoving is not sufficient because a move could have occurred between polls. The only reliable way is to poll for the position frequently. Fortunately, this is a low overhead operation.

Guylain, according to the ASCOM Focuser interface definition, the IsMoving property must be implemented. However, checking IsMoving only tells the caller whether the focuser is currently moving. It does not say that the focuser has moved since the client last polled it.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...

Important Information

This site uses cookies to offer your a better browsing experience. You can adjust your cookie settings. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies, our Privacy Policy, and our Terms of Use