Currently imaging using 3.4.0. EQ Mod mount, ZWO Guidescope, Canon 5D Mk ii and Moonlite focuser. Moonlite focuser serial timeout error still there, but I can manually focus. Plate solver (offline) works perfectly. Good guiding and Canon imaging away.

I'm sorry and a little ashamed,
but the translation was not good e
I'm confused.
I wanted to point out that I'm using a Vixen SXP mount,
an 80/352 refractor and a modified Canon Eos 60D.

Incidentally I ran 3.4 two nights in a row on my laptop. Schedule, sequence, alignment, focus, guiding, and PHD2 all check out. No crashes or strange errors.

Lead_weight and cxxone,

That sounds good! If there are any issues, please let me know. I think Jasem wants to make this release a good stable release, so any bugs or kinks should be worked out.

Lead_weight,

Later this week, maybe I will experiment with Python in a virtual OS X machine to see if I can replicate the situation your desktop is having and see if I can work around it. That might be the best option instead of trying to figure it out remotely. Im glad the laptop is working fine.

carkinzo,

If it wasn't clear, maybe a screenshot would help. I will also try to explain again more clearly.

Do not do plate solve with "Slew to Target", do plate solve with "Sync"


When you first set up your telescope, do several plate solves in different parts of the sky. Don't worry if the target does not show up in the image when you do a plate solve. It does not matter. The mount is still getting told where the telescope is pointing, even if the target isn't in the picture. Each plate solve improves the accuracy of the "mount model," assuming that your mount can build a model (some can and some cannot). If your mount cannot build a pointing model, it will still be good to use at least 3 alignment points by doing plate solves in different parts of the sky. Then after you do a few plate solves, the accuracy should improve. Finally do a plate solve near where you actually plan to be imaging.

In my opinion it is not a good idea to do "Slew to Target" because then you get several alignment points that are very close together. You really want your alignment points to be far apart to produce a better model of the sky.

I agree with you in headlines. But I myself usually do not image more than 1 or 2 objects in one night and in that case "Slew To Target" works really well. My SkyWatcher HEQ5 with EQMod always puts the object that I want to image within 30 arcsec of the center of FOV within 5 or 6 tries. All I mean to say is: I think it depends both on your mount and on your purpose which option to choose.


Wouter

Sounds, good. PM me if you think a quick screen share session to poke around would be helpful, and we can set up a time.

Yes, this is certainly true, and that is why the option exists to do "slew to target." However, he said he was having problems due to the mount not slewing to objects properly after plate solves. There are several things that can cause this that I can think of (pointing model messed up by points too close together, mounts not very accurate with short slews, etc), and most of them would be solved by following the advice that I gave. I find that my own mount struggles when doing plate solves with "slew to target," but. that it works much better if I do several plate solves that are widely spaced apart to build a pointing model before I go to my object. And once I do, that, my slews are pretty much spot on. So yes, certainly it depends on your situation, but I think in this situation, it might help to try my alternate approach.

Yes you are absolutely right. I didn’t mean to contradict you Rob because you give very good advice. Let’s see if carkinzo can solve his slewing option by using the sync option and by building a pointing model first.

The thing that seemed strange to me is that the first correction
does it, but then no longer corrects!
Okay, I'll have to test, but the sky is here again
cloudy, so I don't know when I can do it.
I wanted to ask one thing:
I had heard that to work better you should do it
a 1 or 2 star alignment with the mount computer.
Is it right to do this, or is it useless?
I ask because my Vixen Sxp already with a 3 alignment
stars is accurate, so I asked for this reason.
But if this were right, I would have to sync the map
the StarBook Ten with Kstars and I don't know if it can be done.

Lead_weight,

I did some experiments last night with the issue you reported in a virtual machine with python3 installed in different ways to see why python3 sometimes is not working properly with astrometry.net to plate solve. Another user, who also installed non-homebrew python3 has reported a similar issue in this bug report:

bugs.kde.org/show_bug.cgi?id=405437

, and we were trying to diagnose it there too. In both cases, we did a number of experiments but couldn't find the problem. I decided to try a different approach. It was much easier for me to diagnose the issue in a virtual machine. I will post what I found last night in both places.



The problem:
The issue happens when the user has installed non-homebrew python. Python3 is installed properly, the site packages include astropy and numpy, it can find the site packages, the correct python3 is first in the PATH variable, KStars is installed correctly, and NOTE this is not the "illegal argument exception" caused by running software compiled for a newer computer on an older computer. But when the plate solve is run, it gives an error message which means it can't find astropy. When run from the command line, it gives the same error!

My finding:
It seems to me that the issue is that the calls to python astrometry.net are making use the name python not python3 when the calls are made. OS X has a python2.7 installed by default that is used by the system and should not be changed. Python3 is installed in various ways and could be in different locations. All the different python versions that I tested last night put a simlink in /usr/local/bin for python3 to redirect calls for python3 to wherever python3 is installed. There is not a simlink to python put in that location because the assumption is that if you call python, you want python2.7 to run the code and if you call python3, you want your self installed python to run it. I ran into this issue before with the homebrew python, and it gave me big headaches before, but later I found that there was a folder homebrew made called /usr/local/opt/python/libexec/bin where there actually was a simlink placed from python to the homebrew python3 and if I put that in the path, it automatically fixed the problem! I had assumed that the other versions of python would have a similar folder and you could just put them in the PATH variable and it would work. I was surprised last night when I didn't find a python simlink in /Library/Frameworks/Python.framework/Versions/3.7/bin (or similar folder for other installation), nor did I find anything in /Library/Frameworks/Python.framework/Versions/3.7/opt. So thus even with that folder in the PATH, it still called the system python whenever python was called for.

Now that I think I know what the problem is, I should be able to come up with a way to fix it for non homebrew pythons. Just to verify, can you check for symlinks to python (not python3) in your /usr/local/bin folder, your /usr/local/opt/python/libexec/bin folder, and in whichever python3 bin and opt folder you would currently like to use (for example: /Library/Frameworks/Python.framework/Versions/3.7/bin and /Library/Frameworks/Python.framework/Versions/3.7/opt). If none of those folders contain a file or simlink called python, I think we have found the python3 issue.

The real challenge here is that there are many ways python could be installed on OS X and in fact there often is more than one python installation on a user's computer. Since astrometry.net relies heavily on python, it needs to be able to find it, and whichever python runs needs to have the right packages installed in it. The crazy part of that is that we are volunteering our time to work on KStars, but in order to get it to work properly we have to get all these other programs working and talking to one another properly no matter what the user's computer configuration might be. That is a bit of a challenge, so sorry about the delay on this, but I hope you can understand.