Latest fixes on windows

[kkretzschmar]

Hi Juan, I found some time to test on windows. I used a windows 10 machine as a client communicating to a linux laptop with a running INDI server remotely. Everything works fine! The only issue I found is that the first connect to the remote INDI server took quite a while long. Maybe due to inefficient DNS cache lookup . The DeviceController GUI then did not update properly. But the second connect and further connects then went well.

Workaround: Connect a second time, or use IP addresses instead of host names.

Then while taking some pictures of Mercury transit I took some images with my DSLR and the gphoto driver. Everything worked fine except the server upload modes. The short exposure times were not accepted, the camera behaved as if it would be in bulb mode. I assume a bug on the gphoto driver side here. I'll investigate ...

Last thing to do is to update the documentation, there are outdated pictures from the old interfaces, I can do that.

But I think we are now ready for release! The modules are in a great shape now, thanks for all your effort (quite big, sorry for that ;) ). Interactive and scripting modes are working very well, I wasn't able to bring the prototype that far. I am looking forward for the developments to come (I am already working on the INDI mount module).

Thanks! Klaus

[jconejero]

Hi Klaus,

Super great! So I'm going to write an announcement email and forum post. If you don't mind, we can release a first version in the purest PixInsight style, that is, without documentation ;)

I'll post the announcement here in a while. Something that we should do ASAP is preparing a brief (or not so...) explanation about downloading and installing INDI server and drivers on Linux, Windows and OS X.

[kkretzschmar]

If you don't mind, we can release a first version in the purest PixInsight style, that is, without documentation ;)

;), OK.

Something that we should do ASAP is preparing a brief (or not so...) explanation about >downloading and installing INDI server and drivers on Linux, Windows and OS X.

Yes, I think at least we should refer to the official INDI web site http://www.indilib.org/download.html with the remark that installation of kstars/Ekos is not required.

http://www.indilib.org/download.html

[jconejero]

This is the text that we can send as a massive email to all users. Let me know if you agree, and in such case I can launch the baby right now:

Hi all,

We are excited to announce the release of a new PixInsight module: INDIClient, an open-source, multiplatform INDI client available on FreeBSD, Linux, OS X, and Windows. The new module is now being distributed as an official update for the latest PixInsight 1.8.4 versions.

The INDIClient project has been created by Klaus Kretzschmar, a German software developer and a member of the PixInsight GitHub team. This is undoubtedly one of the most important milestones in the history of PixInsight development. INDIClient opens a door to hardware control support on the PixInsight platform, and you can bet we are going to open this door completely and go in.

Although this initial version includes just a device controller and a CCD/DSLR frame acquisition tool, it is just the beginning. Think of this first release as a functional proof of concept, just to demonstrate what we are working on and how we are doing it. The roadmap for INDIClient development in the short-medium term includes the following tools, by priority order:

• Camera control.
• Mount/telescope control.
• Focuser control and autofocus.
• Autoguiding.

Of course, all of these tools will be, as are the device controller and frame acquisition tools right now, fully scriptable in JavaScript on the PixInsight Core application.

INDIClient is an open-source project available on PixInsight's GitHub repositories:

https://github.com/PixInsight/PCL/tree/master/src/modules/processes/contrib/kkretzschmar/INDIClient

If you are a software developer and would like to contribute, please contact us. If you can't or don't want to contribute with code, but have suggestions or ideas to improve our development, please also let us know. This exciting project can benefit from the collaboration and help of all PixInsight users.

For the latest detailed information on the INDIClient module, see the official announcement thread on PixInsight Forum:

http://pixinsight.com/forum/*insert-post-number*

\ acknowledgements here - not negotiable :) **

The PixInsight Team at Pleiades Astrophoto.

[jconejero]

And I have written also a brief guide to use the module. Not to include it in the announcement email, just on the forum announcement post:

How to Use the INDIClient Module

INDI stands for Instrument Neutral Distributed Interface. It is a protocol to define communication among hardware devices and software frontends. For a general description of INDI, see this document on INDI Project's website:

http://www.indilib.org/about/discover-indi.html

The first step is installing INDI Library on your machine. On Linux and FreeBSD, you can either compile INDI Library from source, or download a precompiled package. See this page for information on download and installation options:

http://www.indilib.org/download.html

It must be pointed out that our INDIClient module is a completely independent solution, which does not require the KStars and Ekos applications.

To compile from source, see this page:

http://www.indilib.org/download/source/category/2-source.html

On OS X, we strongly recommend the excellent INDI Server for OS X application created by CloudMakers:

http://www.cloudmakers.eu/indiserver/

On Windows you should use wINDI, also by CloudMakers:

http://www.cloudmakers.eu/windi/

wINDI is a wrapper for ASCOM drivers, so you'll also need the ASCOM platform in this case:

http://www.ascom-standards.org/

A very interesting option on Windows is installing a virtual Linux machine (for example, using VMware or VirtualBox), where you can install and run an INDI server and communicate with it from PixInsight running natively on Windows, or alternatively, install and run PixInsight directly on the Linux virtual machine.

Irrespective of your operating system, you must have a working INDI server with the required drivers for your devices. The server can be running either locally on your machine, or on a remote system. Typically, you run the INDI server locally on the same machine where you are connecting your devices and running PixInsight.

Once you have downloaded and installed the corresponding update on PixInsight, you'll find two new categories in your Process Explorer window: INDI and Instrumentation. Under both categories you'll find two new tools, namely INDIDeviceController and INDICCDFrame. INDIDeviceController allows you to connect your system to a working INDI server, as well as connecting/disconnecting devices and edit their properties. INDICCDFrame allows you to acquire images using a CCD or DSLR camera for which you have a working INDI driver. We are writing a complete documentation for INDIClient, which should be available very soon, but we think both tools are quite intuitive and their functionality is also quite obvious, so you can start using them right now.

[jconejero]

Please add any information and/or description that you think may be useful for the users. Obviously you have much more practical experience with INDI.

[kkretzschmar]

Great, I'll look into it this evening, currently I am busy ...

2016-05-13 12:24 GMT+02:00 Juan Conejero notifications@github.com:

Please add any information and/or description that you think may be useful for the users. Obviously you have much more practical experience with INDI.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219006890

[jconejero]

OK. Can I release the module, send the email and post basic information on the forum? This way we'll save a lot of time.

[kkretzschmar]

Yes, of course. Go ahead!

2016-05-13 13:39 GMT+02:00 Juan Conejero notifications@github.com:

OK. Can I release the module, send the email and post basic information on the forum? This way we'll save a lot of time.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219020234

[jconejero]

Launching... :)

[vicentperis]

Congratulations to the developers of this project! It's going to be an amazing new stage of PixInsight.

[vicentperis]

Klaus, I just read your comment at PixInsight Forums. I think the best would be to have Andres' tools in PCL. This tools are great and implement some unique features (like the spline distortion correction). I see two ways: contacting Andres to come to the PCL dark side, or writing a port of his scripts to PCL.

[kkretzschmar]

Hi Vicent, yes I know these tools they are indeed excellent. In the early stage of the INDI prototype I wrote a script with the ImageSolver and an early version of the INDI device controller. It worked quite nicely ... but I agree having the solver algortihms available in PCL would be much better

2016-05-13 20:09 GMT+02:00 vicentperis notifications@github.com:

Klaus, I just read your comment at PixInsight Forums. I think the best would be to have Andres' tools in PCL. This tools are great and implement some unique features (like the spline distortion correction). I see two ways: contacting Andres to come to the PCL dark side, or writing a port of his scripts to PCL.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219118124

[vicentperis]

OK, CCDFrame is released. Let's talk about mounts?

I would love to contribute with any idea. But, first I need to know which is the current state of that tool.

[kkretzschmar]

I'm currently porting the current state of dev to the new INDIClient API to make it scriptable from javascript runtime. Then I have to refactor the Interface, dropping the graphics, and rearranging the GUI elements to make it compliant to PI GUI standards.

• The mount controller will have several actions: Parking, Goto, Synch, Moving North/South, East/West
• You will be able to read out the current equatorial and horizontal coordinates,
• Currently, the interface allows to query coordinates from Simbad database, very useful an I'd like to keep that.

2016-05-14 4:46 GMT+02:00 vicentperis notifications@github.com:

OK, CCDFrame is released. Let's talk about mounts?

I would love to contribute with any idea. But, first I need to know which is the current state of that tool.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219196561

[vicentperis]

OK. There are two improvements I would do in the future (maybe not for the first version):

