I was getting my fosucer assembled and facing a issue with adding the temperature probe and automatic temperature compensation. Whenever I have activated (and installed) the temperature probe and the ASCOM driver issues setting :230# or :231# to the focuser, the connection gets closed on a time-out, whether it is set to 5 or 30 seconds.
Driver Access log:
08:47:26.205 Temperature Get GET Temperature - .NET
08:47:26.228 Temperature Get 21,5
08:47:26.247 Connected Get Issuing Connected command
08:47:26.248
08:47:26.248 Connected Get GET Connected - .NET
08:47:26.249 Connected Get True
08:47:26.250 Connected Get Issuing Connected command
08:47:26.250
08:47:26.251 Connected Get GET Connected - .NET
08:47:26.252 Connected Get True
08:48:12.360
08:48:12.360 TempCompAvailable Get GET TempCompAvailable - .NET
08:48:12.378 TempCompAvailable Get True
08:48:12.381
08:48:12.381 TempComp Get GET TempComp - .NET
08:48:12.398 TempComp Get False
08:48:56.421
08:48:56.421 TempCompAvailable Get GET TempCompAvailable - .NET
08:48:56.438 TempCompAvailable Get True
08:48:56.438
08:48:56.438 TempComp Set SET TempComp - .NET
08:48:56.438 TempComp Set True
08:49:01.546
08:49:01.546 TempComp Set SET TempComp - .NET
08:49:01.547 TempComp Set True
Driver log:
08:48:12.361 TCAvailable Get Query controller for tempcompavailable status
08:48:12.361 IsConnected Get True
08:48:12.361 Connected Get True
08:48:12.364 comms() Clearing serial port buffers: OK
08:48:12.364 comms() send: :25#
08:48:12.366 comms() get response
08:48:12.377 comms() rec'd: A1#
08:48:12.377 TCAvailable Get focuser reply = 1
08:48:12.381 TempComp Get Query controller for TempComp state
08:48:12.382 IsConnected Get True
08:48:12.382 Connected Get True
08:48:12.384 comms() Clearing serial port buffers: OK
08:48:12.385 comms() send: :24#
08:48:12.387 comms() get response
08:48:12.397 comms() rec'd: 10#
08:48:12.398 TempComp Get focuser reply = 0
08:48:56.421 TCAvailable Get Query controller for tempcompavailable status
08:48:56.423 IsConnected Get True
08:48:56.424 Connected Get True
08:48:56.426 comms() Clearing serial port buffers: OK
08:48:56.426 comms() send: :25#
08:48:56.429 comms() get response
08:48:56.437 comms() rec'd: A1#
08:48:56.437 TCAvailable Get focuser reply = 1
08:48:56.438 TempComp Set Change state to: True
08:48:56.511 IsConnected Get True
08:48:56.512 Connected Get True
08:48:56.515 comms() Clearing serial port buffers: OK
08:48:56.515 comms() send: :231#
08:48:56.518 comms() get response
08:49:01.526 comms() read exception: System.Runtime.InteropServices.COMException (0x80040402): Timed out waiting for received data[0D][0A] bei ASCOM.Utilities.Serial.ReceiveTerminated(String Terminator) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\Serial.vb:Zeile 1204.[0D][0A] bei ASCOM.myFocuser2ASCOM.Focuser.comms(String cmd, Boolean answer)
08:49:01.531 log_error: read exception: System.Runtime.InteropServices.COMException (0x80040402): Timed out waiting for received data[0D][0A] bei ASCOM.Utilities.Serial.ReceiveTerminated(String Terminator) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\Serial.vb:Zeile 1204.[0D][0A] bei ASCOM.myFocuser2ASCOM.Focuser.comms(String cmd, Boolean answer)
08:49:01.532 TempComp Set fail: Send failed
08:49:01.547 TempComp Set Change state to: True
08:49:01.642 IsConnected Get False
08:49:01.642 Connected Get False
08:49:01.643 comms() err: not connected
08:49:01.643 log_error: not connected
The temperature probe seems to work without issues. The temperature is displayed correctly on the OLED display. Also, I can query the temperature
The temperature is still correctly reported and updated after, e.g. changes if I warm it up with my finger.
The focuser still moves with push button.
I tried it with an Arduino UNO and a Nano (CH340G) and different USB ports.
I used myFP2_ULN2003_324 and myFP2_L293D_324 as well as myFP2_ULN2003_321 firmware.
I had re-installed ASCOM Platform and driver and updated the firmware and all libraries from here.
The disconnect happens whether I issue the command via MaximDL or the MyFP ASCOM tool.
setting the serial time-out to 30 seconds does not help.
I tired various driver settings with TC on/off, reset on start yes/no, etc.
If the temperature probe is configured and installed, it always disconnects on :230# or :231#.
Anyone any idea where the issue might be? Is there anything that needs to be configured in addition to #define TEMPERATUREPROBE 1 to get automatic temperature compensation activated?
Greetings,
Nikolas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Nikolas
Thank you for reporting an issue. There indeed is a problem. You detailed message was appreciated and helped pinpoint the quickly quickly.
I have created an updated ASCOM driver v286. I also updated the ASCOM Test Application to v1320
You may have to use control panel to remove the ASCOM driver first. I did not encounter an issue installing the driver without using Control Panel first.
I have no had time to do the ASCOM1 driver (it will have to wait till tommorrow. But these should resolve the issue for you. The link details are
I was thrilled to see this timely thread since I have been encountering the identical problem. Unfortunately, removing the old driver (carefully, manually) and installing the newly posted one did not fix it for me. The updated ASCOM myfp2 focuser test client appears to work, but does not actually move the motor (no sign of the arduino serial lights blinking) or update temperatures. Same symptoms in the logs - turn on temperature compensation,... serial disconnects. I've attached the client log and the ASCOM device hub log. Hopefully it's just me doing something stupid.
Hi Mike
The log shows that you are not using the latest ascom driver v286
The log shows
Driver Info = myFocuserPro2ASCOM driver by R Brown.
Driver Version = 2.8.4
Please remove the old version first. If it is no longer available in control panel to uninstall, then
This is not a general thing I encourage user's to do because an ASCOM driver also makes changes to the registry, but if all else fails
look in
C:\Program Files (x86)\Common Files\ASCOM\Focuser
and remove any file that looks like a myfp2 or myfocuserpro2
Thanks Robert (both for the quick and useful response and, long-term, for the development and support of this terrific tool). As you suggested, I found that I had a stickly ASCOM...dll file from the previous install that wasn't getting cleared out by the latest install. I'm now officially at 2.8.6 and your ASCOM test application works. It would be nice if it updated the temperature and focus position fields while it is in temperature compensation mode and output those updates to the log. As it stands, I can still use the "GET" buttons to see that it is working.
Above I think you mentioned that an ASCOM1 driver is forthcoming. Right now, if you turn on TC via the ASCOM device hub it renders the hub unresponsive and if you uncheck TC (which it will let you do) it hangs up the device hub so badly that you have to kill it from the task manager. Let me know if I can provide any useful diagnostics.
Thanks,
Mike.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mike
I am just going through these messages to ensure that everything is covered/explained
**It would be nice if it updated the temperature and focus position fields while it is in temperature compensation mode and output those updates to the log. As it stands, I can still use the "GET" buttons to see that it is working. *
Clarification:
The way that ASCOM works is a query - response. In other words the driver queries and the controller responds. Not the other way around.
there is no mechanism for the controller to send anything to the driver saying hey, I got this now, so take notice. That cannot happen. The controller can only send as a result of a request.
What most "app" developers do is decide to query the controller be making the app send requests to the ascom driver all the time, like get temp, get position, get max steps, get tc being the main ones, every second. Some "apps" go overboard in this, I investigated one "app" that at some points on their code was sending the same requests for the same data around 5ms apart. I do not understand the logic behind that let alone the necessity to do that.
One good thing about INDI is that the user can control this "polling" by letting the user decide how often that occurs.
regards
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mike
The driver is v2. Under v2 interface from ascom, move while in temp comp mode is forbidden, so the driver ignores a move request when temp comp is ON.
For the ASCOM Trace log if enabled,
A request for temperature is always logged, even if Temp Comp is ON.
Above I think you mentioned that an ASCOM1 driver is forthcoming.
Yes, just uploaded
Right now, if you turn on TC via the ASCOM device hub it renders the hub unresponsive and if you uncheck TC (which it will let you do) it hangs up the device hub so badly that you have to kill it from the task manager. Let me know if I can provide any useful diagnostics.
Sorry, ASCOM device hub?
Regards
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. I'll track down the ASCOM Trace log. In the meantime, here's a snapshot of the ASCOM device hub. It's a low level interface to configure and operate various ASCOM devices (telescope, focuser, etc.). Your driver works fine in the device hub as long as TC is not enabled, but hangs up once TC is turned on. Similarly, I've been running your driver with the Sharpcap focuser interface for a while with no problem, but the minute I check the TC box everything stops and unchecking, disconnecting, reconnecting doesn't restore basic manual operation of the focuser. All that said, your own test app works fine and is a practical fallback.
A followup... Both in the Device Hub and in Sharpcap checking the TC box will put the focuser in TC mode (the motor moves when the DS18B20 gets heated or cooled). Neither application shows updates to the motor position or temperature when in TC mode or after exiting TC mode. All manageable. The one problem is that when the TC mode box is unchecked neither application returns to hands-on motor control with temperature and motor position updated. In Sharpcap, after returning from TC mode, you can initiate a motor move and the motor responds, but the focuser controls do not return from the "moving" state with the buttons and motor position remaining greyed out. You can hit the "Stop" button in the Sharpcap focuser window and get back into a situation where you can move the motor once again (once again it remains in the moving state after it completes the move). In this situation, even though the motor does move, the motor position value does not update. I'll see if I can get some useful information posted from the Sharpcap logging.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Neither application shows updates to the motor position or temperature when in TC mode or after exiting TC mode.
I can confirm that the firmware does indeed change the position when in TC mode.
That can be easily tested by using the windows app, enable TC, cool down the probe using an ice cube, then use a get position.
Of course that assumes that the firmware was generated with temp probe enabled, and the temp probe was found when the controller booted. And the temperature coefficent value was set correctly,
I like to use the Arduino IDE and serial monitor to do these tests
I set the speed to 9600 with no Line Ending
Then looking at the protocol document, typing data into the field at the top, then clicking the send button
:00# Pxxxx# Get current focuser position
so typing :00# will return the position
then
:23x# None Set the temperature compensation ON (1) or OFF (0)
typing :231# and click send
will turn on temperature compensation.
Checking that TC is on,
:24# 1x# Get state of Temperature Compensation, 0=disabled, 1=enabled
I can type :24# and click send
which should return 11x (first char is a code type, 2nd char is the value)
then cool the probe a bit, wait about 20s
and then ask for the position again
:00# and click send
should return Pxxxxx# where P is the code for position and xxxxx is the focuser position
regards
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mike
I have never used ASCOM Device Hub, so cannot comment on what it does or does not do.
TC issues date back a couple of years now. It happened that a major app decided to ignore TC rules in v2 interface and just move the focuser anyway. Of course this led to a lot of grief with focusers that were implented using v2 interface.
rather than asking the "app" developers to adhere to the interface rules, the group made a decision to allow that behaviour, and then issued a v3 interface, asking of course that apps should check for v2 and deal with it.
What I can say is I did not agree with that and still dont. The only outcome was that the app developers just went on coding the same way they had been doing.
You may find that some "apps" still do not obey the v2 interface rules, and thus will hang when tc is on.
All that aside, if I get the time there are some things I might be able to do. Find my email address in the docs/firmware and send me a mail if you want to do a little testing with the ascom driver.
I will also need to know the name of the firmware file you used to program the controller.
regards
Robert
Last edit: brownrb 2023-03-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mike
I have spend most of the day and night on this, using the Device Hub, and now have a working solution.
As I suspected the request for IsMoving immediately following a Move command from the client fails, because the Arduino cannot respond that fast.
This involves both a Firmware update, ASCOM driver update. Hence I would need to know what firmware filename you have so I can make the modifications to that.
I also updated the Interface version of the focuser driver to V3
Regards
Robert
Last edit: brownrb 2023-03-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I was getting my fosucer assembled and facing a issue with adding the temperature probe and automatic temperature compensation. Whenever I have activated (and installed) the temperature probe and the ASCOM driver issues setting :230# or :231# to the focuser, the connection gets closed on a time-out, whether it is set to 5 or 30 seconds.
Driver Access log:
08:47:26.205 Temperature Get GET Temperature - .NET
08:47:26.228 Temperature Get 21,5
08:47:26.247 Connected Get Issuing Connected command
08:47:26.248
08:47:26.248 Connected Get GET Connected - .NET
08:47:26.249 Connected Get True
08:47:26.250 Connected Get Issuing Connected command
08:47:26.250
08:47:26.251 Connected Get GET Connected - .NET
08:47:26.252 Connected Get True
08:48:12.360
08:48:12.360 TempCompAvailable Get GET TempCompAvailable - .NET
08:48:12.378 TempCompAvailable Get True
08:48:12.381
08:48:12.381 TempComp Get GET TempComp - .NET
08:48:12.398 TempComp Get False
08:48:56.421
08:48:56.421 TempCompAvailable Get GET TempCompAvailable - .NET
08:48:56.438 TempCompAvailable Get True
08:48:56.438
08:48:56.438 TempComp Set SET TempComp - .NET
08:48:56.438 TempComp Set True
08:49:01.546
08:49:01.546 TempComp Set SET TempComp - .NET
08:49:01.547 TempComp Set True
Driver log:
08:48:12.361 TCAvailable Get Query controller for tempcompavailable status
08:48:12.361 IsConnected Get True
08:48:12.361 Connected Get True
08:48:12.364 comms() Clearing serial port buffers: OK
08:48:12.364 comms() send: :25#
08:48:12.366 comms() get response
08:48:12.377 comms() rec'd: A1#
08:48:12.377 TCAvailable Get focuser reply = 1
08:48:12.381 TempComp Get Query controller for TempComp state
08:48:12.382 IsConnected Get True
08:48:12.382 Connected Get True
08:48:12.384 comms() Clearing serial port buffers: OK
08:48:12.385 comms() send: :24#
08:48:12.387 comms() get response
08:48:12.397 comms() rec'd: 10#
08:48:12.398 TempComp Get focuser reply = 0
08:48:56.421 TCAvailable Get Query controller for tempcompavailable status
08:48:56.423 IsConnected Get True
08:48:56.424 Connected Get True
08:48:56.426 comms() Clearing serial port buffers: OK
08:48:56.426 comms() send: :25#
08:48:56.429 comms() get response
08:48:56.437 comms() rec'd: A1#
08:48:56.437 TCAvailable Get focuser reply = 1
08:48:56.438 TempComp Set Change state to: True
08:48:56.511 IsConnected Get True
08:48:56.512 Connected Get True
08:48:56.515 comms() Clearing serial port buffers: OK
08:48:56.515 comms() send: :231#
08:48:56.518 comms() get response
08:49:01.526 comms() read exception: System.Runtime.InteropServices.COMException (0x80040402): Timed out waiting for received data[0D][0A] bei ASCOM.Utilities.Serial.ReceiveTerminated(String Terminator) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\Serial.vb:Zeile 1204.[0D][0A] bei ASCOM.myFocuser2ASCOM.Focuser.comms(String cmd, Boolean answer)
08:49:01.531 log_error: read exception: System.Runtime.InteropServices.COMException (0x80040402): Timed out waiting for received data[0D][0A] bei ASCOM.Utilities.Serial.ReceiveTerminated(String Terminator) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\Serial.vb:Zeile 1204.[0D][0A] bei ASCOM.myFocuser2ASCOM.Focuser.comms(String cmd, Boolean answer)
08:49:01.532 TempComp Set fail: Send failed
08:49:01.547 TempComp Set Change state to: True
08:49:01.642 IsConnected Get False
08:49:01.642 Connected Get False
08:49:01.643 comms() err: not connected
08:49:01.643 log_error: not connected
ASCOM Serial log:
08:48:56.427 Transmit Start
08:48:56.427 Transmit 1 Entered GetNextCount
08:48:56.427 Transmit 1 Got CallCountMutex
08:48:56.427 Transmit 26 1 Released CallCountMutex
08:48:56.427 TransmitWorker 26 9 > :25#
08:48:56.427 TransmitWorker 26 9 Entered GetSemaphore
08:48:56.427 TransmitWorker 26 9 Got Semaphore OK
08:48:56.428 TransmitWorker 26 9 Completed
08:48:56.428 TransmitWorker 26 9 Entered ReleaseSemaphore 9
08:48:56.428 TransmitWorker 26 9 Semaphore released OK
08:48:56.428 WaitForThread 26 1 Completed WaitForSingleObject OK, Command: Transmit Elapsed: 1,1176
08:48:56.428 Transmit Completed: True, Duration: 1,7
08:48:56.429 ReceiveTerminated Start
08:48:56.429 ReceiveTerminated 1 Entered GetNextCount
08:48:56.429 ReceiveTerminated 1 Got CallCountMutex
08:48:56.429 ReceiveTerminated 27 1 Released CallCountMutex
08:48:56.429 ReceiveTerminatedWorker 27 8 Start - terminator: "#"
08:48:56.430 ReceiveTerminatedWorker 27 8 Entered GetSemaphore
08:48:56.430 ReceiveTerminatedWorker 27 8 Got Semaphore OK
08:48:56.430 ReceiveTerminatedWorker 27 8 Entered ReadChar: False
08:48:56.436 ReceiveTerminatedWorker 27 8 ReadChar returning result - "A"
08:48:56.436 ReceiveTerminatedWorker 27 8 Entered ReadChar: False
08:48:56.436 ReceiveTerminatedWorker 27 8 ReadChar returning result - "1"
08:48:56.436 ReceiveTerminatedWorker 27 8 Entered ReadChar: False
08:48:56.436 ReceiveTerminatedWorker 27 8 ReadChar returning result - "#"
08:48:56.436 ReceiveTerminatedWorker 27 8 < A1#
08:48:56.436 ReceiveTerminatedWorker 27 8 Entered ReleaseSemaphore 8
08:48:56.436 ReceiveTerminatedWorker 27 8 Semaphore released OK
08:48:56.437 WaitForThread 27 1 Completed WaitForSingleObject OK, Command: ReceiveTerminated Elapsed: 7,2191
08:48:56.437 ReceiveTerminated Completed: True, Duration: 7,7
08:48:56.513 ClearBuffers Start
08:48:56.513 ClearBuffers 1 Entered GetNextCount
08:48:56.513 ClearBuffers 1 Got CallCountMutex
08:48:56.513 ClearBuffers 28 1 Released CallCountMutex
08:48:56.514 ClearBuffersWorker 28 9 9Start
08:48:56.514 ClearBuffersWorker 28 9 Entered GetSemaphore
08:48:56.514 ClearBuffersWorker 28 9 Got Semaphore OK
08:48:56.514 ClearBuffersWorker 28 9 Completed
08:48:56.514 ClearBuffersWorker 28 9 Entered ReleaseSemaphore 9
08:48:56.514 ClearBuffersWorker 28 9 Semaphore released OK
08:48:56.514 WaitForThread 28 1 Completed WaitForSingleObject OK, Command: ClearBuffers Elapsed: 0,7775
08:48:56.514 ClearBuffers Completed: True, Duration: 1,4
08:48:56.516 Transmit Start
08:48:56.516 Transmit 1 Entered GetNextCount
08:48:56.516 Transmit 1 Got CallCountMutex
08:48:56.516 Transmit 29 1 Released CallCountMutex
08:48:56.516 TransmitWorker 29 8 > :231#
08:48:56.517 TransmitWorker 29 8 Entered GetSemaphore
08:48:56.517 TransmitWorker 29 8 Got Semaphore OK
08:48:56.517 TransmitWorker 29 8 Completed
08:48:56.517 TransmitWorker 29 8 Entered ReleaseSemaphore 8
08:48:56.517 TransmitWorker 29 8 Semaphore released OK
08:48:56.518 WaitForThread 29 1 Completed WaitForSingleObject OK, Command: Transmit Elapsed: 1,1592
08:48:56.518 Transmit Completed: True, Duration: 2,0
08:48:56.519 ReceiveTerminated Start
08:48:56.519 ReceiveTerminated 1 Entered GetNextCount
08:48:56.519 ReceiveTerminated 1 Got CallCountMutex
08:48:56.519 ReceiveTerminated 30 1 Released CallCountMutex
08:48:56.519 ReceiveTerminatedWorker 30 9 Start - terminator: "#"
08:48:56.519 ReceiveTerminatedWorker 30 9 Entered GetSemaphore
08:48:56.519 ReceiveTerminatedWorker 30 9 Got Semaphore OK
08:48:56.520 ReceiveTerminatedWorker 30 9 Entered ReadChar: False
08:49:01.522 ReceiveTerminatedWorker 30 9 EXCEPTION: System.TimeoutException: Timeout f[FC]r den Vorgang wurde [FC]berschritten.[0D][0A] bei System.IO.Ports.SerialStream.ReadByte(Int32 timeout)[0D][0A] bei ASCOM.Utilities.Serial.ReadChar(String p_Caller, Int64 TransactionID) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\Serial.vb:Zeile 1795.[0D][0A] bei ASCOM.Utilities.Serial.ReceiveTerminatedWorker(Object TDataObject) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\Serial.vb:Zeile 1226.
08:49:01.523 ReceiveTerminatedWorker 30 9 Entered ReleaseSemaphore 9
08:49:01.524 ReceiveTerminatedWorker 30 9 Semaphore released OK
08:49:01.524 ReceiveTerminatedWorker 30 9 Exception: System.Runtime.InteropServices.COMException (0x80040402): Timed out waiting for received data[0D][0A] bei ASCOM.Utilities.Serial.ReceiveTerminatedWorker(Object TDataObject) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\Serial.vb:Zeile 1241.
08:49:01.525 WaitForThread 30 1 Completed WaitForSingleObject OK, Command: ReceiveTerminated Elapsed: 5005,2627
08:49:01.525 ReceiveTerminated Completed: True, Duration: 5006,2
08:49:01.525 ReceiveTerminated System.Runtime.InteropServices.COMException (0x80040402): Timed out waiting for received data[0D][0A] bei ASCOM.Utilities.Serial.ReceiveTerminated(String Terminator) in C:\ASCOM Build\Export\ASCOM.Utilities\ASCOM.Utilities\Serial.vb:Zeile 1195.
08:49:01.533 Set Connected False
08:49:01.533 Set Connected 1 Entered GetNextCount
08:49:01.533 Set Connected 1 Got CallCountMutex
08:49:01.533 Set Connected 31 1 Released CallCountMutex
08:49:01.533 ConnectedWorker 31 11 Connected: False
08:49:01.534 ConnectedWorker 31 11 Cleared buffers
08:49:01.541 ConnectedWorker 31 11 Closed port
08:49:01.541 ConnectedWorker 31 11 Port disposed OK
08:49:01.541 WaitForThread 31 1 Completed WaitForSingleObject OK, Command: Connected Elapsed: 7,8276
08:49:01.541 Set Connected Completed: True, Duration: 9,3
08:49:01.645 Set Connected False
Afterwards, the serial connection is stopped.
If the temperature probe is configured and installed, it always disconnects on :230# or :231#.
Anyone any idea where the issue might be? Is there anything that needs to be configured in addition to #define TEMPERATUREPROBE 1 to get automatic temperature compensation activated?
Greetings,
Nikolas
Hi Nikolas
What version of the ASCOM driver are you using?
regards
Robert
Hi Robert,
the latest, myFP2ASCOM 284.
Kind regards,
Nikolas
Am Mo., 6. März 2023 um 09:57 Uhr schrieb brownrb brownrb@users.sourceforge.net:
Hi Robert,
I am using the latest version, myFP2ASCOM_Setup284.exe and ASCOM version 6.5 SP1.
Kind regards,
Nikolas
Hi Nikolas
Thank you for reporting an issue. There indeed is a problem. You detailed message was appreciated and helped pinpoint the quickly quickly.
I have created an updated ASCOM driver v286. I also updated the ASCOM Test Application to v1320
You may have to use control panel to remove the ASCOM driver first. I did not encounter an issue installing the driver without using Control Panel first.
I have no had time to do the ASCOM1 driver (it will have to wait till tommorrow. But these should resolve the issue for you. The link details are
myFP2ASCOM_Setup286.exe
Link
https://sourceforge.net/projects/arduinoascomfocuserpro2diy/files/ASCOM%20DRIVERS/myFP2ASCOM_Setup286.exe/download
myFP2ASCOM TEST App _1_3_2_0
Link
https://sourceforge.net/projects/arduinoascomfocuserpro2diy/files/ASCOM%20DRIVER%20TESTER/myFP2ASCOM_Test_App_1_3_2_0.zip/download
Regards
Robert
Hi Robert,
thank you for the quick turn-around, the issue is fixed.
Kind regards,
Nikolas
I was thrilled to see this timely thread since I have been encountering the identical problem. Unfortunately, removing the old driver (carefully, manually) and installing the newly posted one did not fix it for me. The updated ASCOM myfp2 focuser test client appears to work, but does not actually move the motor (no sign of the arduino serial lights blinking) or update temperatures. Same symptoms in the logs - turn on temperature compensation,... serial disconnects. I've attached the client log and the ASCOM device hub log. Hopefully it's just me doing something stupid.
Hi Mike
The log shows that you are not using the latest ascom driver v286
The log shows
Driver Info = myFocuserPro2ASCOM driver by R Brown.
Driver Version = 2.8.4
Please remove the old version first. If it is no longer available in control panel to uninstall, then
This is not a general thing I encourage user's to do because an ASCOM driver also makes changes to the registry, but if all else fails
look in
C:\Program Files (x86)\Common Files\ASCOM\Focuser
and remove any file that looks like a myfp2 or myfocuserpro2
ASCOM.myFocuser2ASCOM.Focuser.dll
myFP2ASCOMLanguage.txt
myFP2ASCOMReadme.htm
and once they are deleted, then run the installer for driver 286
Regards
Robert
Thanks Robert (both for the quick and useful response and, long-term, for the development and support of this terrific tool). As you suggested, I found that I had a stickly ASCOM...dll file from the previous install that wasn't getting cleared out by the latest install. I'm now officially at 2.8.6 and your ASCOM test application works. It would be nice if it updated the temperature and focus position fields while it is in temperature compensation mode and output those updates to the log. As it stands, I can still use the "GET" buttons to see that it is working.
Above I think you mentioned that an ASCOM1 driver is forthcoming. Right now, if you turn on TC via the ASCOM device hub it renders the hub unresponsive and if you uncheck TC (which it will let you do) it hangs up the device hub so badly that you have to kill it from the task manager. Let me know if I can provide any useful diagnostics.
Thanks,
Mike.
Hi Mike
I am just going through these messages to ensure that everything is covered/explained
**It would be nice if it updated the temperature and focus position fields while it is in temperature compensation mode and output those updates to the log. As it stands, I can still use the "GET" buttons to see that it is working. *
Clarification:
The way that ASCOM works is a query - response. In other words the driver queries and the controller responds. Not the other way around.
there is no mechanism for the controller to send anything to the driver saying hey, I got this now, so take notice. That cannot happen. The controller can only send as a result of a request.
What most "app" developers do is decide to query the controller be making the app send requests to the ascom driver all the time, like get temp, get position, get max steps, get tc being the main ones, every second. Some "apps" go overboard in this, I investigated one "app" that at some points on their code was sending the same requests for the same data around 5ms apart. I do not understand the logic behind that let alone the necessity to do that.
One good thing about INDI is that the user can control this "polling" by letting the user decide how often that occurs.
regards
Robert
Hi Mike
The driver is v2. Under v2 interface from ascom, move while in temp comp mode is forbidden, so the driver ignores a move request when temp comp is ON.
For the ASCOM Trace log if enabled,
A request for temperature is always logged, even if Temp Comp is ON.
Above I think you mentioned that an ASCOM1 driver is forthcoming.
Yes, just uploaded
Right now, if you turn on TC via the ASCOM device hub it renders the hub unresponsive and if you uncheck TC (which it will let you do) it hangs up the device hub so badly that you have to kill it from the task manager. Let me know if I can provide any useful diagnostics.
Sorry, ASCOM device hub?
Regards
Robert
Thanks. I'll track down the ASCOM Trace log. In the meantime, here's a snapshot of the ASCOM device hub. It's a low level interface to configure and operate various ASCOM devices (telescope, focuser, etc.). Your driver works fine in the device hub as long as TC is not enabled, but hangs up once TC is turned on. Similarly, I've been running your driver with the Sharpcap focuser interface for a while with no problem, but the minute I check the TC box everything stops and unchecking, disconnecting, reconnecting doesn't restore basic manual operation of the focuser. All that said, your own test app works fine and is a practical fallback.
Thanks,
Mike.
A followup... Both in the Device Hub and in Sharpcap checking the TC box will put the focuser in TC mode (the motor moves when the DS18B20 gets heated or cooled). Neither application shows updates to the motor position or temperature when in TC mode or after exiting TC mode. All manageable. The one problem is that when the TC mode box is unchecked neither application returns to hands-on motor control with temperature and motor position updated. In Sharpcap, after returning from TC mode, you can initiate a motor move and the motor responds, but the focuser controls do not return from the "moving" state with the buttons and motor position remaining greyed out. You can hit the "Stop" button in the Sharpcap focuser window and get back into a situation where you can move the motor once again (once again it remains in the moving state after it completes the move). In this situation, even though the motor does move, the motor position value does not update. I'll see if I can get some useful information posted from the Sharpcap logging.
Neither application shows updates to the motor position or temperature when in TC mode or after exiting TC mode.
I can confirm that the firmware does indeed change the position when in TC mode.
That can be easily tested by using the windows app, enable TC, cool down the probe using an ice cube, then use a get position.
Of course that assumes that the firmware was generated with temp probe enabled, and the temp probe was found when the controller booted. And the temperature coefficent value was set correctly,
I like to use the Arduino IDE and serial monitor to do these tests
I set the speed to 9600 with no Line Ending
Then looking at the protocol document, typing data into the field at the top, then clicking the send button
:00# Pxxxx# Get current focuser position
so typing :00# will return the position
then
:23x# None Set the temperature compensation ON (1) or OFF (0)
typing :231# and click send
will turn on temperature compensation.
Checking that TC is on,
:24# 1x# Get state of Temperature Compensation, 0=disabled, 1=enabled
I can type :24# and click send
which should return 11x (first char is a code type, 2nd char is the value)
then cool the probe a bit, wait about 20s
and then ask for the position again
:00# and click send
should return Pxxxxx# where P is the code for position and xxxxx is the focuser position
regards
Robert
Hi Mike
I have never used ASCOM Device Hub, so cannot comment on what it does or does not do.
TC issues date back a couple of years now. It happened that a major app decided to ignore TC rules in v2 interface and just move the focuser anyway. Of course this led to a lot of grief with focusers that were implented using v2 interface.
rather than asking the "app" developers to adhere to the interface rules, the group made a decision to allow that behaviour, and then issued a v3 interface, asking of course that apps should check for v2 and deal with it.
What I can say is I did not agree with that and still dont. The only outcome was that the app developers just went on coding the same way they had been doing.
You may find that some "apps" still do not obey the v2 interface rules, and thus will hang when tc is on.
All that aside, if I get the time there are some things I might be able to do. Find my email address in the docs/firmware and send me a mail if you want to do a little testing with the ascom driver.
I will also need to know the name of the firmware file you used to program the controller.
regards
Robert
Last edit: brownrb 2023-03-12
Mike
I have spend most of the day and night on this, using the Device Hub, and now have a working solution.
As I suspected the request for IsMoving immediately following a Move command from the client fails, because the Arduino cannot respond that fast.
This involves both a Firmware update, ASCOM driver update. Hence I would need to know what firmware filename you have so I can make the modifications to that.
I also updated the Interface version of the focuser driver to V3
Regards
Robert
Last edit: brownrb 2023-03-13