ASCOM Focuser control seems to have issues

[StarGrazer]

I am using BYE with the following ASCOM driver and am finding that, when I connect to my Meade micro-focuser from BYE via the ASCOM driver, the right chevron arrows on the BYE GUI seem to work fine but the left chevron arrows do not produce expected results. Whenever any focuser left arrow is clicked on the GUI, the micro-focuser runs for about 5 seconds in one direction, then reverses direction and runs for the same amount of time in the opposite direction and then stops negating any movement (seems like it runs a diagnostic instead of executing the user command?). In any case, a total lack of control.

ASCOM Driver: "Meade LX200 Classic and Autostar #494, #495, and #497 (combined telescope/focuser, 5.0.4"

Could this be a problem with the BYE implementation for any ASCOM focuser or maybe it's specific only to this particular Meade driver? Or if BYE is not the root cause, how would I go about pursuing a solution with the ASCOM layer?

Thanks

[StarGrazer]

Thanks Guylain! Once again you hit the nail on the head!

To this point I had been using default Focuser settings. That means the Focuser Backlash Compensation value in the Focuser properties was set to its default value of 3000 steps. Once I set it to 0, voila... the issue was gone and the Focuser now works as intended/expected!!

PROBLEM SOLVED! (chalk it up to yet another step on my ongoing learning curve :-)

Side note: The more I learn about BYE, the more I am appreciating it as the technical masterpiece you already know it to be! Well done! :-)

[astroman133]

My testing show that BYE's implementation of focuser control is sound. That is, with BYE 3.1.17 RC2 it works as expected with my MoonliteDRO focuser. All of the chevrons move the correct amount in the expected direction, with no unexpected movement. This is true with temperature compensation on or off.

The Meade driver that you are using is quite old. If a ReadMe file was installed with the driver, it may describe how to get support. If there is no other guidance for how to get support, I would post your issue to the ASCOM-Talk Yahoo group.

It may also be of help if you could try controlling your focuser from another application to see if you get the same behavior.

[admin]

BYE simply passes the command to ASCOM and ASCOM controls the focuser per say.

Two things worth nothing.

1) Is your focuser an absolute or relative focuser.  Absolute focuser are best as most moves are repeatable; this is not the case for relative focuser.  Which one is yours?  BYE is optimized to work with Absolute focusers.

2)   Is it possible that your focuser has some sort of back lash compensation?  I say this because it seems to work fine in one direction but not the other.

Regards,

[s3igell]

You can Turn ON the ASCOM Logging, and then review that debug log to see what commands the ASCOM Focuser is handling (and what it is telling the Focuser Driver to do)...

[StarGrazer]

Thanks to all for the replies. I speculate that your (Rick) statement that BYE works as expected with your MoonliteDRO focuser may not be relevant unless of course it is configured in BYE as an ASCOM focuser.

I say that because it is pure speculation on my part (without seeing the source code and I'm sure Guylain could easily blow me out of the water here if I'm off the mark) that the only thing your use case and mine have in common, is likely the "Chevron Click Event" procedures servicing the GUI. I envision that the associated event procedure(s) will contain decision logic that is based upon the active focuser (as configured in the BYE settings), and to have different paths (such as a switch statement or similar) in order to translate those user actions into actual interface compliant commands relevant to the configured focuser device (and of course assuming there is not another API layer making the event functions common and pushing the differences deeper down in the API "stack" or "layers").

If your MoonliteDRO focuser is in fact an ASCOM focuser and configured as such in the BYE settings, then yes I would say your use case is then highly similar to mine since I speculate there would be a higher amount of common code execution for our two use cases in BYE, differing then at the ASCOM driver layer.

I am using the Meade Micro-focuser which I believe to be a relative focuser since Meade requires it to be calibrated at the halfway point using the local hand controller prior to turning things over to remote control (just as they require mount alignment prior to that as well).

To my knowledge, there is no focuser backlash compensation function, but I will double-check that.

I do not have any software available to me at this time that can operate the Meade Micro-focuser remotely AND through the ASCOM driver. i only have the Meade AutoStar Suite and the "Handbox Simulator" functionality in that software operates the focuser flawlessly over direct RS232 serial control. Therefore, I cannot rule out the ASCOM driver as the culprit.

I will also try turning on the ASCOM log assuming I can figure out how to do that (since I do not at the time of this post).

Ok, apologies if anyone feels on the defensive here. It is always difficult to differentiate the "Blame Game" (with the associated and non-productive finger pointing) from a well orchestrated (and way more productive) root cause analysis "deep dive". THANKS FOR THE ASSISTANCE! :-)

I will let you know how I make out.

[astroman133]

I believe that you are confused.

There is no "blame game" going on here. Early stages of troubleshooting an issue are geared toward finding which element is misbehaving. My goal was to help you narrow down, if I could, which parts are likely not the cause of your issue. I have helped out on this forum enough to know that if there is a problem in BYE that Guylain wants to find and fix the root cause in order to make his product better.

