Date   

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


Re: Mesu 200 Mk2 Tracking stops close to equator

Jose Ignacio Sanchez Rodriguez
 

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


Re: Offset Init & flip during SGP sequencing

Don W
 

Hi Russell,
The colors are the limits set  for the meridian limits, and they reflect the colors of the limit lines in SkyView.
Don W


Re: Offset Init & flip during SGP sequencing

Russell R
 

Don W.,

I don't ever deal with meridian flip limits, but curiosity got the best of me. What are the colors blue, green and yellow referring to in that diagram? 
Ol Chuck is quite the artistic engineer!

Russell R.


Re: Long term alignment (new user)

Mark Copper
 

Sorry for not being clear. The Nexus is connected to the SiTech Servo Controller serial port to serial port. (https://www.astrodevices.com/resources/NexusDSCdocuments/Using-Nexus-DSC-with-SiTech-Servo-controller.pdf)

No, I'm not just staring at hardware. Worse. The hardware is a thousand miles away this week and I'm just *thinking* (and reading) about it. And to make matters worse I'm not familiar with any planetarium software -- unless you count Kstars. While thinking (in the shower, of course) it dawned on me that having just built an observatory, maybe I shouldn't need to align the telescope after every power cycle.

However, I have learned a couple things over the last day. Serge at Astro Devices kindly called and both informed me that he is working on a parking routine for the Nexus and assured me that 6-8 Mpoint objects would suffice to build an alignment model that would serve my scope (a Spica Eyes) and current purposes. Don W kindly pointed out if I can get SiTechEXE going, then SiTech also provides a parking facility and Taj at Sidereal Technologies has told me that Dan G had developed a Linux wrapper for SiTechEXE as well so I may not need to resuscitate a Windows box. Finally, there is an interesting thread this week at Cloudy Nights that mentions maintaining alignment across multiple sessions with the Nexus as well.

So I am very appreciative of the information everyone has generously provided, and am looking forward to getting hands on next week.

Mark


Re: Offset Init & flip during SGP sequencing

Don W
 

Hi All,
Your comments wanting special settings for flipless GEMs are un-necessary.  The settings I suggested for Martin do exactly what you want.  Nothing more is needed regarding modifying SiTech.
Don W

741 - 760 of 33612