Date   

Re: Meridian Limit and Unpark Question

Don W
 

Hi Josh,
It is good to hear from you again. In answer to your question about stopping tracking before the meridian, I think the answer is NO.  Why do you want to do this - maybe there is a work-around?

The latest SiTech is 095P at:
http://siderealtechnology.com/SiTechSetup095P.exe

SiTech records a note in the SiTech.cfg file about the park situation.  All that is - is a 0 for not parked and a 1 for parked.  when you start up SiTechexe, it simply reads that cfg file entry, but that really doesn't do anything.  If the mount is in your park position, then go ahead and UNPARK.

Don W


Meridian Limit and Unpark Question

Joshua Hufford
 

Hello everyone, after a hiatus from imaging do to mount motor failure and just general life getting in the way I'm getting my imaging setup back up and running again. My MI-250 is now running with Pittman 9000 series servo motors instead of the stock Losmandy Gemini motors, should be a big improvement. 

First question about the meridian limit, is there a way to prevent the mount from tracking a few degrees before it hits the meridian? I tried entering a negative number in the meridian overlap setting, however it wouldn't accept it. I'd like to have my mount stop tracking three degrees before the meridian if possible. I'm guessing the Meridian Limit east and west boxes are where I would set this, but I'm not exactly sure what I need to input here. 

Also I have my park position set, however when I click UnPark I get a message saying the scope is not officially parked. Any idea why that is?

Lastly I'm running version .94N. Is this the latest version? If not what is? 

Thanks!

Josh


Re: Offset Init & flip during SGP sequencing

paul K
 

Hi Martin, I had some clear tonight so at 10 pm I set up M95 (east of meridian at that time) as a sequence in SGP.

On this occasion in Sitech I set the scope horizontal pointing Az 90 and parked it there. So my process was as follows:

unpark the mount (I used Sitech interface to do this)
In SGP, tick slave dome to scope, then in target settings click 'Centere now'

Findings:

Scope moves quite quickly to target (as usual for me) - no pier flip.
Dome takes a while to catch up and before it does, SGP's centre now routine is taking an image of the inside of my dome.

I repeated this process three times with the same result each time.

So that wasn't particularly useful, it's similar to what you found, but I had no pier flip from Sitech up to that point of failure.

If it's clear again tomorrow night I'll park at Az 270 and centre on a target west of the meridian to see if the same happens on the west side.

I must admit I'll be surprised if it fails to wait on the west side as that's where I image mostly, and I'm sure I'd have spotted the problem before. I will check though.

Also tomorrow I'll post a pic of my mount parms dialog from Sitech.

Best wishes
Paul


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi JonK,
I also agree that imaging under the pole can be of interest and should be straightforward with a bent knee pier.

One thing I've noticed if you set your limits on top of each other is that the RA axis gently oscillates at the end of a slew instead of tracking. Like a PID controller that's not quite tuned.

If you don't mind being weights up then perhaps you could take it out of GEM mode. That will get rid of the limit settings.

Unfortunately for dimensional and spacial reasons I need to be weights down when begin to image; be that in the East or the west. Which means that ultimately Don's suggested settings won't work for me if I choose to begin imaging looking west. I need the mount to function as a GEM.

But I'm going to try Don's settings to check if they illuminate the unwanted slewing during plate solving in the east. Either way it will be an important test.

I shall also try with APT instead of SGP, a different plate solver and a different camera. That should rule in\out any possible equipment compatibility issues.

I shall also test using the ASCOM camera simulator. You can load an image into it and run a real sequence which means I can test during the day.

Hopefully soon I'll have some test results.

Best wishes
Martin




Re: Offset Init & flip during SGP sequencing

Jonk
 

I'd like to agree with MartinC and Paul K.

I also have a bent knee pier, designed mainly to avoid meridian flips and any possibility of crashes, and I asked the question about setting limits before on a separate thread.

What I have done is set all limits to +/- 180 degrees, essentially moving everything to be between the ncp and the N horizon. I know this will probably be frowned upon, but in testing this appears to be all I can do to 'remove limits'.

I would like to see a simple switch in the software, turning limits off, with a simple pop up message 'are you sure, damage may result if incorrectly used' or similar, as is in use on other mount control systems I have seen. This would cater for people who do have the possibility of a pier crash.