I am a user. like yourself, who has been using BYE for several years. I am not affiliated with Guylain or his company in any way, except as you see on this forum. I am also a retired software developer who has written several ASCOM-enabled applications and drivers. I choose to help users who have questions or issues about BYE, as well as ASCOM (on the ASCOM-Talk Yahoo group). Your issue could be due to any of several causes including a bug in BYE to a driver issue to a hardware problem to pilot error. I am just trying to help you solve this issue. Also, if there is an improvement or fix to be made to BYE I can provide feedback to Guylain that he can use to improve his product. I do not typically use the BYE focuser functionality because I have a mount and focuser control app that I have written. So I wanted to test BYE with a spare focuser to see if BYE's focuser control works as I remembered. It does. I reported what testing I had done. What you choose to do with my report and suggestions is up to you.

The whole purpose of ASCOM is to be able to allow applications like BYE to treat all focusers the same. And yes, I selected my MoonliteDRO focuser driver from the selection dropdown list in the ASCOM Chooser dialog that was displayed when I clicked on the Focuser gear button in BYE.

Once BYE is connected to my focuser through ASCOM, each chevron click sends an appropriate position change command to the focuser. ASCOM ensures that the same command is sent to each focuser driver. It is the driver's job to translate that command to the appropriate message for that focuser.

There are one or two types of tracing that you can enable to help sort out what is happening. In BYE, select the focuser and click on the gear button. This launches the ASCOM Focuser Chooser dialog. Click on the word Trace in the upper left to display a menu of tracing options. Select Driver Access Trace and ASCOM will log all the communication that ASCOM has with your focuser driver. This includes Property get and set calls, as well as Commands sent and replies received from the driver for BYE. Don't forget to turn this off when you are done collecting information.

Depending on the driver there may be another level of tracing available. This would be turned on or off from the driver's properties dialog. This dialog is displayed when you select your focuser from the Chooser dropdown and click on the Properties button. Driver tracing is an optional feature that driver authors can choose to implement. Many drivers provide this additional level of diagnostics for troubleshooting issues.

You could try running the ASCOM Diagnostics tool (it was installed as part of the ASCOM Platform). It does some driver testing. There is also an ASCOM tool, called Conform, that is downloadable from the Developer's section of the ASCOM web site. Conform will test a driver to verify that it conforms to the ASCOM standard for focuser drivers. If the Meade driver passes Conform's scrutiny then it is pretty much guaranteed that the driver is good,, and is likely not the cause of the issue that you are reporting.

I hope this is helpful.

[StarGrazer]

Accusations are almost always counter-productive, and for you (Rick) to say that I'm confused is an understatement, but I'm just not confused in the least about what you suggest I'm confused about, I'm confused here because I'm forced to use OPS (Other People's Software) that, in some cases such as the ASCOM drivers, is far from properly documented to a point of facilitating any kind of root cause analysis. If you reread my post, I'm sure you will find that I never said there was a blame game going on here as your comments suggest, I only just put a qualifying statement out there in order to clarify where I'm coming from here, in case someone like yourself were to misinterpret my intent.

Since you set the precedent by sharing your resume' to some degree here in order to establish your credibility, maybe you should know that I am a retired System Design Engineer of 40 years experience in the field of Automated Control System and PES component design (PES; Programmable Electronic Systems used in safety critical applications requiring interactions with various certification agencies) who is well versed in the associated formal methodologies.

[admin]

BYE does not have IF or SWITCH statements that controls the brand of the focuser and BYE does not communicate with any focuser directly... it communicates with ASCOM and ASCOM communicate with the focuser.

Okay, now I understand that your focuser is relative... and from past experience no relative focusers have any sort of backlash compensation because they are relative, e.i no absolute position.

Relative focusers usually have DC motors, not stepper motors, and typically once a move command has been sent to the focuser that command must run to completion before any new commands can be sent.  Even worst, some relative focuser ASCOM driver will actually accept the command and put it a queue and run it once the previous command is completed while some will simply drop that second command since the focuser hasn't completed the previous one.  Bottom line is they do not have consistent implementation unlike their absolute counter part where almost everything is repeatable.  It is for this reason that I said that BYE was optimized to absolute focusers and not relative focusers.

Hope this makes sense.

[astroman133]

I said that I thought that you were confused because you indicated that you thought that my test of BYE with my focuser was not relevant to your issue because you thought that BYE was interacting with my focuser in some fundamentally different way that it does with your focuser. While I do not have access to the BYE source code and have never seen it, I would venture that this is likely not the case. Still there could be some difference between how BYE manages a relative focuser from an absolute focuser.

Running the ASCOM Diagnostics and Conform tools can help Guylain to see that there may indeed be an issue with BYE. Another thing that you could try is to select the focuser simulator rather than your Meade focuser in BYE. This focuser can mimic both a relative and an absolute focuser. If you get the same behavior with the simulator then it could point to the root of the problem being with BYE.

 

[admin]

3 hours ago, StarGrazer said:

Thanks Guylain! Once again you hit the nail on the head!

To this point I had been using default Focuser settings. That means the Focuser Backlash Compensation value in the Focuser properties was set to its default value of 3000 steps. Once I set it to 0, voila... the issue was gone and the Focuser now works as intended/expected!!

PROBLEM SOLVED! (chalk it up to yet another step on my ongoing learning curve ?

Side note: The more I learn about BYE, the more I am appreciating it as the technical masterpiece you already know it to be! Well done! ?

Glad you got it to work