No, but Jasem is aware of the issue. Apparently it has also affected some Baader and Maxdome ii users. Which is why he thinks it is in the Base class I believe.

Read More...

Hi, these are exactly the same symptoms I was experiencing.
I gave up looking at the code in the end, and compiled the grozzie V1.0 driver from source as I knew it worked ok(ish) and th
E slaving works fine. It's still a bit flakey and not as good as Tim Long's V3.x code, but slaving works at least. If the issue really is in the Base class you would think the v1 driver would be affected in the same way. If you do decide to use the old driver don't forget the firmware on both shutter and rotator need to be flashed to match the driver. I also had to clear the eeprom and re-program the xbees as Tim uses a different method to program these from the previous drivers.

If it is ever resolved I would go back to the new drivers though.

Mark

Read More...

Hi Jasem,

I have recompiled the driver as you have suggested, but unfortunately the dome still will not slave beyond the first movement after unparking the mount. It does move to slave after pressing abort as before.
I have attached the full log file of a short test.

However, the STOP command is now recognised as the snip from the log below shows.

[2020-01-12T14:56:44.707 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P304> with value <304> "
[2020-01-12T14:56:44.962 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P234> with value <234> "
[2020-01-12T14:56:45.218 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P184> with value <184> "
[2020-01-12T14:56:45.476 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P156> with value <156> "
[2020-01-12T14:56:45.733 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <STOP> with value <STOP> "
[2020-01-12T14:56:45.734 GMT INFO ][ org.kde.kstars.indi] - NexDome : "[INFO] Dome reached target position. "
[2020-01-12T14:56:45.734 GMT INFO ][org.kde.kstars.ekos.observatory] - "Dome is tracking."

After the abort button is pressed, ekos reports the "Dome is idle" and it then immediately moves to target, as in the snip below.

[2020-01-12T14:59:38.099 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] CMD <@SWR> "
[2020-01-12T14:59:38.102 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] RES <STOPHstop 0:SER,14523,0,53900,0,300> "
[2020-01-12T14:59:38.102 GMT INFO ][org.kde.kstars.ekos.observatory] - "Dome is idle."

I also note I have about 25 lines of this error on starting up before the GPS driver is detected, and this may, or may not, be relevant:

[2020-01-12T14:54:30.792 GMT INFO ][ org.kde.kstars.ekos] - "EQMod Mount is online."
[2020-01-12T14:54:30.947 GMT WARN ][ default] - qrc:/qml/mount/mountbox.qml:274: ReferenceError: xi18n is not defined
Several lines removed
[2020-01-12T14:54:30.948 GMT WARN ][ default] - qrc:/qml/mount/mountbox.qml:695: ReferenceError: xi18n is not defined
[2020-01-12T14:54:30.963 GMT INFO ][ org.kde.kstars.ekos.mount] - "GPS driver detected. KStars and mount time and location settings are now synced to the GPS driver."

Happy to try anything else.

Many thanks

Mark

File Attachment:

File Name: log_14-54-10.txt
File Size: 188 KB


Read More...

Hello Jasem,

I have looked everywhere but I can't see anyone else having this issue.

I automated my Pulsar dome last year using the same Stepper motors/drivers and Arduino Leonardo/Xbee arrangement as NexDome explicitly in order to use the INDI NexDome drivers. I have had the dome hardware working and slaving well with indi/Kstars using the original v1 firmware developed by Grozzie. My mount is an AZ-EQ6GT using the eqmod mount driver.

Now INDI has moved on to the official NexDome hexfile firmware, I flashed the new v3.2.0 firmware on the rotator and shutter and both are working very well using the latest V1.4 NexDome driver , with the exception of the dome slaving to the mount.

The dome will move to slave one time after unparking the mount but not after that. Also the manual CCW and CW buttons in the driver will work once only. Until, that is, the abort button is pressed, where the dome will then move to the correct mount azimuth. Similarly the CW & CCW buttons will again move the dome once, after each abort button press. in the NexDome driver tab the following warning appears:

"2020-01-11T21:03:19: [WARNING] Please stop dome before issuing any further motion commands."

Examining the log files it appears that when the dome reaches it's target azimuth and stops moving it issues a STOP but it is interpreted as a status request instead as the response given apears to be for a @SRS command as in <:SER,7935,0,53900,0,300#> with value <7935,0,53900,0,300> " shown below. The INDI driver thinks the dome is still moving. The abort button issues a "hard stop" using the @SWR command and afterwards INDI is free to move the dome again.

An example from the log, edited for brevity, shows the mount has been slewed to azimuth 45 degrees and, following an abort button press, the dome immediately begins slaving:

[2020-01-11T15:50:36.924 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] CMD <@SWR> "
[2020-01-11T15:50:36.929 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] RES <STOPHstop 0:SER,149,0,53900,0,300> "
[2020-01-11T15:50:36.930 GMT INFO ][org.kde.kstars.ekos.observatory] - "Dome is idle."
[2020-01-11T15:50:36.934 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] JD: 2.45886e+06 - MSD: 23.2189 "
[2020-01-11T15:50:36.934 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] MC.x: 0.03 - MC.y: 0.18 MC.z: 0.07 "
[2020-01-11T15:50:36.934 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] HA: -7.56305 Lng: 0.404272 RA: 102.133 "
[2020-01-11T15:50:36.934 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Active Snoop, driver: EQMod Mount, property: TELESCOPE_PIER_SIDE "
[2020-01-11T15:50:36.934 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] OTA_SIDE: 1 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] OTA_OFFSET: 0.53 Lat: 51.5228 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] OC.x: 0.240877 - OC.y: -0.200657 OC.z: -0.232541 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Mount Az: 45.452 Alt: 21.1014 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] OV.x: 0.664875 - OV.y: 0.654467 OV.z: 0.360019 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Mount Az: 45.452 Alt: 21.1014 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] OV.x: 0.664875 - OV.y: 0.654467 OV.z: 0.360019 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Calculated target azimuth is 53.8915. MinAz: 45.7782, MaxAz: 62.0048 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] CMD <@GAR,53> "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] RES <Phase 0:right> "
[2020-01-11T15:50:36.937 GMT INFO ][ org.kde.kstars.indi] - NexDome : "[INFO] Dome is moving to position 53.8915 degrees... "
[2020-01-11T15:50:36.938 GMT INFO ][org.kde.kstars.ekos.observatory] - "Dome is moving clockwise..."
[2020-01-11T15:50:36.942 GMT INFO ][ org.kde.kstars.indi] - NexDome : "[INFO] Dome is syncing to position 53.8915 degrees... "
[2020-01-11T15:50:37.427 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P165> with value <165> "
[2020-01-11T15:50:37.678 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P202> with value <202> "
[2020-01-11T15:50:37.929 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P260> with value <260> "
In between steps removed

[2020-01-11T15:50:54.293 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P7840> with value <7840> "
[2020-01-11T15:50:54.545 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P7893> with value <7893> "
[2020-01-11T15:50:54.796 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P7925> with value <7925> "
[2020-01-11T15:50:55.048 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <STOP> with value <TOP> "
[2020-01-11T15:50:55.550 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <:SER,7935,0,53900,0,300#> with value <7935,0,53900,0,300> "

This happens repeatably after the first dome move.

I looked at the source code for the driver and in <nex_dome_constants.h> part of the file is shown below the static constants for the commands have "S" assigned to both REPORT and EMERGENCY_STOP. Since they cannot both be "S" I assume REPORT, the first assigned, will be allocated to it. I am not a programmer, and I may well be wrong, but to me this might explain logically why the stop command is interpreted as a status report request and INDI thinks the dome is still moving.

From nex_dome_constants.h :

// Command Strings
static const std::map<Commands, std::string> CommandsMap =
{
{ACCELERATION_RAMP, "A"},
{DEAD_ZONE, "D"},
{SEMANTIC_VERSION, "F"},
{GOTO_AZ, "GA"},
{GOTO_HOME, "GH"},
{HOME_POSITION, "H"},
{POSITION, "P"},
{RANGE, "R"},
{REPORT, "S"},
{EMERGENCY_STOP, "S"},
{VELOCITY, "V"},
{EEPROM, "Z"},
{OPEN_SHUTTER, "OP"},
{CLOSE_SHUTTER, "CL"},
};

I hope this helps, I have the full logs available if necessary.

Many thanks

Mark

Read More...

Hi knro,
The update appears to have resolved the problem.
The wheel connects without issues with all my normal hardware attached and USB lead configuration.
I have have given this an extensive test and I could find no faults with the wheel operation.
All my defined filters appeared in the Capture tab filter selection drop-down with no extra entries.
I am extremely grateful for your efforts in resolving the issue.
Many thanks
Mark

Read More...

Hi knro

I thought I sent this successfully this morning but it's not here, so I will submit it again,

May thanks

Mark

Read More...

Hi knro, thanks for your help.

I have updated and tested the wheel with my normal usb connection.
I used a minimal configuration to test: telescope simulator; ccd simulator and the sx wheel. This time the wheel connected in the driver control panel without crashing.
Unfortunately on selecting the sx wheel in the Ekos Capture tab kstars crashes. This seems repeatable. I attach a couple of backtraces that look identical plus the wheel logs.

Prior to this I tested using the ZWO ASI 178mm and the EQMod mount driver and results were less predictable. Sometimes I could get as far as Ekos capture, select the sx wheel and preview but the filters did not physically change (exactly as before) and the preview hung waiting for the filter to change. Also in these cases the filter drop down showed extra slots Filter_8 ,9,10,11 and 12.

Let me know if you would like me to try any particular tests.

Many thanks

Mark

Read More...

Hello, this is my first post on the forum.

I have finally found an issue I could not (eventually) fix :)
With my usual working equipment setup, after I updated to the latest kstars-bleeding via:
sudo apt-get update && sudo apt-get -y dist-upgrade
On connecting my filter wheel in the driver control panel kstars crashes repeatably every time. It does this regardless of what else is connected. Even a minimal configuration with telescope simulator and ccd simulator plus the wheel (all other hardware disconnected) causes a crash.

I have tried every permutation and combination of leads/hubs/both USB3 and USB2/powered/non-powered. The only way that does not cause a the crash is a direct lead from the wheel to a usb2 port on the computer. This is running the latest Ubuntu as updated via the above command.

This appeared to connect ok (green indicator) and the actual filter names could be reinstated from the defaults and saved to the config file. The filter could be heard moving when a new position was set in the driver control panel. Unfortunately when returning to the Ekos Capture tab, the problem had not been resolved. The sx wheel drop down shows the filters I defined, but also additional undefined slots. When taking a preview exposure (by both camera and camera simulator) it worked ok on the default filter position, but selecting a different filter and then preview leads to a hang while it waits forever for the filter to move to another position before the exposure can start. The filter wheel does not physically move.

I have a sx wheel 7 position model SXUFW-UM36T - Has latest firmware 1040-12 (reflashed to ensure no corruption) and functions correctly with Starlight's stand-alone windows application.

I am no expert, but I had a look at the 3rd party drivers on the github and some recent changes may have a bearing on the matter since it has always worked flawlessly before this. Here is where I looked:


indi/3rdparty/indi-sx/

Latest commit 0548078 23 days ago

"knro - Since most filter wheels save and load filter names from configuration file rather than hardware, the functionality is moved to FilterInterface to reduce duplication of Get and Set Filter names across all drivers"

3rdparty/indi-sx/sxwheel.cpp

I have attached the repeatable crash backtrace and a logfile for the crash (no really useful info) and last nights log where the wheel was connected by the single usb2 port but the Capture module could not control the wheel.

Any help on this issue would be greatly appreciated.

Mark

Read More...