• To have a simple data base of objects to be able to find the coordinates offline. Something basic, without the charting capability. With Messier, Caldwell, NGC/IC, VdB, Sharpless, Barnard, Arp, named and bright stars, and HD stars. I could make a compilation of all those objects in a text file with coordinates, size, type of object and magnitude. It would be simply a catalog like the one in the Celestron on Meade handpad.
• To be able to define the horizon. We can discuss how would be the approach. Maybe reading telescope movements (by moving it with the hand controller), or by specifying it by putting points in a graph.

[kkretzschmar]

To have a simple data base of objects to be able to find the coordinates offline. Yes makes sense.

With Messier, Caldwell, NGC/IC, VdB, Sharpless, Barnard, Arp, named and bright stars, and HD stars. Seems to me a lot of data. Should we use a real database here, e.g. sqlite?

To be able to define the horizon. We can discuss how would be the approach. Not sure whether this is the responsibility of the client or the scope driver. E.g. the indi_eqmod_driver has already rudimentary horizon support (based on horizontal coordinates), but we need that definitely.

2016-05-14 14:55 GMT+02:00 vicentperis notifications@github.com:

OK. There are two improvements I would do in the future (maybe not for the first version):

-

To have a simple data base of objects to be able to find the coordinates offline. Something basic, without the charting capability. With Messier, Caldwell, NGC/IC, VdB, Sharpless, Barnard, Arp, named and bright stars, and HD stars. I could make a compilation of all those objects in a text file with coordinates, size, type of object and magnitude. It would be simply a catalog like the one in the Celestron on Meade handpad.

To be able to define the horizon. We can discuss how would be the approach. Maybe reading telescope movements (by moving it with the hand controller), or by specifying it by putting points in a graph.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219218930

[vicentperis]

In case of using the sqlite, do you still need the object data in a text file to generate the database?

Regarding the horizon definition. My idea is to implement some features by software so they are accesible to every instrument. If we have our own horizon definition, that does not depend on your mount controller. I have also ideas to apply a periodic error correction without depending on the controller.

V.

[kkretzschmar]

In case of using the sqlite, do you still need the object data in a text file to generate the database? I think yes, since the data have to be uploaded once into the db ... but let me check ...

My idea is to implement some features by software so they are accesible to every instrument. If we have our >own horizon definition, that does not depend on your mount controller. Good point.

2016-05-15 14:59 GMT+02:00 vicentperis notifications@github.com:

In case of using the sqlite, do you still need the object data in a text file to generate the database?

Regarding the horizon definition. My idea is to implement some features by software so they are accesible to every instrument. If we have our own horizon definition, that does not depend on your mount controller. I have also ideas to apply a periodic error correction without depending on the controller.

V.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219284446

[jconejero]

Should we use a real database here, e.g. sqlite?

