Results 1 to 9 of 9
  1. #1

    Unhappy Bisque Mounts: "Script Error: Property write Tracking is not implemented..."

    Hi Bob,
    I am using ACP Control in my observatory at New Mexico Skies. I have been imaging very successfully with ACP for 6 weeks with few errors excepting dome hardware problems. I have been doing flats using the Autoflats script and by checking dawn or dusk flats when doing a single target color series. These always worked perfectly until two days ago when I go this error. I have not changed any of the files excepting changing angle in defaultflat.txt. After getting this error I reloaded the Autoflats and defaultflat files, but got same error. It is possible that the techsupport team made a change that I am unaware of, but I have no way of knowing that. Can you shed some light on this error as I am dead in the water relative to flats. Imaging of targets continues to work great.
    Using Paramount MEII, Planewave 17, Windows 10 Pro, 15 foot Technical Innovations at NMS.

    Thanks for the help.
    Attached Files Attached Files

  2. #2
    Join Date
    Nov 2015
    Location
    Christchurch, Dorset, United Kingdom
    Posts
    283

    Default TheSky Controlled Driver Setup

    Hi Richard.

    There is a known random issue, as yet unresolved, with TheSky 2X ASCOM driver where if any software package that attempts to make a connection to a Paramount via Software Bisque's 2X ASCOM "TheSky Controlled Driver" and the Paramount is not physically connected or powered up then various properties in the driver setup are turned off, most commonly the "Can set tracking" option which is often the source of the error message that you are reporting.

    Some users have reported suspecting that Windows Updates may also be responsible for resetting "TheSky Controlled Driver" or that if two instances of TheSky are running concurrently that this might also cause "TheSky Controlled Driver" to revert back to default settings.

    Make sure that the mount is powered up and connected and then start up MaxIm, in "Camera Control" module, click "Settings" > "Autoguide Output" > "Control Via" > "ASCOM Direct" > Setup > "ASCOM Telescope Driver for TheSky" > "Properties" and confirm that the driver options are configured as in the attached image then "OK" out and close the tabs.

    Repeat in ACP > "Telescope" > "Setup" > "ASCOM Telescope Driver for TheSky" > "Properties", the same settings should be selected.

    I think most of us Paramount users have seen this crop up but with no obvious cause, hopefully this will be the issue with your system and it will be a simple reset of the TheSky Controlled Driver to fix this issue.

    Note that the attached image is a screen shot of the driver setup tab from my system which is a safe dome with no unauthorised users present and the mount is not left in a powered up state between observing sessions so I have the option "Find Home on initial contact" selected. This causes the mount to find home whenever the driver is invoked and might be dangerous in your situation so choose that option according to your particular situation.

    HTH

    William.

    TheSky Controlled Driver Setup.jpg

  3. #3
    Join Date
    Oct 2005
    Location
    Mesa, AZ
    Posts
    32,391

    Default

    Still traveling... Thank you William!! this purportedly happens if a new TPOINT model is created (not involving ACP of course). Rumor only at this point. Do check to see that the settings shown by William are right. The Paramount settings are also covered in ACP Help, German Mount Specifics.
    -- Bob

  4. #4

    Default Thanks and comments

    Hi Bob,
    Thanks for your help. Here are a few thoughts relative to your suggestions;
    1. My problem is not intermittent. It always happens at the beginning of trying to run flats and it happens every time I try to run flats whether from Autoflats script or part of imaging script that calls flats.
    2. I did change the settings in Maxim as suggested; however, mine is using relays to guide so not set in Maxim for ASCOM. The ACP settings are already as you suggested.
    3. Windows did an update 11/20 so I will keep in mind, it may be the catalyst of the problem as it recently started. BYW, do you know how to completely turn off Windows updates in Windows 10 Pro?
    Thanks so much,
    Rick

  5. #5

    Default Maybe not related

    Hi Bob,
    See my comments back to William. I don't think this is my issue as mine is only flats and not intermittent. Please look into it when possible. I will post if I see anything more.
    Thanks, Rick

  6. #6
    Join Date
    Nov 2015
    Location
    Christchurch, Dorset, United Kingdom
    Posts
    283

    Default Bisque 2X ASCOM driver

    Hi Richard.

    The source of that error in your auto flat log specifically identifies the Bisque 2X ASCOM driver.

    Maybe the Bisque 2X ASCOM driver has been damaged by a Windows update although that really should be apparent when running normal plans too.

    Try uninstalling the Bisque 2X ASCOM driver, reboot the computer, re-install a freshly downloaded copy of the Bisque 2X ASCOM driver and reboot for a final time then check in ACP telescope setup that the Bisque driver is selected and configured.

    I can think of other possibilities that might possibly generate the same error such as the Paramount is being asked to point to a set of coordinates for the flat that are in a user defined collision or horizon limited zone and the mount has “errored”, though again, you would expect to see that with your live data acquisition too, or the mount is not waking from park with tracking suspended when the flat plan is run.

    So far as Windows updates go, to really have control over Windows 10 updates in a sensible managed way requires the use of a Windows server-client model which is the method I use at my observatory. As a client, the observatory computer looks to my Windows micro-server for its updates and as the server administrator I get to decide if/when and which updates to push to the client.
    In all other aspects the client works independently of the server and the server does not even need to be switched on except when managing updates.

    This works of-course even for clients and servers separated via the net so is quite suitable for remote operations, the downside being the cost of the micro-server hardware and Windows server essentials license.

    (I know of some users who configure their Windows 10 systems as clients of an imaginary server with a fictitious IP address, this has the effect of blocking updates, with some additional client side configuration, but is really insecure and ultimately damaging to all other Windows users as the client never receives critical security updates and then becomes a threat to everybody else once it becomes “hijacked”.)

    You might find that you gain enough control over Windows updates simply by using the advanced options in the Windows Update settings to routinely suspend updates for x days. If you enabled that function today you could block all updates until 2nd Jan 2021, and on the 1st Jan 2021 manually “check for updates” install all pending updates and reboot the computer at least twice then re-enable temporary-updates-suspend for another month.
    Managing updates this way you get to decide when the update(s) are installed and you can then positively link a particular update to a subsequent problem and roll-back that update to give you a bit of breathing room while MS (or Bob) find a fix for whatever got broke!

    If I think of anything else re the flat plan failure I’ll post back but I think Bob will probably need all your ACP and Scheduler logs to pin down the reason.

    William.
    Last edited by William Bristow; Nov 27, 2020 at 20:50. Reason: Spelling

  7. #7
    Join Date
    Oct 2005
    Location
    Mesa, AZ
    Posts
    32,391

    Default

    OK, from your log:

    13:10:19 **Scope has no tracking control. Must slew to dither

    and

    13:10:40 Stop tracking for test exposures
    13:10:40 Property write Tracking is not implemented in this driver.
    13:10:40 **Script Error**
    13:10:40 Source: ASCOM.SoftwareBisque.Telescope
    13:10:40 Message: Property write Tracking is not implemented in this driver.



    There are two issues here. One is my bug. I neglected to avoid trying to control tracking for a mount that doesn't support tracking control. Actually, I should rip all of this out and simply require that any mount to be used with ACP have tracking control.

    The real reason for this error is that your mount reports that it cannot be told to turn tracking on and off. The error is coming from within the Software Bisque driver for TheSky/Paramount. Did you look at the settings as posted by William here, specifically Can Set Tracking? If so are you saying that this error appears (a) only when trying to take flats, and (b) if it appears and you immediately check the Can Set Tracking, you see that it is ON? If so this will be interesting to solve. Is it possible that your mount is in a specific condition (Not homed? Parked? or ???) when you do flats? Is it when you first start TheSky? Are you starting TheSky by itself before asking ACP to connect the scope? Did this "just start happening"? No changes to TheSky, the ASCOM plugin, ... (Windows updates would be very unlikely to cause settings in the Bisque scope interface to just change).

    The bottom line is that the scope is refusing to let ACP turn tracking on and off, and ACP needs to be able to control the tracking.
    -- Bob

  8. #8

    Red face Thanks and comments

    Hi Bob et.al.
    I did implement what William suggested. There was a check box for set tracking that was unchecked and I checked it. After doing that my system worked perfectly in Flats and Images ever since. I checked it several times after that day and it remained checked as it should be. Additionally I confirmed that this error type (both flats and images) has been happening to several other clients at New Mexico Skies. Those cases varied from resetting once to fix all the way to cases where it has to be fixed daily. I did not investigate these any further than second hand description of problem. For technical information:
    1. Mine only occurred on flats and not images
    2. After I set the settings to "Track" it has worked since..."Knocking on wood".
    3. My setup uses ACP to "Connect to Telescope" which connects to TheSkyX via ASCOM driver (I believe) and also connects to the dome.

    It is still working to date 2020-12-10.
    Thanks for your prompt and detailed attention.
    Rick

  9. #9
    Join Date
    Oct 2005
    Location
    Mesa, AZ
    Posts
    32,391

    Default

    Richard -- 100% on your reaponse. I don't kkow why that setting in the Bisque system seems to get turned off. It may be an old wives' tale, but it might be running T-Point models or otherwise using TheSKy outaide of its usage as a control system for the bisque mounts and offering an ASCOM interface to same. Or maybe those people are using some other 3rd party software that sneaks in to the Bisque settings storage and turns it off???? I just don't know.
    -- Bob

 

 

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Spurious error: Property write Tracking is not implemented in this driver
    By Russell Croman in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 3
    Last Post: Oct 9, 2020, 15:50
  2. Filter Offset Script Crashing - "System.Dynamic" error from TheSky
    By Mark de Regt in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 1
    Last Post: Jan 13, 2020, 22:37
  3. ACP Stops on 2nd target with "Script Error (Tracking has been stopped)"
    By A Michael Smith in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 3
    Last Post: Oct 26, 2015, 18:39
  4. Solid State Disk Issue (was "ACP Script error while...")
    By rspostrspost in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 7
    Last Post: Oct 2, 2012, 09:14
  5. Tracking Rate Goes from "Stop" to "Tracking" After Darks Plan Initiated
    By Michael Cook in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 4
    Last Post: Apr 3, 2012, 00:39

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •