ascominitiative / ascomplatform Goto Github PK

The Observing Conditions Hub includes a test program. The program has a Chooser button that launches the Chooser to select an Observing Conditions driver. However, the user's selection is not honored and it appears that only it can only test the OC Hub.

I recommend that either the Choose button be removed, but keep the Setup button, or if the test program is suitable, allow it to be used as a test client program for any OC driver.

The Telescope Simulator for .NET returns its AssemblyVersion for its DriverVersion. Currently this is '6.6.0.0'.

The documentation states that it must only contain the major and minor versions and be of the format 'n.n'.
Clearly the string returned by the simulator is incorrect.

Also Conform does not validate this and does not raise an error when '6.6.0.0' is returned.

The Alpyca package tries to validate the version value returned from the Simulator, via ASCOM Remote, as a float. This fails and it raises an exception to the caller.

The ASCOM Telescope Simulator has a setup setting called "Tracking Rates". When this option is checked, the Simulator supports all 4 possible drive rate values. However, if Tracking Rates is unchecked, the only supported rate is driveSidereal. However, no InvalidValueException is raised when an attempt is made to set to set the tracking rate to an unsupported value.

In addition, since Conform only tests supported rates, no error is generated by Conform that says that the Simulator is non-conformant.

The triple-slash comments generated by the Visual Studio Template for a Switch driver and a local server put comments for several methods into the driver code that are different from the documentation in the Developer Help file. These should be reviewed and corrected, as necessary. Methods needing review are:

MinSwitchValue (help file says "should return 0.0" but code comment says "must return 0.0")
MaxSwitchValue (help file says "should return 1.0" but code comment says "must return 1.0")
SwitchStep (help file says "should return the value 1.0" but code comment says "must return 1.0")
GetSwitchValue (help file says "must not throw a "MethodNotImplementedException" but code comment says "boolean switches must throw a not implemented exception"
SetSwitchValue (help file says "Can throw a MethodNotImplementedException if CanWrite(int16) is False" but code comment says "boolean switches must throw a not implemented exception.")

Also, the generated code for SwitchStep seems to be incorrect. The logging call and throwing the initial exception are commented out in favor of returning a constant 1 from the method.

This might also be an opportunity to improve the documentation of the expected behavior regarding how the SetSwitchValue method should behave in the case of a boolean switch, where the expected values are 0.0 or 1.0, when an intermediate value like 0.5 is provided by a client app. The goal should be to provide guidance so that drivers authors know how the driver needs to behave so that all drivers react the same to this type client error.

The Platform Developer help for ASCOM.DeviceInterface.ICameraV3.SensorName says that it is "Mandatory must return an empty string if the sensor is unknown".

In the Remarks section it says "May throw a PropertyNotImplementedException if the sensor's name is not known."

ASCOM.DriverAccess.Camera.SensorName has no guidance about the fact that an empty string could be returned or that the property is optional.

Hi,

in ASCOM version 6.4. this method is not working anymore. This was working fine in version 6.3 and below.
When calling it with a julian date retrived via NOVAS31.JulianDate() this method is throwing "Not a legal OleAut date"

at System.DateTime.DoubleDateToTicks(Double value)
at ASCOM.Astrometry.EarthRotationParameters.DeltaT(Double RequiredDeltaTJulianDateUTC) in C:\ASCOM Build\Export\ASCOM.Astrometry\ASCOM.Astrometry\EarthRotationParameters.vb:line 493

Did the input for this method change, or what's wrong here?

Regards,
Stefan

The ASCOM 6.5 Developer Document needs to be corrected for the ICameraV3.InterfaceVersion. The documentation indicates that the property should return "2" for this interface version. This should be corrected to "3".

Thanks!

The ASCOM script generator seems to insert
MinVersion=0,5.0.2195sp4
which INNO v6 rejects. Commenting this out lets the script ignore this. I am not sure what this should be set to.

The ASCOM script generator uses {cf} to generate directory paths for INNO. But {cf} is invalid in v6 of INNO. Should I be using {commoncf} instead?

An ASCOM user reported that the Platform installer failed to detect and warn that .NET Framework 3.5.1 was not activated on his Win 10 system. According to the current Platform Release Notes, the installation should have provided a popup warning and paused to allow activation of the version 3.5.1 before proceeding on Windows 10. Per the user he received no warning popup but activating v3.5.1 allowed a subsequent installation to complete without error.

In a C# driver that is generated from the ASCOM device driver template a variable is created to hold a static instance of the TraceLogger object that is used throughout the driver for logging driver activity as specified by the author. This is the C# code:

    /// <summary>
    /// Variable to hold the trace logger object (creates a diagnostic log file with information that you specify)
    /// </summary>
    internal static TraceLogger tl;

Also generated is a Dispose method as follows:

    public void Dispose()
    {
        // Clean up the tracelogger and util objects
        tl.Enabled = false;
        tl.Dispose();
        tl = null;
        utilities.Dispose();
        utilities = null;
        astroUtilities.Dispose();
        astroUtilities = null;
    }

Notice that Dispose cleans up and disposes the TraceLogger object. The issue is that 'tl' is static so if there are two instances of a driver in a local server they both share the same trace logger. And of one of those instances is disposed by its client, the static trace logger is also disposed. Then when the remaining instance of the driver attempts to write to the trace logger, a null reference exception is generated.

The fix may be as simple as removing the static keyword from the definition of the TraceLogger instance variable.

Peter,

I originially posted this under the NOVAS3.1 error with the same exception but have created a new issue as I think it may be different. To help you track the problem down here is a little unit test to replicate the problem.

using System;
using ASCOM.Astrometry.Transform;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace LunaticAstroEQ.Tests
{
   [TestClass]
   public class TransformTest
   {
      [TestMethod]
      public void TestMethod1()
      {
         using (Transform transform = new Transform())
         {
            double longitude = 1.3223722222222223;
            transform.SiteLatitude = 52.65177222222222;
            transform.SiteLongitude = longitude;
            transform.SiteElevation = 175.5;
            transform.JulianDateUTC = LocalApparentSiderealTime(longitude, new DateTime(2017, 03, 28, 21, 0, 0));
            transform.SetTopocentric(0.13166666666666665, 29.0);
            double alt = transform.ElevationTopocentric;
            double az = transform.AzimuthTopocentric;
            Assert.AreEqual(alt, 10.0); 
         }
      }

      private double LocalApparentSiderealTime(double longitude, DateTime localTime)
      {
         // get greenwich sidereal time: https://en.wikipedia.org/wiki/Sidereal_time
         //double siderealTime = (18.697374558 + 24.065709824419081 * (utilities.DateUTCToJulian(DateTime.UtcNow) - 2451545.0));

         // alternative using NOVAS 3.1
         double siderealTime = 0.0;
         using (var novas = new ASCOM.Astrometry.NOVAS.NOVAS31())
         {
            var jd = localTime.ToUniversalTime().ToOADate() + 2415018.5;      // Taken from ASCOM.Util.DateUTCToJulian
            novas.SiderealTime(jd, 0, novas.DeltaT(jd),
                ASCOM.Astrometry.GstType.GreenwichApparentSiderealTime,
                ASCOM.Astrometry.Method.EquinoxBased,
                ASCOM.Astrometry.Accuracy.Reduced, ref siderealTime);
         }
         // allow for the longitude
         siderealTime += longitude / 360.0 * 24.0;
         // reduce to the range 0 to 24 hours
         siderealTime = siderealTime % 24.0;
         return siderealTime;
      }
   }
}

The exeption will be thrown on the line double alt = transform.ElevationTopocentric;

Looking at the exception call stack it is the following line that is causing the problem.
LogDebugMessage("DeltaUT1(JD)", String.Format("Automatic DeltaUT1 is required for Julian date: {0} ({1})", RequiredDeltaUT1JulianDateUTC, DateTime.FromOADate(RequiredDeltaUT1JulianDateUTC - OLE_AUTOMATION_JULIAN_DATE_OFFSET).ToString(DOWNLOAD_TASK_TIME_FORMAT)))
Line 649 in EarthRotationParameters.vb. I think you have an error in your debug message logging.

The call stack is:

   at System.DateTime.DoubleDateToTicks(Double value)
   at System.DateTime.FromOADate(Double d)
   at ASCOM.Astrometry.EarthRotationParameters.DeltaUT1(Double RequiredDeltaUT1JulianDateUTC) in C:\ASCOM Build\Export\ASCOM.Astrometry\ASCOM.Astrometry\EarthRotationParameters.vb:line 649
   at ASCOM.Astrometry.AstroUtils.AstroUtils.DeltaUT(Double JulianDate) in C:\ASCOM Build\Export\ASCOM.Astrometry\ASCOM.Astrometry\AstroUtils.vb:line 400
   at ASCOM.Astrometry.Transform.Transform.TopoToJ2000() in C:\ASCOM Build\Export\ASCOM.Astrometry\ASCOM.Astrometry\Transform.vb:line 582
   at ASCOM.Astrometry.Transform.Transform.Recalculate() in C:\ASCOM Build\Export\ASCOM.Astrometry\ASCOM.Astrometry\Transform.vb:line 653
   at ASCOM.Astrometry.Transform.Transform.get_ElevationTopocentric() in C:\ASCOM Build\Export\ASCOM.Astrometry\ASCOM.Astrometry\Transform.vb:line 438
   at LunaticAstroEQ.Tests.TransformTest.TestMethod1() in C:\Users\phil\source\repos\LunaticAstroEQ\LunaticAstroEQ.Tests\UnitTest1.cs:line 21

Kind regards,

Phil

p.s. I tried forking the repository and referencing the sources directly from a test project to debug this further but it wouldn't run the sources, just the installed platform DLLs. I don't want to screw up my development machine so I have had to stop.

From the help document's table of contents, clicking on the ASCOM.DriverAccess Dome Class topic brings up a document that displays the name and description of the Constructor, along with all the Properties and Methods of the class. Under Properties, the description of the CanPark property says "True if driver is capable of setting dome altitude." This is incorrect. if you drill down to the page for that property (Dome.CanPark) you see the same description.

The same error does not exist in the description of the IDomeV2.CanPark property description.

Was running Conform and saw some minor enhancements that might be of value for a testing telescope driver:

Attempt to write an unsupported TrackingRate value should raise an error (not currently tested)
Reading TargetRightAscension and TargetDeclination after valid values have been written (not currently tested).

When using comtypes to connect Focuser .Net simulator, the GUI will be shown, but always Not responding, the API works fine. All the other simulator works fine.
Thanks.

Affected items:
containerfile: D:\download\ASCOMPlatform64.exe

file: D:\download\ASCOMPlatform64.exe->(7zSfx)->ASCOMPlatform64.res->RemoveASCOM.exe

Affected items:
containerfile: C:\ProgramData\miaC621.tmp\ASCOMPlatform64.res

file: C:\ProgramData\miaC621.tmp\ASCOMPlatform64.res->RemoveASCOM.exe
file: C:\Users\mayo\AppData\Local\Temp\mia1\RemoveASCOM.exe

Above is what I got from Windows Defender during installing 6.4 SP1. Is it false alarm?

Per Peter Simpson,
All the imaging applications I’m aware of depend on having a valid value for SensorType.

However the documentation in both ASCOM.DeviceInterface and DriverAccess sections describe the property as Optional.

Also, Conform reports an issue if SensorType raises a PropertyNotImplementedException, as is required when an optional property is not supported.

Consider revising the documentation, perhaps to say that a default value of monochrome should be returned if unavailable or unknown. Another option could be to provide a new sensor type of Unknown.

The ASCOM Telescope Simulator for .NET has the ability to specify the capabilities of the simulated telescope. One of those capabilities is whether the telescope supports asynchronous equatorial slewing (CanSlewAsync). Another is whether the telescope driver supports the ApertureArea, Aperture Diameter and FocalLength properties (CanOptics).

These values exist on the setup dialog form as the Equatorial Asynchronous and Optics checkboxes, but when the user changes the checked state for those controls and closes the form with the OK button those values are never harvested from the form and saved to the simulator's profile or reflected in the behavior of the simulator.

As per Rick B. this web page needs to be updated

https://ascom-standards.org/Help/Developer/html/P_ASCOM_DeviceInterface_ICameraV2_ImageArray.htm

It states that the return code for no image data avaiable is NOT CONNECTED, it is supposed to be INVALID OPERATION.

Additionally there is a typo on the page, " iamges" >> "images"

Thanks
Mark

Regarding 6.5 RC2

Profile Explorer started throwing exceptions after I used it to delete a device profile.

This started when I was testing a driver which was getting NullReferenceException when trying to restore settings through the SettingsProvider. This is not supposed to happen because missing settings are created with a default value. However, I found that the settings were present but with empty values. Thinking this to be an odd situation, I opened Profile Explorer and used it to delete the device's profile (top level settings key). This appeared to work.

I re-ran my driver and still got the NullReferenceException. I tried to open Profile Explorer amd it threw the exception in the screen image above. It now does this every time.

The exception message requested that I run ASCOM Diagnostics, which also threw an exception and it looks like there may be a deadlock situation. I believe this could be the issue that @DanielVanNoord mentioned in our last online meeting.

I have attached an export of my ASCOM device profile registry in case that helps, but I suspect the issue is a deadlock in Utilities.Profile.

I don't think I have ever observed this issue prior to running the 6.5 RC.

I have had a look into the code (actually after the last meeting) and there doesn't seem to be any obvious explanation for this. It's worth asking @DanielVanNoord - when you saw this problem, were you using the SettingsProvider or going direct to the profile?

HKLM_Software_ASCOM.zip

Hello,

When open "ASCOM Diagnostics" on a W7 Pro or connect some devices like a Takahashi focuser, appears a similar message like this

Error System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> ASCOM.Utilities.Exceptions.HelperException: Unable to open ephemeris file: C:\Program Files (x86)\Common Files\ASCOM\Astrometry\JPLEPH, RC: 1
at ASCOM.Astrometry.NOVAS.NOVAS31..ctor() in C:\ASCOM Build\Export\ASCOM.Astrometry\ASCOM.Astrometry\NOVAS31.vb:line 107
at ASCOM.Astrometry.AstroUtils.AstroUtils.InitialiseAstroUtils() in C:\ASCOM Build\Export\ASCOM.Astrometry\ASCOM.Astrometry\AstroUtils.vb:line 46
at ASCOM.ActiveFocuser.Focuser..ctor()
--- End of inner exception stack trace ---
at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
at System.Activator.CreateInstance(Type type, Boolean nonPublic)
at System.Activator.CreateInstance(Type type)
at ASCOM.DriverConnect.ConnectForm.btnConnect_Click(Object sender, EventArgs e) in C:\ASCOM Build\Export\ASCOM.DriverConnect\ConnectForm.cs:line 245

Regards.
Arritrancos

When the Chooser attempts to instantiate a driver in order to display the Setup dialog, and the driver's constructor throws an exception, the Chooser reports the stack trace reports that the exception was thrown in ChooserForm.vb. It may be more useful to report the information in the InnerException, instead. This has 2 advantages...First, it tells the user that the issue is in the driver rather than the Platform and second it gives information to the driver author about what the issue may be.

1. The driver specification says hours but the simulator seems to have implemented minutes.r specification says hours but the simulator seems to have implemented minutes.
2. There is a typo in the observing conditions simulator title - configurtation.

Issue Description:

• When ASCOM Alpaca discovery is initiated, the broadcast packet goes out over all network interfaces.
• If the interface does not permit broadcast traffic ( Wiregaurd, TailScale ), an 'ICMP Destination Unreachable' is received on the UDP port. ( ICMP Type 3, Code 3 - Port unreachable ).
• This causes the UDPClient code to close the port before any discovery responses can be received and processed.

From ASCOM.ChooserForm.1153.196840.txt log file, the following exception is triggered:

11:53:19.832 Finder - FinderDiscoveryCallback                           4 - Exception: System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host[0D][0A]   at System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult, EndPoint& endPoint)[0D][0A]   at System.Net.Sockets.UdpClient.EndReceive(IAsyncResult asyncResult, IPEndPoint& remoteEP)[0D][0A]   at ASCOM.Utilities.Finder.FinderDiscoveryCallback(IAsyncResult ar) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\AlpacaSupport\Finder.vb:line 193

