Author Topic: LFEP ASCOM driver - bug reports  (Read 92748 times)

Offline Armando

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 225
Re: LFEP ASCOM driver - bug reports
« Reply #80 on: Tuesday, 17.12.13 - 13:28:04 - CET »
Hi the_lizardking,

Looks good,... however there is a samll drift but could be related to the alignment maybe.
There is apparent coma but I think the stars are pretty round near the center-bottom part of the frame...

Quote
When you say we need to go over ascom, do we only need to work with an ascom camera driver going from camera to lfep or must the lfep be connected to the pc somehow??
Do not guide by ST-4.

CS
Armando

Offline the_lizardking

  • Hero Member
  • *****
  • Posts: 136
Re: LFEP ASCOM driver - bug reports
« Reply #81 on: Wednesday, 18.12.13 - 09:51:03 - CET »
OK then Camera to LFEP ASCOM driver,... understand.

Offline Armando

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 225
Re: LFEP ASCOM driver - bug reports
« Reply #82 on: Saturday, 05.04.14 - 19:29:31 - CEST »
Hi @all,

I just uploaded a new driver on SourceForge:
http://sourceforge.net/projects/lfepascom/files/LFEP%20ASCOM%20Driver%20%281.5.3%2005-04-2014%29.exe/download

Before going to post an update notice message on this forum I'll gladly appreciate some tests mainly related to flip and parking.

Clear Skies
Armando Beneduce
« Last Edit: Thursday, 10.04.14 - 15:03:55 - CEST by Armando »

Offline Armando

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 225
Re: LFEP ASCOM driver - bug reports
« Reply #83 on: Thursday, 10.04.14 - 15:14:21 - CEST »
I received no feedback about the last release.  ::)
Anyway... I found a bug; a new driver is available.

CS
Armando

Offline drknoppi

  • Full Member
  • ***
  • Posts: 39
Re: LFEP ASCOM driver - bug reports
« Reply #84 on: Thursday, 10.04.14 - 18:29:44 - CEST »
Hello Armando,
The recent weather conditions are
April like, very poor.
Thank you for your work 😀
Rainer
LG
Rainer

Offline Armando

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 225
Re: LFEP ASCOM driver - bug reports
« Reply #85 on: Thursday, 10.04.14 - 19:28:06 - CEST »
Hi Rainer,

I know that weather is not good at all...
But, if possible, we should test the driver also with bad weather so that we find no bad surprises under clear skies...
Unfortunately I can't test park and flipping and your feedback is really useful to speed up the driver development.
Anyway I hope current driver is working.

CS
Armando

P.s. You can see a file that includes "TDM" in its name is also available on SourceForge. Please ignore it: it's meant to control an I2C slave used to power Off TDM while mount is slewing. I implemented this solution to exclude possible flip/parking issues when a TDM controller is in use.
the_lizardking will use it. If someone else means to equip his mount with TDM I'll provide further details about the required hardware and I2C slave firmware requirement.

Offline Heinz-S

  • Full Member
  • ***
  • Posts: 43
Re: LFEP ASCOM driver - bug reports
« Reply #86 on: Sunday, 27.04.14 - 18:38:12 - CEST »
Hello Armando,

I just installed the new driver 1.5.3 23-04-2014. Using FW 5.88 I will send you the following feedback:

The confirmation sound, that could be heard after changing a setting with a click on apply or OK is not active any more. Now the slewing led is blinking for a while after clicking on one of the both buttons.

After setting a park position and afterwards clicking on the park button the tracking stops properly, the parking and slewing led starts blinking but the mount didn't move. Instead the driver sends the error message, you will find in the attachment.

The manual flip function I've tested with driver version 1.5.3 13-04-2014 and no error occurs.  Regarding the flip function, I have two questions:

When I start the manual flip, the mount moves to a middle position, where the telescope points to the northern direction. In that position it rests for a while. Afterwards the move was competed. Is it possible, to disable that function or to shorten the time of standstill?

I miss the automatic flip function, that aligns the telescope depending on the position of the object. If the object is been located on the western side of the meridian, the telescope should be located in the east. By analysing the coords of the object, the LFEP should be able to locate the telescope in the right position. At the moment I use the manual flip function to position the telescope on the right side. Would it be very difficult, to implement such an automatic meridian flip function for all the observers, that didn't use a photographic equipment?

CS
Heinz

Offline Armando

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 225
Re: LFEP ASCOM driver - bug reports
« Reply #87 on: Sunday, 27.04.14 - 20:06:15 - CEST »
Hi Heinz,

After setting a park position and afterwards clicking on the park button the tracking stops properly, the parking and slewing led starts blinking but the mount didn't move. Instead the driver sends the error message, you will find in the attachment.
OK, I see the exception. I think you didn't enable autoflip for GoTo.
I think that if you enable autoflip for GoTo the exception doesn't occur.

Quote
Regarding the flip function, I have two questions:

When I start the manual flip, the mount moves to a middle position, where the telescope points to the northern direction. In that position it rests for a while. Afterwards the move was competed. Is it possible, to disable that function or to shorten the time of standstill?
I want to make the driver able to avoid pillar crashes.
You can enable autoflip for GoTo (and/or parking) so that if a flip is opportune it's executed. But you can also force the driver to ask for a confirmation before executing a flip. So if the driver recognizes a flip is opportune but you don't confirm the flip it won't flip. I want to exclude a pillar crash also in this case...
So I had to add other GoTo steps to manage these conditions.
Now I don't know exactly what step you're referring to... Probably you're referring to the step during which the scope is apparently not moving but you can see it's moving (slowly) to cross the N (or S) Pole. If this is the case we need to keep the driver as is; you need just to wait some seconds while scope moves at 16x to cross the Pole.

Quote
I miss the automatic flip function, that aligns the telescope depending on the position of the object. If the object is been located on the western side of the meridian, the telescope should be located in the east. By analysing the coords of the object, the LFEP should be able to locate the telescope in the right position. At the moment I use the manual flip function to position the telescope on the right side. Would it be very difficult, to implement such an automatic meridian flip function for all the observers, that didn't use a photographic equipment?
This feature is already implemented.
You can enable AutoFlip for GoTo and/or for parking. You can also force the driver to ask for a confirmation so that you can still exclude a flip if you want...
For parking you can set a parking position that is good on both sides of pier. This is the reason why you can disable autoflip for parking. If you want to park always at the same side of pier then you've to enable the autoflip for parking. Finally you can also enable autoflip for parking with confirmation required...

I realized that a pillar/tripod crash could be caused by the flip itself (e.g. scope next to tripod and pointing to W near the horizon)!
So I started to deeply modify the driver to take care of many conditions that can cause a pillar crash (the flip itself, when scope is already in an unusual position because of a lot of time passed since the meridian cross; or when a flip is "suggested" by the driver but the user doesn't confirm it; or when the user means to move to a "dangerous position" starting from a "good" one; etc. etc...).

Just for example, if you're pointing to NW with the scope on W side of pier ("bad position") and you send a GoTo to SW a flip is advisable. If you enable autoflip the driver should execute it (and move the scope away from pillar, if necessary). But I added also other steps so that if you don't enable autoflip or if you don't confirm the flip (with flip confirmation required) the scope will move upwards, then only on dec to "bypass" the pillar and finally will point to the target... Other steps occur also if you try to move to a dangerous position. Someone can prefer to park with scope pointing under the horizon... So you can see a pillar/tripod crash against the front side of the scope! The driver should manage also these conditions.

You see I added other settings (in safety tab) to define a dangerous area "around the pillar/tripod" in terms of distance on RA from local meridian when declination is not too far from Zenith's declination (you can set 2 values to define the minimum distances on Dec from Zenith). These values are used to make the driver able to "bypass" the pillar itself.

These are the main changes that I was able to test only "virtually" by CartesDuCiel since my mount is too slow (40x GoTo).
Please let me know if you find the autoflip working and if you see the driver bypasses the pillar as expected when you force the driver to make no flips or when you try to make dangerous GoTos...

CS
Armando
« Last Edit: Sunday, 27.04.14 - 21:12:53 - CEST by Armando »

Offline Armando

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 225
« Last Edit: Sunday, 04.05.14 - 22:20:13 - CEST by Armando »

Offline Heinz-S

  • Full Member
  • ***
  • Posts: 43
Re: LFEP ASCOM driver - bug reports
« Reply #89 on: Tuesday, 06.05.14 - 17:07:01 - CEST »
Hello Armando,

thank you for the detailed explanation. The possibility to enter a time in the flip menu had been the reason for my confusion. Such a function I combine with photographic use only. The HW handbox of my CGEM mount didn't expect to enter a time. It is flipping dependent only on the coords of the objects.

Your explanation, that the pole crossing is moving at 16x had been very helpful. I only had to raise the speed.

The version 28-04-2014 of your driver had fixed the exception bug. The parking function now operates as expected.

The bypass – function I'm not able to test at the moment, because the shack that contains my scope isn't very large. The long scope, I'm using presently, perhaps would crash to one of the side walls.

Using E&T I've chosen a couple of stars alternating on both sides of the meridian. The mount every time flips on the right side with pole crossing at 16x.

A GOTO to Polaris was running in a different way. The scope was located at NW when I started the GOTO. The mount was running to the pole cross position and rested there for a few seconds, moving at 16x. Then it was slewing back to NW until it pointed to Polaris.

After that I started a GOTO to Mars, but that time not using E&T but the HW handbox. The mount was slewing to SE (the bad side) and pointed to Mars. That time the mount crossed the pole without moving at 16x. The whole movement was executed with GOTO speed.

When I parked the scope later on, I noticed that the SW handbox now displayed the wrong orientation (West instead of East). So I think, that it isn't good to use the HW handbox and the driver together for GOTO commands.

CS
Heinz

Offline Armando

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 225
Re: LFEP ASCOM driver - bug reports
« Reply #90 on: Wednesday, 07.05.14 - 20:49:11 - CEST »
Hi Heinz,

Hello Armando,

thank you for the detailed explanation. The possibility to enter a time in the flip menu had been the reason for my confusion. Such a function I combine with photographic use only. The HW handbox of my CGEM mount didn't expect to enter a time. It is flipping dependent only on the coords of the objects.
OK.

Quote
Your explanation, that the pole crossing is moving at 16x had been very helpful. I only had to raise the speed.
Crossing the pole is at 16x speed whatever is the speed associated to 16x pad speed.  ::)
Another reason why you could have thought that mount was not moving (during the flip) could be the starting position: when Dec is about +-90° you "see"  a slow slewing on RA if you "follow" your mount on a sky chart...

Quote
The version 28-04-2014 of your driver had fixed the exception bug. The parking function now operates as expected.
OK. From time to time give a look at Sourceforge to update the driver. Only when I'll have properly tested the driver I'll post  a notification about it on this forum with a change log too...

Quote
The bypass – function I'm not able to test at the moment, because the shack that contains my scope isn't very large. The long scope, I'm using presently, perhaps would crash to one of the side walls.
In any case while testing the driver be ready to stop the mount (a click on Stop or simply a press on any HW handbox button is enough: the driver detects the slewing has been aborted/has failed). Only the step at 16x speed required to cross the Pole requires a click on Stop (or an abort command by any ASCOM client) to be aborted. But generally crossing the Pole is quick and so it's pretty unlikely that you'll abort a slewing exactly while mount is crossing the Pole...

Quote
Using E&T I've chosen a couple of stars alternating on both sides of the meridian. The mount every time flips on the right side with pole crossing at 16x.
OK.

Quote
A GOTO to Polaris was running in a different way. The scope was located at NW when I started the GOTO. The mount was running to the pole cross position and rested there for a few seconds, moving at 16x. Then it was slewing back to NW until it pointed to Polaris.
Polaris is circumpolar and it's one of the targets that can be located "under" the plane orthogonal to your local meridian, even if above the horizon.
For this part of the sky I had to take care of other issues: front side of the scope could collide with the pillar/tripod. I think I need to test by myself the driver to figure out if some changes are required... Anyway the priority is to keep the driver safe so that no pillar crashes can occur.

Quote
After that I started a GOTO to Mars, but that time not using E&T but the HW handbox. The mount was slewing to SE (the bad side) and pointed to Mars. That time the mount crossed the pole without moving at 16x. The whole movement was executed with GOTO speed.

When I parked the scope later on, I noticed that the SW handbox now displayed the wrong orientation (West instead of East). So I think, that it isn't good to use the HW handbox and the driver together for GOTO commands.
I modified the driver so that playing by the HW handbox is possible: previously the driver crashed as soon as you started to play by the HW handbox to send a GoTo command.
But obviously I still suggest to use the PC to control the LFEP.
If you see that HW handbox shows a SideOfPier that differs from the ASCOM one I think your Dec motor rotation is reversed (Dec motor settings). I can do nothing to solve this bug. If I make the driver OK for your Dec motor cables then the users with normal (not reversed) Dec motor rotation will find the HW handbox showing a SideOfPier that differs from the ASCOM one...  :)

As for parking, it's useful only for fixed observatories. And I see no reason to prefer the limited functionality of the HW handbox to control the LFEP at home...
In a few words I see the HW handbox useful on the field, when the equipment is limited and no PC/notebooks are involved, just to point using the catalogs stored on the memory card...
But if you have a PC then the ASCOM driver offers an handy control of the mount...

CS
Armando

Offline the_lizardking

  • Hero Member
  • *****
  • Posts: 136
Re: LFEP ASCOM driver - bug reports
« Reply #91 on: Wednesday, 07.05.14 - 21:40:54 - CEST »
I totaly agree,... if you have the change to use a PC use the ASCOM driver to run the mount. I have a fixed obs and do even not go outside anymore. The driver is meanwhile so good that it works perfect!

Also parking works fine which never worked proper with the handbox - only when you have a crazy parking position like I have it comes to probs from time to time :) . I remember when we began and we where only searching bugs,... most of them on the Handbox and we had an unfinished driver,... today Armando made the safest driver I know moving the mount very intelligent and really safe. Also you can rely on the functions,... the Log gives usefull messages and the driver catches all features, even some that on the handbox never worked...

 

Offline Heinz-S

  • Full Member
  • ***
  • Posts: 43
Re: LFEP ASCOM driver - bug reports
« Reply #92 on: Sunday, 11.05.14 - 09:50:42 - CEST »
Hello the_lizardking,

I totally agree too! Armando has created an excellent driver. He asked the users to test it under different circumstances. While testing, I noted all observations of mount moving to be able to send back an entire report, hoping that it would be helpful.

The using of the HW handbox should complete the test result, because it is also part of the LFEP. When I'm not testing the driver but enjoying a starry night, be insured that I'm not use the HW handbox, except for correcting instructions to center an object with the red buttons. ;)

CS
Heinz