I also disagree with the comment above about not imaging under the pole - ok, for people with a pier crash possibility, this is sound advice, but people have to take responsibility for their own actions. For people without this issue, there's no reason not to - ok, it's not abundant with targets for imaging, but take last year for example - Comet Neowise - a perfect example of set in the NW and rise in the NE. My observatory location has a fairly good NW to NE view so I would certainly look to be pointing in that area.

But, it's not always about imaging - I am an occasional observer and with my large refractor, I simply remove the imaging gear and fit a diagonal and eyepiece. If I want to point to the N, which I probably will do frequently as it's the darkest part of sky for me and is probably my best horizon taking into account the low skyline and lack of serious light pollution, then the advice of 'don't image' (or observe) under the pole doesn't work for me. Especially with a bent knee pier. Again, Comet Neowise would be a perfect example.

Regarding the initial error discussed about the plate solve then the mount slewing to a mirror opposite without any input from SGP, I am very interested to see if this is a bug. Unfortunately, my equipment is not set up so I can't run my Mesu e200 / SGP combination to see if it does the same, but look forwards to the resolution.

In conclusion, a 'switch off mount limits' button would be great, as I don't really care whether I am weights up or down for the majority of what I want to do.


Re: Mesu 200 Mk2 Tracking stops close to equator

Don W
 

Hi Paul,
Slippage anywhere in the drive is bad.  All slippage is dependent on the load and the level of friction.  Slippage is by definition when the friction is overcome and the two parts allow movement when you don't want any movement there.

So Slippage can be the friction drive wheel (like the Mesu Mount drive), it could be a set screw in a coupling or belt drive hub, or as Chuck mentioned the output drive gear in Pittman Servos is staked to the output shaft. Any and all of these cases "could" occur in a localized place in the sky - for instance due to balance where in part of the sky the motion is working against the balance load.  The cause of slippage doesn't know or care where you are pointing in the sky - it just slips when the friction isn't enough.

Generally the SiTech servos will be applying torque when tracking similar to when slewing.  The acceleration and deceleration of a heavy and especially a long refactor (lots of moment of inertia) is where the loads on the drive are higher.  If slippage is marginal during acceleration then SiTech can be set to reduce the acceleration forces.

Don W


Re: Mesu 200 Mk2 Tracking stops close to equator

paul K
 

Just to ask the question to try to help, would the slippage Chuck describes be positional as per Jose's problem? Or given the gearing ratio (motor to mount)  would it be more evident i.e not just one place in the sky?

Paul


Re: Mesu 200 Mk2 Tracking stops close to equator

Don W
 

Hi Chuck and all,
Chuck has a good point that slippage might be IN THE SERVO.  But that would also affect slewing.

A test for this (or any slippage) would be to slew between two stars (about 10 degrees or more apart) with a camera recording the positions at each star.  Do this a few times and the images will confirm if there is any slippage.
Don W


Re: Mesu 200 Mk2 Tracking stops close to equator

CandCShaw
 

One more thought..... if the servos have built in gear reducers on them, the spur gears may be slipping at the armature gear or at the output gear.  Quite a few years ago I had what I thought was drive slippage, but my clutches were confirmed to not be slipping. Turns out, it was the spur gear that was “staked” to the output shaft that was slipping under load. The motor was one I had obtained from Dan.  This was a low odds failure, but the lesson is not to rule out things without solid evidence. 

Chuck 


On Apr 8, 2021, at 2:42 PM, Don W <westergren@...> wrote:

Hi All,
I am a SiTech user since 2008 and one of the authors of the SiTech manuals (not written by Dan) in 2009.  I am also a moderator of the forum, along with Dan and Chuck Shaw.  I try to answer all questions that come up on this forum.  Over the years I have been in personal contact with Mesu users and with Mr Mesu himself.  The recent problems discussed here now are apparently mostly with the newer Mk2 version.

I believe Mr Mesu stands firmly behind all his products, just as Dan stands behind all the SiTech products.  The more products produced and sold means there will be some products that have "problems".  These are also complex products, which have "learning curves" so many times the answers are in the settings and use of controls.  Also many times the "problems" are caused by users using other programs which interact with SiTech and the mount.  A large number of problems occur when settings in two or more software try to control the same operation - you and I don't know which is the culprit.

