1 - Remember serial port (yes its possible, maybe in a future release, code wise its not as easy as it sounds as comports can change)
2 - Calibrate temperature. At present this is unsupported. Depends what sort of calibration support you want, its too complicated to implement the temperature co-efficients for ASCOM. If you just wanted a way to add or subtract an offset value this is easy, but all ASCOM functionality for temperature control and refocusing is difficult as do not have control over the focuser thermal characteristics (which vary from setup to setup)
3 - Send a private email to brown_rb@yahoo.com as the 2nd ASCOM driver is in testing. Only condition is you need to provide feedback
Cheers
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just did a very quick test and so far the beta seems OK but I need some more testing. Would it be possible to enter a offset instead of using a listbox
Last edit: tcpip 2015-01-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did some more testing:
- Application showing wrong version number.136 instead of 138
- Unable to set maximum position. After changing maximum position in the ASCOM driver the arduino still uses the default (10000)
- Unable to connect to the ASCOM driver from multiple applications.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Latest application is v146, about shows v1.4.6.0. Please send screenshot
Unable to set maximum position in ASCOM - correct. ASCOM does not support any call to set MaxSteps. pg23 of the documentation, These settings are saved by the controller and sent to the application/driver on connect(). Entering values into the dialog boxes before connecting are ignored.
Initial Focuser Position
Maximum Steps (MaxSteps)
Note: MaxSteps cannot be greater than 32000. Initial Focuser Position cannot be greater than MaxSteps. Values cannot be negative (less than 0).
Under the section: Initial Setup, I recommend setting the parameters using the Windows Application before using ASCOM. One is unlikely to want to change MaxSteps once the focuser is configured for your system,
Unable to connect from multiple applications - if you mean more then one application at a time, yes, this is correct. Imagine one app telling the focuser to move in whilst the other is telling it to move out? My understanding is that the drivers for focusers are not designed to be multi-app, and there are issues with command sequencing in ASCOM as this is not specified by default and left to the developer. Also its not possible to share a com port as its exclusive, so I am guessing one would need to use a POTH type concept for focusers.
Why do you want to connect from multiple applications?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By way of background
When Focuser Position and MaxSteps was stored in Application Settings (on the local computer) the driver and application let you send these values at connect time to the controller.
When these were changed to be stored in EEPROM of the controller, the ability to set these on connect was removed, they are now set post connect, but maxsteps only from the windows app (as ASCOM does not support setting maxsteps).
What happens now is that the application or ascom driver, on connect, requests these values from the controller. That way we can be assured we are starting with the last known good configuration. It also means that whether using the ascom or windows app that those two important settings are the same.
The pdf document outlines the initial setup of the focuser unit by outlining a procedure to determine all the settings for the focuser. This is done using the windows application. Once the focuser is configured correctly, and positioned so that damage cannot occur when instructed to go to positions 0 or Maxsteps, then one can use the ASCOM driver if desired. Changing Maxsteps once the focuser is configured correctly is probably inadvisable?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wasn't specific enough. I meant ASCOM application showing v136 instead of v138.
Oeps, Yes should have read the documentaion again. Sorry but the confusion came by the ability of adding Maxsteps in the ASCOM driver.
Yes, I mean more then one application at a time. I've made my own VB.net application to log/graph the temperature and focus position (see screenshot). The focus functionalities of Sequence Generator Pro are basic but I'm using it to autofocus. In the past I've used robofocus and it allowed me the connect multiple application to the ASCOM driver.
Thanks for the extensive reply. Hopefully it will be clear for half and hour now so I can give it a try under the stars.
Adding maxsteps in the ascom driver was a legacy thing. Its problematic because one isnt yet connected to the controller and so whatever is in there is meaningless (same for focuserpos) until it connects. Previously it was used for sending these values to the focuser on connect(), but that code was removed some time ago. I had a quick play putting the code back in just now, it works but it then raises some new issues due to the fact that there have been a lot of changes in structure since then and so appears to break some other things (not really but would end up causing a lot of user confusion thinking it doesnt work but it does, just have to obey the rules!)
On the more than one app - I'll let you know. It could take a while though.
Cheers
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At present the ASCOM driver is a client driver model. To support more than one client application I would need to re-implement this as a local server model, and that would be a significant amount of work.
I would have to be honest and say the chances of re-writing the code as a local-server model are slim. The brief look I had today at this reinforces the idea that at present there are not enough hours in the day to look at doing this at present.
However -
One could enable logging and use an application to monitor the log file as all commands such as GP and SP and GZ etc related to focuser position, moves and temperature are written to the debug log. At present this would be the only way to get this info from a different app. One would have to write the app of course.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have implemented a test version using windows sockets, similar to like PHD2, where another client app can connect to the ASCOM driver on an IpAddress of the host and a specific Port, then request the temperature and position (using t and p commands). It appears to work. Have tested it with telnet application. It writes the ipaddress of the host into the ascom trace log (I was using 127.0.0.1 as a loopback but using the actual ipaddress of the host running the ascom driver is better because it then means the client can be running on another computer!)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thought I was smart and tried the Moonlite ASCOM driver but failed. The Moonlite stand alone application works but the ASCOM didn't find the hardware. Seems they build in a protection?
I'm not sure about the idea of windows sockets or use the log file. The client-server model makes ASCOM powerful. But I really appreciate your time and effort for trying to make this work for me: thanks! First I need some cloudless night to give it a go. Maybe this is a non issue.
Last edit: tcpip 2015-02-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the early releases it was 100% compatible with Moonlite.
Over time some changes were added to the protocol to do all sorts of things one cannot do with the moonlite drivers. perhaps somewhere done this chain something was removed (I seem to recall some changes in the startup connect sequence were vital for moonlite ASCOM to work - I'll recheck this but its a low priority as the supplied ASCOM driver works).
To be honest I have not tested it with the Moonlite drivers for several months now.
If I get some time I will test them again and report back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some info re that latest Moonlite DRO focuser.
It seems that the receive timeout is set to 500ms in the latest moonlite driver (previous versions it was 5000ms), so it misses the response from the Arduino because it times out (the response arrives too late). There is no way to speed the Arduino up unless using a capacitor to prevent the reset.
Interestingly the previous driver had the timeout set to 5000ms which was ample time.
Last edit: brownrb 2015-02-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just confirmed operation with the new Moonlite DRO focuser.
I installed the latest DRO focuser software from the moonlite site (did not choose option for second focuser).
I connected the Arduino UNO controller, placed a 47uf capacitor between RST and 5V.
I powered on the Arduino.
I loaded up the myAscomApp and selected the DRO focuser,
as seen below, it connects and operates fine.
The new Moonlite DRO drivers are done using the Local Server ASCOM implementation, but this new release appears a little buggy as you have found. It should by design act as a hub permitting multiple clients but doesn't. Not sure why that is. Its certainly appears to be coded such that it rejects multiple clients in this release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For any issues with the ASCOM driver, please post here
I'm using myFocuserASCOMSetup134 and I'm wondering if it would be possible to add:
- remember serial port
- calibrate temperature
I would like to add a second focuser. Where can I find the second ASCOM driver?
1 - Remember serial port (yes its possible, maybe in a future release, code wise its not as easy as it sounds as comports can change)
2 - Calibrate temperature. At present this is unsupported. Depends what sort of calibration support you want, its too complicated to implement the temperature co-efficients for ASCOM. If you just wanted a way to add or subtract an offset value this is easy, but all ASCOM functionality for temperature control and refocusing is difficult as do not have control over the focuser thermal characteristics (which vary from setup to setup)
3 - Send a private email to brown_rb@yahoo.com as the 2nd ASCOM driver is in testing. Only condition is you need to provide feedback
Cheers
Robert
Versions uploaded today (Windows Application and ASCOM driver) remember the last used serial port.
Before installing new versions, UNINSTALL old version !!!!!
Thanks, I'll try the new versions tomorrow!
The calibration support I want is as simple as add or subtract an offset value and of course this needs to be remembered in the ASCOM driver.
I'll send you a private email about the 2nd ASCOM driver.
Again, thanks for the good work!
Just saw the 2nd driver is already in the file section, ready for download. So I don't have to send a private email. Thanks!
Check out the Beta folder and report back - temperature offset value now available,
Yesterday evening I was able to test 135 and 2nd ASCOM driver. As far as I've tested they work fine.
This evening I'll be able to test the beta and will let you know. wow, you're fast! Thanks.
Thanks for the report back
Robert
Just did a very quick test and so far the beta seems OK but I need some more testing. Would it be possible to enter a offset instead of using a listbox
Last edit: tcpip 2015-01-31
See the beta folder again for your request change
Did some more testing:
- Application showing wrong version number.136 instead of 138
- Unable to set maximum position. After changing maximum position in the ASCOM driver the arduino still uses the default (10000)
- Unable to connect to the ASCOM driver from multiple applications.
Initial Focuser Position
Maximum Steps (MaxSteps)
Note: MaxSteps cannot be greater than 32000. Initial Focuser Position cannot be greater than MaxSteps. Values cannot be negative (less than 0).
Under the section: Initial Setup, I recommend setting the parameters using the Windows Application before using ASCOM. One is unlikely to want to change MaxSteps once the focuser is configured for your system,
Why do you want to connect from multiple applications?
By way of background
When Focuser Position and MaxSteps was stored in Application Settings (on the local computer) the driver and application let you send these values at connect time to the controller.
When these were changed to be stored in EEPROM of the controller, the ability to set these on connect was removed, they are now set post connect, but maxsteps only from the windows app (as ASCOM does not support setting maxsteps).
What happens now is that the application or ascom driver, on connect, requests these values from the controller. That way we can be assured we are starting with the last known good configuration. It also means that whether using the ascom or windows app that those two important settings are the same.
The pdf document outlines the initial setup of the focuser unit by outlining a procedure to determine all the settings for the focuser. This is done using the windows application. Once the focuser is configured correctly, and positioned so that damage cannot occur when instructed to go to positions 0 or Maxsteps, then one can use the ASCOM driver if desired. Changing Maxsteps once the focuser is configured correctly is probably inadvisable?
Thanks for the extensive reply. Hopefully it will be clear for half and hour now so I can give it a try under the stars.
Adding maxsteps in the ascom driver was a legacy thing. Its problematic because one isnt yet connected to the controller and so whatever is in there is meaningless (same for focuserpos) until it connects. Previously it was used for sending these values to the focuser on connect(), but that code was removed some time ago. I had a quick play putting the code back in just now, it works but it then raises some new issues due to the fact that there have been a lot of changes in structure since then and so appears to break some other things (not really but would end up causing a lot of user confusion thinking it doesnt work but it does, just have to obey the rules!)
On the more than one app - I'll let you know. It could take a while though.
Cheers
Robert
At present the ASCOM driver is a client driver model. To support more than one client application I would need to re-implement this as a local server model, and that would be a significant amount of work.
I would have to be honest and say the chances of re-writing the code as a local-server model are slim. The brief look I had today at this reinforces the idea that at present there are not enough hours in the day to look at doing this at present.
However -
One could enable logging and use an application to monitor the log file as all commands such as GP and SP and GZ etc related to focuser position, moves and temperature are written to the debug log. At present this would be the only way to get this info from a different app. One would have to write the app of course.
I have implemented a test version using windows sockets, similar to like PHD2, where another client app can connect to the ASCOM driver on an IpAddress of the host and a specific Port, then request the temperature and position (using t and p commands). It appears to work. Have tested it with telnet application. It writes the ipaddress of the host into the ascom trace log (I was using 127.0.0.1 as a loopback but using the actual ipaddress of the host running the ascom driver is better because it then means the client can be running on another computer!)
Thought I was smart and tried the Moonlite ASCOM driver but failed. The Moonlite stand alone application works but the ASCOM didn't find the hardware. Seems they build in a protection?
I'm not sure about the idea of windows sockets or use the log file. The client-server model makes ASCOM powerful. But I really appreciate your time and effort for trying to make this work for me: thanks! First I need some cloudless night to give it a go. Maybe this is a non issue.
Last edit: tcpip 2015-02-02
In the early releases it was 100% compatible with Moonlite.
Over time some changes were added to the protocol to do all sorts of things one cannot do with the moonlite drivers. perhaps somewhere done this chain something was removed (I seem to recall some changes in the startup connect sequence were vital for moonlite ASCOM to work - I'll recheck this but its a low priority as the supplied ASCOM driver works).
To be honest I have not tested it with the Moonlite drivers for several months now.
If I get some time I will test them again and report back.
Some info re that latest Moonlite DRO focuser.
It seems that the receive timeout is set to 500ms in the latest moonlite driver (previous versions it was 5000ms), so it misses the response from the Arduino because it times out (the response arrives too late). There is no way to speed the Arduino up unless using a capacitor to prevent the reset.
Interestingly the previous driver had the timeout set to 5000ms which was ample time.
Last edit: brownrb 2015-02-04
I have just confirmed operation with the new Moonlite DRO focuser.
I installed the latest DRO focuser software from the moonlite site (did not choose option for second focuser).
I connected the Arduino UNO controller, placed a 47uf capacitor between RST and 5V.
I powered on the Arduino.
I loaded up the myAscomApp and selected the DRO focuser,
as seen below, it connects and operates fine.
I can confirm this too but unfortunately also with the Moonlite ASCOM driver only one application can connect to it.
The new Moonlite DRO drivers are done using the Local Server ASCOM implementation, but this new release appears a little buggy as you have found. It should by design act as a hub permitting multiple clients but doesn't. Not sure why that is. Its certainly appears to be coded such that it rejects multiple clients in this release.