Questions? Comments or like to contact us? Use this form to message us.


Tel:    +1.604.421.2835

Sign up for our newsletter to get informed about NexDome news or new products.

May 28

X2 plug-in park and abort commands


Rudolphe, this is some data for you. I am using X2 plugin. I tried to park my dome last night and it executed the park command, the dome moved to location, but then it immediately tried to return to sync with the telescope. I hit the abort button to stop it moving and it did for about two seconds then insisted on going to the scope position. The MyT Mount was at home position with tracking off at the time.


I realized that the dome was coupled to the telescope under the dome setup tab. So I uncoupled and then the park was successful. Same with abort.


I thought I might recommend that if a park or abort command is sent that the driver should uncouple the dome from the telescope. If parking then the user probably doesn’t want to continue tracking the scope. If abort then the user probably sees a problem with where the dome is going and just wants it to stop moving completely. I could see that there could be a safety issue with equipment or something if the dome continues to insist on coupling to the scope and moving after an abort.


just thought I would give you a data point. Otherwise I prefer the X2 over the ascom driver because it stays on track better. Thanks for all your work.



Hi Dave,


I have never noticed that behavior. To the contrary, once my mount is parked, the dome parks with no problem. Just curious but was your mount parked?



No it was at home position. Also as a result of the unexpected fight against the abort command I did create a park position of the typical north Pointing with counterweight down and parked the mount. Then when I parked the dome it stayed put, but that could just be because the scope was also pointing that way. I didn’t do a full on trial to see if it decouples the scope once you park. I kind of just got it to a happy place and quit. But I was more concerned about how it fought against the abort command. I would like an abort to also cause the dome to uncouple from the scope because something drastic could be happening and as a user I want abort to mean everything stops moving.

I assume you will be using some sort of executive control program to automate your dome? If so, all of the ones I am familiar with can park your scope before parking your dome. I use CCDAP, mostly because in integrates well with TSX, and it parks the scope, closes the shutter and parks the dome just fine under automated (weather, hardware issue, etc.) abort conditions.


If you're mainly worried about disconnecting the dome from the scope after manually aborting a dome rotation in TSX - then just hit the "disconnect" button in the X2 plugin. Also, for what it's worth, I tried to recreate your experience with my dome but, as long as mount tracking was OFF, the dome stayed put.


One thing you might try is to uncheck the "Couple Dome to Telescope Slews" box; i.e., only check the "Couple Dome to Telescope Tracking" box. You don't really need to couple the dome to slews as it will still move to the correct position as soon as the telescope finishes slewing and starts tracking.

Those are all valid work arounds and yes I was actually trying to set up ccdcommander for the first time and get things working together. and s long as I do things in the correct order all is good. My only concern is that as a user if things are going nuts and I need to hit the abort button, I would expect it to abort the current function whether it is opening or closing the slot, spinning the dome, whatever, and stay still. I don’t want it then chasing a coupling. This goes beyond park timing of commands, etc. it could be that something bad is happening to a piece of equipment, maybe a cable gets caught or an unforeseen event and I just want it to ABORT. I don’t then want it taking off again until I have resolved the emergency. So I’m just asking if a future revision can cause the abort button to uncouple the dome for safety. Maybe display a pop up box like ‘abort successful and BTW the dome is now uncoupled‘. I’m just thinking of future me and the stupid things I do and not wanting those to cascade To a Complete meltdown.

May 30

So my test in TSX , my home and park are at 0º:

- connect to dome

- connect to mount (mount simulator in TSX).

dome rotate to line up with scope.

- park dome

dome rotate to park position at 0º (mount is NOT parked)

- slew mount to something.

mount does slew, dome DOESN'T MOVE and stay parked at 0º


Next test : Change park position to 180º

- unpark dome, it slews to match the mount position.

- park dome : it slews to 180º

- slew scope to something : dome doesn't move and stays parked a 180º


So if the dome moved in your case, something is instructing it to move.

I will try to do a more thorough test and document. Thanks for checking it out. Maybe it was something else I was doing or another setting. Did you have ‘couple to slew’ and ‘couple to tracking’ checked?

Sorry. I was incorrect in my explanation before. I did a test and it was 'home' not 'park' that caused me problems

it seemed to ignore abort command while homing and skyx said it was aborted/ stopped but it was still actually moving.


today's test>>>

connected to dome, says ready


connected to scope, homed to bisque position ra 2 dec 0 , after scope homing stops, dome spins to sync.


park dome command, dome moves to park, stayed in place for 30 seconds or so till i hit next command 'home'


find home. even though park and home are same location, i issued home to get a precise position so that the charger magnets can connect.


when i hit home command after being at park, dome did briefly, but then immediately went to sync position with scope.


when i hit abort, it would maybe pause for just a half second, but then start to move to sync position again.

skyx reported move aborted and dome stopped but dome was actually still moving.