In Jose's case, the SiTech logs show that the servos are moving properly, but the camera proves the mount is not moving properly.  With a friction drive, there "CAN" be slippage and that is what is indicated.  That is a mount problem, pure and simple.  Mr. Mesu has produced a lot of mounts over the years using friction drives and they "work".  I have never seen a Mesu Mount, but I understand the setup of the friction drives is something the user doesn't normally do.  Only Mr. Mesu does that.

All friction drives have the possibility of slippage.  Dan programmed into SiTech ways of using mount axis encoders to detect and handle "slippage".  The Mesu mounts are the only ones I know of now being produced with friction drives.  All the early Mesu Mounts used to have mount encoders.  Now they don't, so Mr. Mesu must be confident that slippage is not a problem.  but as always, with many many products produced, a few will have problems.  I think that is what we have here.

Don W


Re: Mesu 200 Mk2 Tracking stops close to equator

CandCShaw
 

Don, servo config has an excellent routine for determining tics per rev for friction drives. It does not require any “mount” encoders, just the Motor encoders. 

Chuck


On Apr 8, 2021, at 2:42 PM, Don W <westergren@...> wrote:

Hi All,
I am a SiTech user since 2008 and one of the authors of the SiTech manuals (not written by Dan) in 2009.  I am also a moderator of the forum, along with Dan and Chuck Shaw.  I try to answer all questions that come up on this forum.  Over the years I have been in personal contact with Mesu users and with Mr Mesu himself.  The recent problems discussed here now are apparently mostly with the newer Mk2 version.

I believe Mr Mesu stands firmly behind all his products, just as Dan stands behind all the SiTech products.  The more products produced and sold means there will be some products that have "problems".  These are also complex products, which have "learning curves" so many times the answers are in the settings and use of controls.  Also many times the "problems" are caused by users using other programs which interact with SiTech and the mount.  A large number of problems occur when settings in two or more software try to control the same operation - you and I don't know which is the culprit.

In Jose's case, the SiTech logs show that the servos are moving properly, but the camera proves the mount is not moving properly.  With a friction drive, there "CAN" be slippage and that is what is indicated.  That is a mount problem, pure and simple.  Mr. Mesu has produced a lot of mounts over the years using friction drives and they "work".  I have never seen a Mesu Mount, but I understand the setup of the friction drives is something the user doesn't normally do.  Only Mr. Mesu does that.

All friction drives have the possibility of slippage.  Dan programmed into SiTech ways of using mount axis encoders to detect and handle "slippage".  The Mesu mounts are the only ones I know of now being produced with friction drives.  All the early Mesu Mounts used to have mount encoders.  Now they don't, so Mr. Mesu must be confident that slippage is not a problem.  but as always, with many many products produced, a few will have problems.  I think that is what we have here.

Don W


Re: Mesu 200 Mk2 Tracking stops close to equator

Don W
 

Hi All,
I am a SiTech user since 2008 and one of the authors of the SiTech manuals (not written by Dan) in 2009.  I am also a moderator of the forum, along with Dan and Chuck Shaw.  I try to answer all questions that come up on this forum.  Over the years I have been in personal contact with Mesu users and with Mr Mesu himself.  The recent problems discussed here now are apparently mostly with the newer Mk2 version.

I believe Mr Mesu stands firmly behind all his products, just as Dan stands behind all the SiTech products.  The more products produced and sold means there will be some products that have "problems".  These are also complex products, which have "learning curves" so many times the answers are in the settings and use of controls.  Also many times the "problems" are caused by users using other programs which interact with SiTech and the mount.  A large number of problems occur when settings in two or more software try to control the same operation - you and I don't know which is the culprit.

In Jose's case, the SiTech logs show that the servos are moving properly, but the camera proves the mount is not moving properly.  With a friction drive, there "CAN" be slippage and that is what is indicated.  That is a mount problem, pure and simple.  Mr. Mesu has produced a lot of mounts over the years using friction drives and they "work".  I have never seen a Mesu Mount, but I understand the setup of the friction drives is something the user doesn't normally do.  Only Mr. Mesu does that.

All friction drives have the possibility of slippage.  Dan programmed into SiTech ways of using mount axis encoders to detect and handle "slippage".  The Mesu mounts are the only ones I know of now being produced with friction drives.  All the early Mesu Mounts used to have mount encoders.  Now they don't, so Mr. Mesu must be confident that slippage is not a problem.  but as always, with many many products produced, a few will have problems.  I think that is what we have here.