Confirmed source is ICMP Destination Unreachable via packet capture:

Solution:
According to this stackoverflow post, this behavior can be disabled by setting a specific Client.IOControl Code:

public const int SIO_UDP_CONNRESET = -1744830452;
var udpClient = new UdpClient(endpoint);
udpClient.Client.IOControl(
    (IOControlCode)SIO_UDP_CONNRESET, 
    new byte[] { 0, 0, 0, 0 }, 
    null
);

This appears to be needed around both Finder.vb line 41 and Finder.cs line 47.

I suspect this is impacting a large subset of ASCOM Alpaca users since it seems probable that an ASCOM equipped computer would have a VPN enabled ( especially for remote observatories ).

Unrelated - I think there's a typo in Finder.vb line 45, Finder.vb line 167 and Finder.cs line 52. Specifically, I suspect ethereal port is likely meant to be ephemeral port.

Hello,

I would like to integrate the ASCOM dlls into a Matlab script (by using "loadlibrary(dll-file,header-file)" and I look for the necessary headers files. Unfortunately, in the ASCOM developer Tools only XML-files are included. Are C Header files available for the ASCOM dlls?

Best regards,
Thomas

Here is a use case we have:

_I need to operate momentary action switches via the ASCOM Switch interface that we need to automate at a remote observatory in Chile and operated from the UK. These relay switches are programmed in hardware to remain closed for a set pre-programmed time and then open. These are used to turn on and off 10Micron mounts via their EXT socket and to start up and shutdown NUC computers via the mother board "front panel" header socket. In particular these momentary action switches are used to shut down hung computers and 10Micron mounts without cycling power to the whole rig.

A small detail here is the regular boot / shutdown occurs when the switch opens as long as its not been closed for more than 5 seconds. If the momentary action switch is closed for >5 seconds the computer (or mount) is forced to power down at the hardware level. Hence we have pairs of programmed switches wired in parallel - one switch is programmed as a 2 second momentary action switch and will boot or do a regular shutdown on either NUC computers or 10 Micron mounts. The other switch is programmed to do 8 seconds momentary action to force a hung or unresponsive computer or mount off (it happens !).

So the question is how to interface momentary action switches to the Ascom (Alpaca) Switch interface? The interface supports latched binary switches and multivalued switches but not momentary action swtches

In an ideal world I would use /setswitch => true to trigger the hardware momentary switch and expect /getswitch to tell the truth and return false when asked - as the switch will have opened again. Note that we want to know the state of the switch - not the hardware the switch controls as there are other ways to start and stop that hardware. The fly in the ointment with this idea is Conform Universal declares this an Issue when /getswitch does not return the last value given to /setswitch_

Here is a suggestion that could be worked on as the basis for a future extension to the Switch interface if the above use case interests you (I'm doing these as roughed out Alpaca endpoints - switch id arguement is assumed):

• Add a method /getswitchtype method returning one of a set of code values interpreted as BinarySwitch, MultiValueSwitch and MomentarySwitch. The later is a new type of switch. This method could support future extensions such as TimerSwitch or whatever along with additional methods appropriate for the switch type.

• Add a /triggerswitch method, This would initiate the momentary action switch. This method should only be called if /getswitchtype has returned a MomentarySwitch code. If it is called for another type of switch it should raise an exception. Other methods such as /getswitch, /getswitchvalue could also raise the Not Implemented exception for momentary action switches

• Add an optionally implemented /gettriggerduration method that indicates the duration the switch closure period. A client can use this to animate a switch graphic to indicate the duration if the momentary nature of the switch. If Not Implemented then the client can animate (or not) the switch graphic in anyway they choose. This method should only be called if /getswitchtype has returned a MomentarySwitch code. If it is called for another type of switch it should raise an exception.

As I said this is a sketch of an idea.

Documentation for this property states:

The inital value of this parameter is 0.0, which is a special value that forces Transform to replicate original behaviour by determining the Julian date from the PC's current date and time. If this property is non zero, that particular terrestrial time Julian date is used in preference to the value derrived from the PC's clock.

It seems that setting this value to 0 should be permitted and pass validation as this is a special case within the interface for this property.

The simulator has a Profile setting called "Track on / off Support". Presumably the purpose of this setting is to indicate whether the simulated telescope supports changing the Tracking state. However it appears to be not completely implemented.

Turning off "Track on / off Support" does not prevent changing the Tracking flag from either the Simulator U/I or from a connected application. Nor does it throw a PropertyNotImplementedException as specified in the interface specification.

Please add "May raise an error if the telescope is not tracking or is slewing" or something similar to the developer help guide for the PulseGuide method. This can be used for Telescope drivers that may not want to complete a PulseGuide command while slewing or not tracking and want to return an error to the calling application.

The DestinationSideOfPier method is apparently optional because of comments that indicate that it could throw a MethodNotImplemented exception. However, there is no way to simulate or test this behavior except through a driver that exhibits this behavior. It would be helpful for the simulator to be able to optionally throw MethodNotImplemented exception as a result of calls to DestinationSideOfPier to allow application developers to have confidence that they are handling this type of "weak" driver correctly. One of these drivers is the Software Bisque 2X Telescope Driver.

Thanks!

Net Core 3.0 ArrayLists are not COM Visible so direct casting does not work. .Net Core only exposes ArrayLists over COM as IEnumerble. CoreFX has chosen not to fix this, see: https://github.com/dotnet/corefx/issues/40675.

All of my commits are showing up as anonymous in the commit history. My Git user ID is "NameOfTheDragon" and I would like my historical commits to be associated with that user ID so that I'm correctly identified as the author of my work.

When running Conform against the ASCOM.Simulator.Telescope driver, an issue with PulseGuide is reported when dual axis pulse guiding is deselected in the driver properties. Disabling dual axis pulse guiding is supposed to indicate that calls to PulseGuide are synchronous. This should mean that Conform should never see IsPulseGuiding as True. However, the following output is generated by Conform.

08:33:22.193 PulseGuide ISSUE Synchronous pulseguide expected but IsPulseGuiding has returned TRUE

When using the ASCOM Templates to create a skeleton driver, one of the created files is ReadMe.htm. For an in-process driver that ReadMe file contains the following statement very near to the top of the file:

Prior to developing your first driver, please familiarize yourself with the developer information we've provided at the ASCOM Initiative web site (internet required).

Part of that text is a link to a developer.html page on the ASCOM-Standards web site. Clicking on this link generates a page not found error. I believe that instead the link should be "https://ascom-standards.org/Developer/Index.htm".

ASCOM DeviceHub accesses the getters for TargetRightAscension/Declination during SyncToCoordinates

This was reproduced using SharpCap, using a plate solve + sync as the first action after connecting the mount (no slew).

In the Validate sub statement for the Switch template that checks that the number of states for the switch is correct, wrong is misspelled.

TL.LogMessage(message, String.Format("Switch {0} has the wriong number of states", id, ns))

See this code:

When transforming J2000 coordinates using ASCOM's transform library, topocentric is used only if SiteTemperature is also provided. This parameter shouldn't be required if Refraction is false. In J2000ToTopo, SiteTemperature isn't even used if refraction is disabled.

The Annunciator control doesn't always display correctly. There are some corner cases when the control's on/off state or cadence are changed that result in the control being invisible or not displaying in the correct cadence. Improvement is desirable.

The LED control appears to be affected in a similar way.

This would be a great first issue for someone new to the project to take a crack at.

See the discussion from the mailing list for extra context: https://ascomtalk.groups.io/g/Developer/topic/80764828?p=Created,,,20,2,0,0

Please update the IDomeV2 documentation to reflect async design principles, particularly with respect to:

• Slewing property following shutter operations, dome rotation, and parking
• ShutterStatus following OpenShutter and CloseShutter

At the moment there's been confusion between application developers and driver developers regarding what should happen after an async method returns to the caller. In particular, it should:

• Raise an exception if the operation isn't going to take place
• Corresponding status property reflects an inprogress or completed state immediately

Without this, applications may need to poll and wait to see if progress takes place which is a violation of design principles.

Microsoft Windows Version 1909 (OS Build 18363.476)

I get the following error:

Error reading from file C:\PROGRA3{F4B1C1\OFFLINE\459C26BD\C4C88ADB\AscomMasterInterfaces.tlb. Verify that the file exists and that you can access it.

I do not see the folder 459C26BD in the following directory:
C:\ProgramData{F4B1CB96-DAB5-4F31-AA59-94ECEEFDE0F9}\OFFLINE

The following doesn't log doesn't provide any additional clues as to why it failed.

1:55:51 PM ASCOM Platform 6.4 SP1 v6.4.1.2695
1:55:51 PM Installation date: 11/27/2019
...
1:55:51 PM Installer: C:\ProgramData\miaAB61.tmp\ASCOMPlatform64.exe
1:55:51 PM Engine cache: C:\ProgramData\{F4B1CB96-DAB5-4F31-AA59-94ECEEFDE0F9}\
...
1:55:51 PM Product code: {8961E141-B307-4882-ABAD-77A3E76A40C1}
1:55:51 PM Revision code: {F4B1CB96-DAB5-4F31-AA59-94ECEEFDE0F9}

1:55:51 PM Installer mode: MSI Engine

1:55:51 PM OS: Windows TENFOUR
1:55:51 PM Product Name:  Windows 10 Enterprise
1:55:51 PM Edition:  Enterprise
1:55:51 PM Version:  6.3
1:55:51 PM Build:  18363
1:55:51 PM Build Label:  18362.1.amd64fre.19h1_release.190318-1202
1:55:51 PM Architecture: 64bit

1:55:51 PM Install method: EXECUTABLE
...
1:55:51 PM Win64Mode: TRUE
...
1:55:51 PM FrameworkRoot: C:\Windows\Microsoft.NET\Framework\ 
1:55:51 PM RegAsm32: C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe
1:55:51 PM RegAsm64: C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\regasm.exe
1:55:51 PM NGen32: C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe
1:55:51 PM NGen64: C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\ngen.exe
1:55:51 PM ProgramFiles: C:\Program Files (x86)\
1:55:51 PM CommonFiles: C:\Program Files (x86)\Common Files\
1:55:51 PM Maintenance: FALSE, RecommendedUpgrade: FALSE, NeedsUpgrade: FALSE
1:55:51 PM GAC Assembly Reference Path: SOFTWARE\Wow6432Node\Microsoft\Fusion\References
...
1:55:51 PM DesktopDirAll: C:\Users\Public\Desktop\
1:55:51 PM ASCOMStartMenu: ASCOM Platform 6
1:55:51 PM AllUsers: TRUE
1:55:51 PM Target Directory: C:\Program Files (x86)\ASCOM\Platform 6
...

1:55:51 PM Install cache directory: C:\ProgramData\{F4B1CB96-DAB5-4F31-AA59-94ECEEFDE0F9}

1:55:51 PM Platform Version: 6.4.1

1:55:51 PM CheckMSI31 - MSI library found OK
1:55:51 PM CheckNet4 - Found Client framework version: 4.8.03752
1:55:51 PM CheckNet4 - Framework 4 Client present: TRUE
1:55:51 PM CheckNet4 - Found Full framework version: 4.8.03752
1:55:51 PM CheckNet4 - Full Framework 4 Client present: TRUE
1:55:51 PM CheckVC14(86) - VC 14 library (32 bit) found OK
1:55:51 PM CheckVC14(64) - VC 14 library (64 bit) found OK
1:55:51 PM Mode: Install new version
1:55:54 PM Platform Installation Options - TRUE
1:55:54 PM Install Desktop Diagnostics Shortcut - TRUE
1:55:54 PM Install Profile Explorer Shortcut - TRUE
1:55:54 PM Display User Guide - FALSE
 
1:55:54 PM Straight forward install - removing old Platform 4 or 5 if it exists
1:55:54 PM Platform 4.1 - 
1:55:54 PM Platform 5A - 
1:55:54 PM Platform 5B - 
1:55:54 PM First time install, preparing ASCOM Profile Store
1:55:54 PM RC: 0 Set ACL on ASCOM Profile Store
 
1:55:54 PM Installing 32bit Registry entries
1:55:54 PM Creating shortcuts in native mode
1:55:54 PM DesktopFolder: C:\Users\Public\Desktop\
1:55:54 PM ShortcutFolder: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\ASCOM Platform 6

2:06:20 PM Apply Install - Success:  ERROR, LastError: Fatal error during installation

2:06:27 PM UserGuide: User guide display not requested

The odd thing is that it installed OK on a Lenovo laptop over a year ago, either the current download or the older download yields the same error on this desktop.

If I ignore the error, I get the same error for each .tlb file.

Hi,

I noticed that the Observing Condition Hub does not call TimeSinceLastUpdate of the underling driver(s). The result is always 0 (or close to zero).

I think the problem is not the drivers, because :

• when the drivers are called directly the values are correct
• the behaviour is the same with several drivers.

I found that at this line :

the condition is never true, so, these lines are executed

Before investigate, I would like to know if this is a known issue.

Regards,

Julien

Hi, Peter
I create an ASCOM 6.5 RC1 driver demo using project template(c#) in Visual Studio Community 2019 , without any addtional code, build it and test it with a console application , which is also generated from the template, the driver throw an exception on creating AstroUtils object line:

astroUtilities = new AstroUtils();

Data:
System.Collections.ListDictionaryInternal

StackTrace：
ASCOM.Utilities.RegistryAccess.EnumProfile(String p_SubKeyName)
C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\RegistryAccess.vb : line 325

TargetSite :
{System.Collections.Generic.SortedList`2[System.String,System.String] EnumProfile(System.String)}

Is that a bug? or any other settings are not correct?

thanks!

PS: I had ever installed ASCOM Platform 6.4 SP1 before on my Win10 laptop.

In Section 2.8.3 ASCOM Reserved Error Numbers, the values in the COM Exception Numbers column appear to have one too many digits. For example, 0x800400400 should be 0x080040400.

Screenshot attached.

In the following screen snipping, notice "ASCOM Remote Client 1" in the drop-down list.

I wanted to delete this remote client, but the delete screen is empty:

Some application which use ASCOM.Astrometry experience a leak of handles of a registry key "HKLM\SOFTWARE\WOW6432Node\ASCOM". On my system in a remote observatory the leak rate was about 19000 handles per hours.

After some debugging, it turned out that these handles are opened by RegistryAccess objects allocated by AstroUtils and EarthRotationParameters classes.

Both EarthRotationParameters and AstroUtils classes did not have the Finalize method implemented, so the garbage collector could not properly dispose these objects, including RegistryAccess member objects.

After implementing Finalize methods (see the attached diff) the leak is not reproducible anymore. I was able to test the fix on my imaging system by simply copying ASCOM.Astrometry.dll with the fix to Windows\assembly\GAC_MSIL and Common Files\ASCOM. There were no noticeable leak after a couple of hours.

So while the problem has been fixed for me, it would be good to have the fix included in official ASCOM package. Other people, who run astrophotography automation software continuously for many days, would benefit from the fix.

Thanks,
Vitali
AstrometryLeak.txt

ASCOM doesn't recognize the usb port to my telescope is connected to. My Dell computer does recognize it. I have new SynScam V5 Controller which has USB port so connection cable issues should not apply unless ASCOM and SynScan V5 controller are not compatible. Could it be a driver problem? If so, where do I get the driver? Ed

Testing the ASCOM.Simulator.Focuser with Conform version 6.4.1.2694 reports the following error:

06:34:27.948 Move - TempComp True ERROR TempComp is True but no exception is thrown by the Move Method - See Focuser.TempComp entry in Platform help file

The simulator reportedly supports IFocuserV3 (InterfaceVersion = 3). This should mean that focuser movement when TempComp is true is allowed and no exception would be expected.

This seems like a bug in Conform.

Thanks!

Hi,

When using Sequence Generator PRO, the Observatory will occasionally disconnect and a message box titled "ASCOM Dome Control Panel" will appear containing the following lines of text:

Run-time error '-2147352567 (80020009)':

Unable to complete command

Clicking OK causes the ASCOM Dome Control Panel to disappear from the screen. I can then click reconnect in SGP and the control panel will restart, but often the dome will likely have closed before I've realized the ASCOM Dome CP crashed and any exposures in progress need to be restarted.

The dome being controlled is a MaxDome II

I am using the latest 6.4.1.2695 ASCOM platform release.

If there are any system logs that you can direct me to I would be happy to provide them.

Thanks,

John

I found a bug in ASCOM.Astrometry.AstroUtils.AstroUtils.EventTimes method.
It doesn't return sunrise time events for latitude lat = 26.695512 and longitude lon = 100.03105 for the date of December 14, 2019 .
I could observe that changed 1% latitude works correctly. It works if you change the time zone.
I think it fails if the time is too close or is equal to 0:00.
Attached code example:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using ASCOM;

namespace testAscomSunsetRise
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
            ASCOM.Astrometry.Transform.Transform apTransform = new ASCOM.Astrometry.Transform.Transform();
            ASCOM.Astrometry.NOVAS.NOVAS31 apNOVAS = new ASCOM.Astrometry.NOVAS.NOVAS31();
            ASCOM.Astrometry.AstroUtils.AstroUtils apUtil = new ASCOM.Astrometry.AstroUtils.AstroUtils();
            System.Collections.ArrayList astroNight = new System.Collections.ArrayList();
            System.Collections.ArrayList civilNight = new System.Collections.ArrayList();
            System.Collections.ArrayList sunRiseSet = new System.Collections.ArrayList();
            DateTime lastUpdate = DateTime.UtcNow;
            double lat = 26.695512;
            double lon = 100.03105;
            civilNight = apUtil.EventTimes(ASCOM.Astrometry.EventType.CivilTwilight, lastUpdate.Day, lastUpdate.Month, lastUpdate.Year, lat, lon, 0);
            astroNight = apUtil.EventTimes(ASCOM.Astrometry.EventType.AstronomicalTwilight, lastUpdate.Day, lastUpdate.Month, lastUpdate.Year, lat, lon, 0);
            sunRiseSet = apUtil.EventTimes(ASCOM.Astrometry.EventType.SunRiseSunset, lastUpdate.Day, lastUpdate.Month, lastUpdate.Year, lat, lon, 0);
            Console.WriteLine("Latitude: " + lat.ToString());
            Console.WriteLine("Longitude:" + lon.ToString());
            Console.WriteLine("Time" + lastUpdate.ToString());

            Console.WriteLine("sunRiseSet cont :" + sunRiseSet.Count.ToString());
            foreach (var e in sunRiseSet) Console.WriteLine("Array sunRiseSet:" + e.ToString());
            Console.WriteLine("civilNignht cont :" + civilNight.Count.ToString());
            foreach (var e in astroNight) Console.WriteLine("Array astro:" + e.ToString());

            Console.WriteLine("astroNight cont :" + astroNight.Count.ToString());

            DateTime objDateWoHour = lastUpdate.Date;
        }
    }
}


The output of the example with a bug and changing the latitude (1%).

C:\Users\Isilda\source\repos\testAscomSunsetRise\testAscomSunsetRise\bin\x86\Deb
ug>testAscomSunsetRise.exe

> 
> Hello World!
> Latitude: 26,695512
> Longitude:100,03105
> Time14/12/2019 18:07:22
> sunRiseSet cont :4
> Array sunRiseSet:True
> Array sunRiseSet:0
> Array sunRiseSet:1
> Array sunRiseSet:10,4769542132567
> civilNignht cont :5
> Array astro:True
> Array astro:1
> Array astro:1
> Array astro:22,6261952111538
> Array astro:11,8566759109858
> astroNight cont :5

> C:\Users\Isilda\source\repos\testAscomSunsetRise\testAscomSunsetRise\bin\x86\Deb
> ug>testAscomSunsetRise.exe
> Hello World!
> Latitude: 26,96246712
> Longitude:100,03105
> Time14/12/2019 18:14:55
> sunRiseSet cont :5
> Array sunRiseSet:False
> Array sunRiseSet:1
> Array sunRiseSet:1
> Array sunRiseSet:0,00456997991677
> Array sunRiseSet:10,4673235217848
> civilNignht cont :5
> Array astro:True
> Array astro:1
> Array astro:1
> Array astro:22,632481231502
> Array astro:11,8504289094108
> astroNight cont :5

Add Device Hub to the Platform installer alongside POTH.