I don't think so. IMO, we have enough resources to manage these data without external dependencies. For simple lists of objects where we want to perform single queries, we can implement a fast search tree structure. Let me know when this is needed, and I'll include an implementation in PCL (I already have it and use it in the core application; it's just a matter of porting it to a more generic class design).

If we need to perform rectangular range search operations (for example, to find all objects in a given region of the sky) or nearest neighbor searches, we can use more efficient data structures, such as quadtrees. The current PCL implementation:

https://github.com/PixInsight/PCL/blob/master/include/pcl/QuadTree.h

works for generic point lists, which can be specialized for this task very easily. I already use QuadTree and KDTree (https://github.com/PixInsight/PCL/blob/master/include/pcl/KDTree.h) in the StarAlignment tool.

[vicentperis]

OK. I'll do a recopilation of the data once I'm back in Spain. I'll include these fields:

• Object name
• RA J2000
• Dec J2000
• Magnitude
• Size
• Object type

I'll generate a CSV file. I would like to include constellation as well, but I think it will be difficult (I don't figure out how to do that right now).

[jconejero]

For the purposes of finding objects by name or by coordinates, I think constellation data are not necessary. Otherwise we could implement a range search based algorithm (using quadtrees) if we have a set of corner coordinates defining constellation boundaries.

[vicentperis]

We already have the NGC2000, Messier and named stars as text files in Andres' script folder. :-)

[vicentperis]

The constellation boundaries are also defined in Andres' scripts. We could use that file as well.

I think, from the user point of view, it could be useful to show some additional data that's needed simply to check that you're pointing at the right object, since we're not including any star map right now. That's why it could be good to include the object type and constellation.

[kkretzschmar]

IMO, we have enough resources to manage these data without external dependencies. Even better!

For simple lists of objects where we want to perform single queries, we can implement a fast search tree structure. Yes, but we should also take into account that the search phrases can contain alias names (orion nebula instead of M42), or different spelling (upper/lower case, spaces, alph taur vs alpha tauri, etc) ... so preproccessing of the query string is necessary. Might be some effort ...

If we need to perform rectangular range search operations (for example, to find all objects in a given region of the sky) or nearest neighbor searches, This is cool, didn't know that we already have such data structures.

2016-05-15 18:41 GMT+02:00 Juan Conejero notifications@github.com:

Should we use a real database here, e.g. sqlite?

I don't think so. IMO, we have enough resources to manage these data without external dependencies. For simple lists of objects where we want to perform single queries, we can implement a fast search tree structure. Let me know when this is needed, and I'll include an implementation in PCL (I already have it and use it in the core application; it's just a matter of porting it to a more generic class design).

If we need to perform rectangular range search operations (for example, to find all objects in a given region of the sky) or nearest neighbor searches, we can use more efficient data structures, such as quadtrees. The current PCL implementation:

https://github.com/PixInsight/PCL/blob/master/include/pcl/QuadTree.h

works for generic point lists, which can be specialized for this task very easily. I already use QuadTree and KDTree ( https://github.com/PixInsight/PCL/blob/master/include/pcl/KDTree.h) in the StarAlignment tool.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219296371

[kkretzschmar]

Object name As mentioned in my previous thread, imo we also need to support alias names.

2016-05-15 18:53 GMT+02:00 vicentperis notifications@github.com:

OK. I'll do a recopilation of the data once I'm back in Spain. I'll include these fields:

• Object name
• RA J2000
• Dec J2000
• Magnitude
• Size
• Object type

I'll generate a CSV file. I would like to include constellation as well, but I think it will be difficult (I don't figure out how to do that right now).

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219297041

[kkretzschmar]

Btw, our anouncement made it's way through several forums (I've seen a Youtube video soon after the release). Overall feedback is very positive, most of them want to have a kind of data aquisition pipelining features, e.g. automatic aquisition of frame series for different filter settings, or stacking not in batch but online mode, i.e. stacking immediately when a new frame was created.

I also have seen successful trials on all platforms and different devices😀...

Finally, I am happy that we also get support from the INDI people, especially Jasem, who is the main driver of INDI and Kstars/Ekos development.

2016-05-15 21:56 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:

Object name As mentioned in my previous thread, imo we also need to support alias names.

2016-05-15 18:53 GMT+02:00 vicentperis notifications@github.com:

OK. I'll do a recopilation of the data once I'm back in Spain. I'll include these fields:

• Object name
• RA J2000
• Dec J2000
• Magnitude
• Size
• Object type

I'll generate a CSV file. I would like to include constellation as well, but I think it will be difficult (I don't figure out how to do that right now).

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219297041

[kkretzschmar]

Hi Juan, due to the crashes on OSX which some users have reported. I am wondering why We don't get stack traces from the users. Is it switched off by default? Thanks Klaus

2016-05-15 22:09 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:

Btw, our anouncement made it's way through several forums (I've seen a Youtube video soon after the release). Overall feedback is very positive, most of them want to have a kind of data aquisition pipelining features, e.g. automatic aquisition of frame series for different filter settings, or stacking not in batch but online mode, i.e. stacking immediately when a new frame was created.

I also have seen successful trials on all platforms and different devices 😀...

Finally, I am happy that we also get support from the INDI people, especially Jasem, who is the main driver of INDI and Kstars/Ekos development.

2016-05-15 21:56 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com :

Object name As mentioned in my previous thread, imo we also need to support alias names.

2016-05-15 18:53 GMT+02:00 vicentperis notifications@github.com:

OK. I'll do a recopilation of the data once I'm back in Spain. I'll include these fields:

• Object name
• RA J2000
• Dec J2000
• Magnitude
• Size
• Object type

I'll generate a CSV file. I would like to include constellation as well, but I think it will be difficult (I don't figure out how to do that right now).

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219297041

[jconejero]

Hi Klaus,

If you refer to the PixInsight Core application, there are no valid/significant crash reports on any platforms with the current version.

If you refer to this one: http://pixinsight.com/forum/index.php?topic=9857.0 it is irreproducible, and to be more precise, it does not make any sense either. Since last year, I no longer consider bug reports that cannot be reproduced and/or are reasonably documented and justified. Otherwise I'd be in a psychiatric institution :)

Seriously, PixInsight is a very complex platform, especially since version 1.8.4. The number of possibly wrong scenarios and potential conflicts is immense, especially on Windows. If a bug can be reproduced or described in reasonably understandable terms, I normally can fix it very quickly. Otherwise crash reports are of no help in a 99% of the practical situations.

That said, I'll enable stack traces in the next official release of INDIClient, which we can publish very soon if you want, for example with the bug fix I've just pushed today, and a few other glitches I've seen.

[jconejero]

our anouncement made it's way through several forums

I told you it was going to be an earthquake :) Yes, this project has been received very positively in general. Man, you've started something big! ;)

[kkretzschmar]

If you refer to the PixInsight Core application, there are no valid/significant crash reports on any platforms with >the current version. No I refer to this one

http://pixinsight.com/forum/index.php?topic=9852.msg62448#msg62448

PI itself is very stable, never seen big problems with it.

Otherwise crash reports are of no help in a 99% of the practical situations. I think especially with sporadic crashes it can help. My current problem is that I don't have an Mac to reproduce those crashes, maybe I can try with a VM box.

That said, I'll enable stack traces in the next official release of INDIClient, which we can publish very soon if you >want, for example with the bug fix I've just pushed today, and a few other glitches I've seen.

Yes, let's give it a try. I have a suspicion that it has to do with the DNS resolution or connect function on mac. I am wondering if QT is providing network APIs which are OS independent and more stable...

2016-05-16 11:14 GMT+02:00 Juan Conejero notifications@github.com:

Hi Klaus,

If you refer to the PixInsight Core application, there are no valid/significant crash reports on any platforms with the current version.

If you refer to this one: http://pixinsight.com/forum/index.php?topic=9857.0 it is irreproducible, and to be more precise, it does not make any sense either. Since last year, I no longer consider bug reports that cannot be reproduced and/or are reasonably documented and justified. Otherwise I'd be in a psychiatric institution :)

Seriously, PixInsight is a very complex platform, especially since version 1.8.4. The number of possibly wrong scenarios and potential conflicts is immense, especially on Windows. If a bug can be reproduced or described in reasonably understandable terms, I normally can fix it very quickly. Otherwise crash reports are of no help in a 99% of the practical situations.

That said, I'll enable stack traces in the next official release of INDIClient, which we can publish very soon if you want, for example with the bug fix I've just pushed today, and a few other glitches I've seen.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219382729

[kkretzschmar]

Man, you've started something big! ;) Wasn't aware of this ;)

2016-05-16 11:20 GMT+02:00 Juan Conejero notifications@github.com:

our anouncement made it's way through several forums

I told you it was going to be an earthquake :) Yes, this project has been received very positively in general. Man, you've started something big! ;)

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219383818

[jconejero]

I have a suspicion that it has to do with the DNS resolution or connect function on mac.

That's what I think.

I am wondering if QT is providing network APIs which are OS independent and more stable...

It does. In the core application, however, I use cURL because it is rock-solid and much easier to use and maintain (for me at least) with a remarkably clean API. We already have the NetworkTransfer class in PCL:

https://github.com/PixInsight/PCL/blob/master/include/pcl/NetworkTransfer.h

It should work IMO. I can extend it as necessary otherwise.

[jconejero]

Correction: No, NetworkTransfer won't work as it is now, mainly because it implements synchronous data transfers, which is not what we need.

BaseClientImpl.cpp uses standard UNIX sockets (Winsock on Windows, which is essentially the same with peculiarities). It should work reliably. However, the code is ugly and we should rewrite it ASAP, IMO.

[kkretzschmar]

BaseClientImpl.cpp uses standard UNIX sockets (Winsock on Windows, which is essentially the same with >peculiarities). It should work reliably. However, the code is ugly and we should rewrite it ASAP, IMO. OK, it uses deprecated gethostbyname API, this should be repaced.

2016-05-16 12:51 GMT+02:00 Juan Conejero notifications@github.com:

Correction: No, NetworkTransfer won't work as it is now, mainly because it implements synchronous data transfers, which is not what we need.

BaseClientImpl.cpp uses standard UNIX sockets (Winsock on Windows, which is essentially the same with peculiarities). It should work reliably. However, the code is ugly and we should rewrite it ASAP, IMO.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219398908

[jconejero]

