les coordonnees RA/DEC sont fausses et ne correspondent pas.
le driver ASCOM que j'utilise dans ce test est un driver 32 bits qui est appelé par PRISM qui est une appli 64 bits (dans ce cas).
Il faut lire ce qui est ici
https://ascom-standards.org/Developer/D ... 64Bits.htm
In other words, a 32-bit application cannot use a 64-bit driver, and vice versa.
Donc, il faut vraiment un driver ASCOM 64 bits et pas 32 bits.
Ici on voit ce message ->
Ici ce post est assez interessant je trouve ->
https://www.otelescope.com/forums/topic ... ly-driver/
Y a un long post qui explique le detail.
I would offer a slight correction to your statement...BYE does not "launch" ASCOM like one program can launch another program. The ASCOM Platform is referenced by and used within BYE.
The Windows "bitness" rules are somewhat confusing. Here is a summary:
A 64-bit version of Windows can run both 32-bit and 64-bit applications, but a 32-bit version of Windows can only run 32-bit applications. This works because 64-bit versions of Windows include a 32-bit subsystem. There is no 64-bit subsystem for 32-bit versions of Windows.
A 32-bit application can only use 32-bit DLLs and a 64-bit application can only use 64-bit DLLs; with one qualification....NET code (applications and libraries) are interpreted. This type of code is built into and distributed as "intermediate language". This code is then converted from intermediate language to machine language when the code is executed. This means that if .NET DLLs are correctly built, they can be loaded into and run from either 32-bit or 64-bit applications. This is accomplished by building them for "Any CPU". The DLLs that make up the ASCOM Platform are built for Any CPU. This allows the ASCOM development team to distribute only a single version of each DLL with each release. There is no such thing as a 32-bit version of ASCOM or a 64-bit version of ASCOM.
ASCOM drivers different from the ASCOM Platform. That said, some drivers are distributed with the ASCOM Platform, but most are distributed separately, by equipment vendors or independent driver authors. The bitness of drivers is a function of how the driver author created them. Some drivers are DLLs and some are EXEs. The DLLs load into the memory space of the application that is consuming them. Therefore they must be capable of cooperating with that application's bitness. BYE is a 32-bit application. It must be so because it uses the Canon SDK which is a 32-bit unmanaged (non-.NET) DLL. This works for the ASCOM Platform because it is built for Any CPU and is perfectly happy to work as part of a 32-bit program. ASCOM DLL-based drivers that are 32-bit only will work fine with BYE. ASCOM DLL-based drivers that use .NET and are built for Any CPU will work fine with BYE. Only ASCOM DLL-based drivers that are built only for 64-bit will not work with BYE.
That said, if BYE were a 64-bit application, the ASCOM Platform would continue to work well with it and the Sesto Senso 64-bit driver would also work with it, but the 32-bit driver would not work with it.
EXE-based ASCOM drivers run as separate processes from ASCOM client programs like BYE. This means that they can have different bitnesses. If, for example, the 64-bit version Sesto Senso driver was designed, built and distributed as an EXE file, BYE would easily be able to interoperate with it. Also, if the Sesto Senso driver were developed from one of the skeleton project templates that are provided by the ASCOM Initiative it could have been built for Any CPU and therefore the same DLL would work on either 32-bit or 64-bit versions of Windows and under 64-bit Windows would work with either 32-bit or 64-bit applications. This would eliminate the need to distribute multiple versions of the driver.
Here is a problem with the Sesto Senso driver that you may encounter at some point in the future...What if you need both the 32-bit version of the driver to work with BYE AND the 64-bit version of the driver to work with some other 64-bit application. Unless the two versions of the driver are designed to operate side-by-side, you would have to choose which version is more important to you. This would be inconvenient for you, but addressable by the authors of the driver in a couple of ways. They could either convert the driver to .NET and release it for Any CPU or they could convert the DLL to an EXE and release a 32-bit only version that would work with either a 32-bit or a 64-bit client application.
There are two main benefits for a 64-bit version versus a 32-bit version of an application. One is performance and the other is size. A 32-bit application has a 2 GB memory limit that is eliminated for a 64-bit application. However, I would be extremely surprised if a focuser driver needed either the performance or size increase that a 64-bit version provides.
I hope this helps.
Donc le driver Temma en 32bits ou 10 microns en 32 bits ne marche PAS BIEN avec Prism 64 bits. Je le comprends comme cela, sf erreur de ma part.