Don W


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi Paul,

 

Thanks for the confirmation & offering to test in the east.

 

My procedure is the same as yours but on the opposite side of the meridian in the east. The only other difference is that I’ve not made a habit of a ‘pre-initialisation’ during the day as you do because I tend not to shut down the drive but leave it energised. If I do and have previously parked then it remembers where it is anyway. I have tried powering it off and re-initialising though but it makes no difference to the outcome.

 

As you say imaging opportunities are rarer these days which is why it’s so important everything works as expected.

 

That’s why I invested in the Mesu\SiTech combination; and it is good. I like the construction and the software and tracks & guides very nicely.

 

This issue can’t be down to SGP otherwise I’d see the same problem in the West and you would too. SiTech-wise the only real difference between us is our Meridian limit settings (because of our different pier arrangements) but I just don’t see why (in the east) that should cause the mount to slew to the exact mirror position on the opposite side of the meridian during plate solving?

 

Hopefully Don’s solution will resolve this & I can hold up my hand and apologise profusely.

 

Best regards

Martin


Re: Long term alignment (new user)

jmgoldba
 

On Wed, Apr 7, 2021 at 01:54 PM, Mark Copper wrote:
The hardware is a thousand miles away.
Okay, I'm just under 500 miles away. Though I rely on others, like Don, who live closer for hands-on I do run the software at home in a simulator mode.

There are two things going on: configuration and control. The 'Using Nexus...' document should really be called 'Configuring Nexus...'. All off the shelf control programs typically have some planetarium functionality. SiTechExe has SkyView.

I'm still not clear how you're planning to control your mount, as in point at targets, using the Nexus. On Linux I suppose you can use KStars with a Nexus Indy driver or maybe Nexus has some mount operation program that's going to include a Park option, where the Nexus program effectively hides the SiTech interface from the user after its been configured.

Jesse


Re: Offset Init & flip during SGP sequencing

paul K
 

Hi Martin,

Yes I initialise (and park) at Az 270. Each session (there's usually quite a lot of time between them these days) I initialise using skyview to get an offset init @ Az 270 with the scope horizontal. (I usually do this sometime during the day). I then slave the dome to the scope in SGP at the start of an imaging run and use the Sitech handpad to slew to a random location west of the Meridian, and platesolve to get an accurate offset init. I then use centre now or 'run sequence' in SGP, BUT I've always done the first platesolve west of meridian, just 'cos of trees to N and to E.

However, as I mentioned I'm moving my obs to a field with no obstructions and my plan there is to set everything up in SGP and let it start by itself, so if my target was E of meridian, when a timed sequnce starts in SGP, the first platesolve will be in the east.

I do have a bit of visibility slightly E of meridian at my current location, so I'm going to try a 1st platesolve in the East next clear night just to check this out. I'll post back.
Best wishes
Paul


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi Paul,

 

Yes that’s exactly what I’m saying J

 

So just out of interest you always initiate in the West? And park in the West too?

If so then you are initiating, parking & plate solving all on the same side of the pier?

I’m just trying to get a handle on how others are working & if this could be relevant?

 

Many thanks for your support.

 

Best regards

Martin


Re: Offset Init & flip during SGP sequencing

paul K
 

I respect your position on this Don, but I can just hear folks saying - why am I getting involved with instructions for driving a car when I drive a motorbike.... :)
Perhaps a minor mod to help those folks who don't need to get involved with the not inconsiderable detail of meridain limits and flips, might be to provide a tick box in Sitech config which auto populates the boxes with the setttings needed for flipless working. Just trying to help....
best wishes
Paul


Re: Offset Init & flip during SGP sequencing

paul K
 

Hi Martin, so if I have it right, what you're saying is if you decide to image a target anywhere in the east and the mount platesolves in order to centre on the target, your mount will flip. Is that right?

I don't image in the east due to trees, so never tried a platesolve looking east.

Paul


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi Don,

 

I’ve not had an opportunity to image yet but in preparation I have the settings configured as you suggested. I am initiated in the East and parked in East as I always do.

 