it uses deprecated gethostbyname API, this should be repaced.

Of course. It should use getaddrinfo() instead (it already is using it for Windows).

[kkretzschmar]

I just found out what the reason for the reported problem

http://pixinsight.com/forum/index.php?topic=9852.msg62517#msg62517

is. The CCD upload feature was introduced later and there are still CCD device drivers out there which do not have this feature. So we need to be downward compatible with these old drivers, i.e. we should send the image to the client even if the driver does not support "UPLOAD_MODE". I think the fix is very simple

In AbstractINDICCDFrameExecution::Perfom() we only have to initialize

bool serverSendsImage = true;

and if "UPLOAD_MODE", "UPLOAD_LOCAL" is set to "ON"

set serverSendsImage = false;

2016-05-16 14:57 GMT+02:00 Juan Conejero notifications@github.com:

it uses deprecated gethostbyname API, this should be repaced.

Of course. It should use getaddrinfo() instead (it already is using it for Windows).

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219418559

[jconejero]

OK, understood. I'm going to implement this change now.

[kkretzschmar]

Great, thanks!

2016-05-16 15:15 GMT+02:00 Juan Conejero notifications@github.com:

OK, understood. I'm going to implement this change now.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219421905

[jconejero]

I assume that serverKeepsImage is not affected by this issue, right?

[kkretzschmar]

No, the old drivers do not have the possibility to save images on the INDI server host. So the default serverKeepsImage = false is correct.

2016-05-16 15:22 GMT+02:00 Juan Conejero notifications@github.com:

I assume that serverKeepsImage is not affected by this issue, right?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219423271

[kkretzschmar]

I mean yes, your are right, the old drivers do not have the possibility to save images on the INDI server host. So the default serverKeepsImage = false is correct. ;)

2016-05-16 15:28 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:

No, the old drivers do not have the possibility to save images on the INDI server host. So the default serverKeepsImage = false is correct.

2016-05-16 15:22 GMT+02:00 Juan Conejero notifications@github.com:

I assume that serverKeepsImage is not affected by this issue, right?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219423271

[jconejero]

Fixed: https://github.com/PixInsight/PCL/commit/2f25f6bc3ce0b6648ebf1dc73681b753f65617b2

[kkretzschmar]

Hi Juan, I've talked to the cloudmaker developer, he will implement the UPLOAD_MODE feature for wINDI devices next week.

I

2016-05-16 15:36 GMT+02:00 Juan Conejero notifications@github.com:

Fixed: 2f25f6b https://github.com/PixInsight/PCL/commit/2f25f6bc3ce0b6648ebf1dc73681b753f65617b2

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219426231

[kkretzschmar]

Hi, short update from my side

I'm currently porting the current state of dev to the new INDIClient API to make it scriptable from javascript Is done. The scripting interface will have commands for Unpark, Park, Goto, and Synch. Move commands does not make sense in the scripting interface since these commands are time dependent, e.g. the telescope moves as long as a button is pressed. But there is no button in automatic scripting ...

I have written several javascript tests and it is working.

Thanks to Juan for the refactoring of the INDIClient with respect to Thread synchronisation, it works perfectly ! I admit that I got stuck with synch issues when I did my first trial with respect to designing a scriptable mount process.

Next step will be the refactoring and enhancement of the INDIMount GUI.

Two questions:

• I think the users will come with the requirement for switching to a "screen night modus", i.e. a modus with darker system colors (e.g. black background and red foreground colors). Is this possible?
• I would appreciate if we would have dedicated private discussion threads for the different INDI features (private means visible only for all github team members ). I am wondering whether github issues could be the right format for that ...

Klaus

2016-05-14 9:18 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:

I'm currently porting the current state of dev to the new INDIClient API to make it scriptable from javascript runtime. Then I have to refactor the Interface, dropping the graphics, and rearranging the GUI elements to make it compliant to PI GUI standards.

• The mount controller will have several actions: Parking, Goto, Synch, Moving North/South, East/West
• You will be able to read out the current equatorial and horizontal coordinates,
• Currently, the interface allows to query coordinates from Simbad database, very useful an I'd like to keep that.

2016-05-14 4:46 GMT+02:00 vicentperis notifications@github.com:

OK, CCDFrame is released. Let's talk about mounts?

I would love to contribute with any idea. But, first I need to know which is the current state of that tool.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PixInsight/PCL/pull/26#issuecomment-219196561