dome reached sync position


uncoupled from scope using check boxes, sent home command. dome started moving to home. i hit abort.


screen said abort successful and the dome slot graphic on thesky stopped at the azimuth where i issued abort command.


but dome actually continued to move to home position then stopped

then thesky dome slot graphic updated to home position


issued park command. dome parked.


under dome setup recoupled to scope with check boxes

dome stayed parked even after i coupled to scope.

unparked dome, and it immediately slewed to sync scope position.




So this is the behavior that I want to report to see if it can be checked out.

If the dome is in the middle of a move to sync or to home, it seems to ignore the abort command.

SKYX control screen says abort successful and dome stopped, but it actually finishes the move.


maybe this is a firmware issue?



May 30

The abort is sent by TSX, the plugin then send it the dome.

If TSX then send another command after that it will be executed.

If I were to ignore all command after an abort, how do you get out of that state ! ? (there is no un-abort).

So not too sure how to handle this when the mount is coupled to the dome.


As for the home then abort when not coupled, it should stop and not move after the abort... I'll retest that tonight if I can on my test rig. It might be related to the homing retries I added because of the way the old firmware was working (or not properly working). If that's the issue I'll remove this and re-test. If that fixes it I'll build a new version of the plugin.




May 31

I can confirm the issue is the built in retry on homing. This was added for the old firmware as the homing was often passing the home sensor and then reporting it had stopped and was not on the home position so the plugin was doing 1 retry to get to the proper home position (as this was a small move at this point).

Now when you abort, it retries and if you abort again when it restart it will stop for good.

I'll remove that retry and will build a new plugin


Sorry to give you more work. I really appreciate all your effort.

May 31Edited: May 31


X2 plugin 2.13 will be ready in a few minutes :)


Edit : Version 2.13 published. on my website.

@Rodolphe I will download and try next outing. I was actually up late tonight running my first tpoint model with a new MyT and polar aligning it. I have to say the X2 hit the center of the dome slot every time and tracked very well. With the Ascom driver I always had issues with it getting behind on tracking. Don’t know why. Could be the coordination between the sky, x2, and MyT. Just seems to work better Than CGX plus Ascom plus Maxim dL. I guess you do get what you pay for and sometimes get for free from nice developers :) thank

New Posts
  • This is the process i go through to get to the speed settings for the shutter, so a few questions: First I open ascom dome control panel I click connect. Of course it doesnt let you change values unless its disconnected, so i disconnect and reopen the nexdome ascom server monitoring window, hit setup: Seems no matter what values i put below, here 600/1500 etc, the speed of the shutter is the same. I had tried lowering these at first to see if it would help with the motor sticking. Is this the right procedure to lower the values and test? Also, i know there is a much longer thread here about updating the firmware on the shutter/rotator, but, what does the update firmware button here do? At one point i clicked it when only the rotator was connected, it claimed it updated? How do i know if i even need to update either? Both came brand new recently? Thanks in advance
  • I've completed the motor install (although i may be missing parts on the motor related to this, the set key that holds the pin in place was missing, found an m4 for now that seems to hold it but the pin doesnt go in fully, see this thread for more details) First issue (or maybe not), when i push the motor and it moves up, i think when the panel that has the band through it goes under the first panel, half way up, it sticks for a half second, flexes and pops and keeps going. After this at times on the way up, even during the first half, sometimes the motor stalls briefly. The biggest issue is after its up fully and you bring it down, the first 16" or so going back it stalls and moans repeatedly, however, interestingly i can work it forward by doing an on off real quick multiple times, OR by pressing upward on the motor. Here is a video clip of the stalling (most of it near the end): At this point i took all the wheels off the rear, added washers, so now they have quite a bit of flex available. The retention bracket is installed, but i had my son work the motor while i pulled back on the bracket and wheel on one side only, no change. When you pull the panels in the rear when its up there, apart, you can see grinding marks on each panel on the sides. So at this point i'm left with removing the retention brackets on both sides as a final test, and to be able to get the panels apart to add antifriction tape someone recommended. It appears the front panels will need to come off (not the rear solid non moving one), then apply tape as here: Here is an external view of the situation: This is the antifriction tape i've ordered (1" x 15 feet, two rolls,TapeCase 423-5 UHMW) : I dont know what else to try, other than what i have planned at this point. Pretty frustrated. Incidentally, i have the inside dome rotation working pretty solidly, so this is the only sticking point, pun intended. Thanks in advance.
  • Im breaking my shutter issues into multi parts here, in this one, i seem to be missing the set screw on the part by the gear as in this image: The part circled was naturally coming out. I'd like to get the official part to fix this, however in the meantime i've added what seems to mostly fit but not flush, m4 set screw and the locking pin goes in a tad further: Any suggestions here? From someone else, it appears that pin should slide all the way inside (i dont know if this could be related to the motor stalling/sticking issue i have (sep thread))