I can perform GOTO’s via Skyview, SGP, Cartes Du Ciel or Stellarium and the mount behaves as I would expect a GEM to behave. I.E. it flips if select a target on the opposite side of the meridian; either going from East to West or West to East. It goes through the pole if my target is in the opposite sky quadrant. And it re-parks correctly from anywhere in the sky.

 

It does not auto-flip or stop tracking when the scope tracks past the 90 deg track-past setting you suggested or if the scope tracks past either pole.

 

This is great but all of the above was also true of my previous settings.

 

The problem occurs during plate solving in the East, when the ‘InitPoint’ window appears during the adjustment (East radio button active). That’s when my mount would flip – but as I said to Paul – not a ‘genuine’ Meridian flip. It wouldn’t be pointing back at the target. It flips to the same declination but mirrors the RA position on the opposite side of the Meridian. I.E. If the target was 3hrs East of the Meridian, the mount would ‘flip’ to the same declination but 3hrs West of the Meridian.

 

If my scope was in the open air & not in a dome then it would actually work out because having performed this strange flip SGP re-plate solves, with the InitPoint window showing the West radio button active this time (I assume because the scope is now looking West). The plate solve error is obviously massive but the mount then returns to the correct position, plate solves again (East radio button active again when the InitPoint windows appears) and this time my imaging sequence continues as if nothing has happened.

 

If my target was in the West the plate solve takes place (West radio button active when the InitPoint windows appears), the mount remains where it should, it takes one or two small plate solve adjustments as you might expect and my imaging sequence continues as it should.

 

So Don, although I’m really hopeful that your suggested settings resolve this behaviour I’m struggling to understand how the Meridian & track-past limits can influence the plate solving\InitPoint routines in this way?

 

If you have any further thoughts please let me know. If not then I’ll get back to you once I’ve had a chance to actually image.

 

Many thanks & regards

Martin


Re: Mesu 200 Mk2 Tracking stops close to equator

Jose Ignacio Sanchez Rodriguez
 

Hello Paul,

Thanks for your post. The MKII has clutches. What I mean with not engaged is that, with the motors unclutched, I start tracking on SiTech.exe. In such a way I can perform a day test an establish a baseline for what I should expect during a night test or even during a day test under load. I just cannot setup indoors right now. Some building stuff going on at home.

If the current variation I observe in the above conditions is normal, then I can perform further tests with conditions closer to the ones last weekend. If it is not normal, then I have saved a lot of time.

As the DEC motor is idle during tracking I just checked what happens to its current when I slew the scope in DEC with the handpad. I see a similar variation in current as I observe on the RA motor while tracking in the above mentioned conditions. If I slew in RA while tracking the current does not go up much higher than while tracking. That sounds a little off, but I declare myself a total ignorant in this respect. That´s why I want to know if what I observe in this controlled conditions is normal or not.

I already sent the PHD2 and SiTech logs to Lucas. I´ll report back with his conclusions.

Best Regards,

Jose


Re: Mesu 200 Mk2 Tracking stops close to equator

paul K
 

Hi Jose, when you say tracking but not engaged, I'm not quite sure what you mean by that. It is useful to test the motors under no load (I guess that's what you mean by not engaged?), but what I'd say is the 'acid test' is to monitor the motor current under a normal load i.e. clutches engaged, mount position set to roughly where it failed and the system tracking. It will probably take a lot of time to check it, but if it's possible to log motor volts and amps you could just check the log. Don will know.

best wishes
Paul


On Thu, 8 Apr 2021 at 10:27, Jose Ignacio Sanchez Rodriguez <jsanchez.es@...> wrote:
Hello Don,

Today I checked the amperage and voltage of the motors on the SiTech Controller Stuff. This was with the motors tracking but not engaged, so as to be able to control for the balance variable. What I saw is that, on what I assume is the DEC motor (the one on the right) the amperage was pretty constant at 0.05. I think this is because, as I am not guiding, the DEC motor is idle. When I hover over the RA motor (the one on the left) the current moves from as los as 0.04 to as high as 0.1.  The voltage (I think there is a common indicator for the two motors) is steady at 13.5, which is my PSU voltage.

I am attaching a link to a short video of this test (the voltage does not show in the video, only the currents).

https://www.dropbox.com/s/764w5rhmvc934jo/Controller%20Stuff%20Motors%20Amperage.mov?dl=0

Is such variation of the RA current something normal? 

Best Regards,

Jose

741 - 760 of 33617