I'm trying to set-up a system for a Baader Steeltrack focuser using a DRV8825 board driving a NEMA14/17 PG27 motor and using 312 firmware with all add on's bar the temp probe disabled. I'm using a geared motor to alleviate the need to keep the motor powered and driver/motor from heating up,
The system works, but as I'm driving the 'fine' focus knob, via the PG gearbox, copying the Baader focuser, I need to be able to set the Max Steps to greater than 10000, but no matter what I try, using app. ver 2.4.8.2., or updating DEFAULTMAXSTEPS in myDefines.h it always stays/reverts back to 10000 !! I've also tried adjusting default/maximum step size, to try & get greater movement, to no avail...
What am I doing wrong ??
Julian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Robert,
FYI, one thing I'm seeing, when using the new app & doing 'long' moves is that I'm getting an error window popping up stating: "Timeout Exception in ReceiveResponse : No Response from controller" but the move carries on and on clicking ok the app appears to be working ok except there is a 'Pulse' of the RX led on the Nano and a corresponding pulse in the motor movement.
Julian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would need the windows app error log to be able to track this down
I did not any code related to movements etc so I have no idea what the cause is, but I need the log.
I have always been unhappy with some aspects of the code that tracks moving. I implemented a new method with the Linux application and I will change to that in the near future, but in the meantime it would be nice to determine what is the root cause.
Last edit: brownrb 2021-10-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for log - confirmed my suspicions
02/10/2021 12:12:55: SendString: sending=:0572000#
02/10/2021 12:12:55: SendString: sending=OK
02/10/2021 12:12:55: SendString: =END===========================================================
02/10/2021 12:12:55: ReceiveResponse: ==START====================================================
02/10/2021 12:12:55: ReceiveResponse: Check if client is connected
02/10/2021 12:13:06: ReceiveResponse: Timeout Exception
02/10/2021 12:13:06: ReceiveResponse: Error message: System.TimeoutException: The operation has timed out.
at System.IO.Ports.SerialStream.Read(Byte[] array, Int32 offset, Int32 count, Int32 timeout)
at System.IO.Ports.SerialStream.Read(Byte[] array, Int32 offset, Int32 count)
at System.IO.Ports.SerialPort.InternalRead(Char[] buffer, Int32 offset, Int32 count, Int32 timeout, Boolean countMultiByteCharsAsOne)
at System.IO.Ports.SerialPort.ReadTo(String value)
After sending 05 it waited for a response. 12:55
A response never came 13:06
That is because ther is no response to any Set command (05 is a set command)
Only get commands (like get coil power etc) is when the controller sends a response
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So over the last couple of hours I rewrote the code, ripping out a lot of code that is now redundant.
I did find the errors of code that related to the timeout - my mistake
So anyhows, changed the way that the app now handles moves. I just did a 12000 step move without issue.
So I will post the update now.
// 2.4.8.6
// Fix for timeout issues
// Implemented timer to monitor and handle moving positions
Pic shows moving from 2000 - 17000
Note the new status indicator Idle - Changes to Moving when a move occurs
it doesn't surprise, you've done a marvellous job over the years, and with the changes in technology etc. there were bound to be 'issues' cropping up over time, but keep up the great work....
Julian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FYI, I still get a 'Pulse' in motor movement & RX led when the "Please wait : focuser is moving" is being flashed to the screen, but I suspect that this will now be a limitation of the hardware not able to cope with the quick updates etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
please explain pulse in motor movement?
Are you referring to a small audible pause like the motor stopped moving for a fraction?
If so this is normal.
I ask you to bounce a ball with one hand and be ready to catch something else with your other hand. So you are happily dribbling the ball away, and I throw another tennis ball towards your other hand - so there comes a slight hesitation or speed of dribbling suffers, because the brain has to splice together the competing requirements, and something has to give.
the controller is like that. It is a slow speed cpu, not a fast pc. There is no real multitasking or scheduling of tasks - the arduino basically chugs along moving the motor (bouncing the ball), when suddenly another command comes it - so it rushes off to process that, and whilst it is processing that - well it had to give up the bouncing of the ball (moving the motor) until the command was processed - so yes, there are these small blips - but, and it is important to note, that there are no missed steps. We just say "stop moving the motor for a bit" and go "process this command" and when finished with that "go back to moving the motor"
The esp32 version does not suffer from this drawback. If there was enough memory I would have coded the nano version the same way, but, alas, the nano does not have any space left to do this.
but I suspect that this will now be a limitation of the hardware not able to cope with the quick updates etc.
No, the app can only run as fast as the controller allows. Communication is send/response or send/no response.
So the app, once it determines it can send a command, sends it
Checks are for ismoving (one cannot move if already moving)
Check for Temp Comp enabled (one cannot move if TC is on - that would stuff up the temp comp handling code). If a response is required (get something command) then the app waits up to 5s for a response. Most responses would occur in less than 20ms. So there is a measure of "flow control". In addition, the app, after sending a command, waits a pre-determined amount of time before sending another command (which is a delay around 50ms in duration). So that means the controller can keep up with things, because if commands coming from the app are about 50ms apart, and the controller can send a response in < 20ms, then everything should go smoothly,
Back to the issue of a move timing out - the move command begins with :05
What was causing the issue in the code was that the code sent the move command (05) - then waited for a response and timed out after 5s.
There is essentially no reponse for an 05 move command.
This occured in two places in the code for the windows app, so I removed the offending lines of code that was waiting for a response.
The other code changes had to do with implementing the monitoring of the move by timer, rather than the huge amount of code that was in there before,
When a move is requested, the app
1. checks to see if temp comp on - if it is then move is cancelled
2. checks to see if focuser is moving - if it is, then the move is cancelled
3. determines the destination position
4. sends the move command to the controller
5. starts a periodic timer that monitors the move, checking once every second, by getting the ismoving state, and the position (which updates the position field on the form
6. when the periodic timer detects that the ismoving state is false, this means the focuser is no longer moving, so it reads the position from the controller and updates the form, then turns itself off.
So during a move,
1. The moving indicator at the botton of the form shows "moving"
2. The position field is updated to the position the focuser is at
3. The status message will show focuser is moving etc
Any pulsing of the rx or tx led's will be an indication that the app is talking to the controller, so when the app sends are you moving, you will see the rx led flash, then the tx flash as it sends back a response of (yes or no).
Sorry for the long explanation. A lot of things are going on under the hood, trying to make the app somewhat resistant to a bullet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for explanation...
So from what you say, it may be better to use an ESP32 module instead of the nano's,...
But also to be honest, I don't use the application that much, as my systems are usually remotely driven on Linux/Windows systems, using KStars, Indi etc. or Sharpcap, SGPro, BackyardEos et al with the Ascom or native drivers, its just that with this Baader Steeltrack focuser, I'm mocking everything up on a workbench, before fitting it to a scope, so noticing these 'funnies'
I'm also going to mock up a board based on the Watterott TMC2209 driver module, but the circuit diagram of what is connected to what is a little confusing, what with the colour changes, connection blobs for some connections & not others, also there is no underneath image to confirm connections, unless I load the gerber files into a viewer..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The esp32 wifi is supported by INDI (use indi driver myfocuserpro2 in TCP/IP mode)
Also android phone, tablet, json, web interface, the list goes on
:-)
The Watterott TMC2209 is not supported
Last edit: brownrb 2021-10-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Robert,
I'm trying to set-up a system for a Baader Steeltrack focuser using a DRV8825 board driving a NEMA14/17 PG27 motor and using 312 firmware with all add on's bar the temp probe disabled. I'm using a geared motor to alleviate the need to keep the motor powered and driver/motor from heating up,
The system works, but as I'm driving the 'fine' focus knob, via the PG gearbox, copying the Baader focuser, I need to be able to set the Max Steps to greater than 10000, but no matter what I try, using app. ver 2.4.8.2., or updating DEFAULTMAXSTEPS in myDefines.h it always stays/reverts back to 10000 !! I've also tried adjusting default/maximum step size, to try & get greater movement, to no avail...
What am I doing wrong ??
Julian
Hi Julian
Nothing I think, looks like the app is broken
Seems a bug or two crept into the windows app
So i have uploaded a fixed windows application
myFocuserPro2_2_4_8_4
https://sourceforge.net/projects/arduinoascomfocuserpro2diy/files/WINDOWS/MainApp/
regards
Robert
Thanks Robert
I can confirm that I'm now able to set Max Steps above 10000...
There maybe some other funnies, e.g. motor speed was set to slow & step mode to half, but at least they are 'set-able' and don't revert back...
Anything major I'll report here...
Julian
Robert,
FYI, one thing I'm seeing, when using the new app & doing 'long' moves is that I'm getting an error window popping up stating: "Timeout Exception in ReceiveResponse : No Response from controller" but the move carries on and on clicking ok the app appears to be working ok except there is a 'Pulse' of the RX led on the Nano and a corresponding pulse in the motor movement.
Julian
I would need the windows app error log to be able to track this down
I did not any code related to movements etc so I have no idea what the cause is, but I need the log.
I have always been unhappy with some aspects of the code that tracks moving. I implemented a new method with the Linux application and I will change to that in the near future, but in the meantime it would be nice to determine what is the root cause.
Last edit: brownrb 2021-10-02
As requested.
Thanks for log - confirmed my suspicions
02/10/2021 12:12:55: SendString: sending=:0572000#
02/10/2021 12:12:55: SendString: sending=OK
02/10/2021 12:12:55: SendString: =END===========================================================
02/10/2021 12:12:55: ReceiveResponse: ==START====================================================
02/10/2021 12:12:55: ReceiveResponse: Check if client is connected
02/10/2021 12:13:06: ReceiveResponse: Timeout Exception
02/10/2021 12:13:06: ReceiveResponse: Error message: System.TimeoutException: The operation has timed out.
at System.IO.Ports.SerialStream.Read(Byte[] array, Int32 offset, Int32 count, Int32 timeout)
at System.IO.Ports.SerialStream.Read(Byte[] array, Int32 offset, Int32 count)
at System.IO.Ports.SerialPort.InternalRead(Char[] buffer, Int32 offset, Int32 count, Int32 timeout, Boolean countMultiByteCharsAsOne)
at System.IO.Ports.SerialPort.ReadTo(String value)
After sending 05 it waited for a response. 12:55
A response never came 13:06
That is because ther is no response to any Set command (05 is a set command)
Only get commands (like get coil power etc) is when the controller sends a response
Hi Dr.
So over the last couple of hours I rewrote the code, ripping out a lot of code that is now redundant.
I did find the errors of code that related to the timeout - my mistake
So anyhows, changed the way that the app now handles moves. I just did a 12000 step move without issue.
So I will post the update now.
// 2.4.8.6
// Fix for timeout issues
// Implemented timer to monitor and handle moving positions
Pic shows moving from 2000 - 17000
Note the new status indicator Idle - Changes to Moving when a move occurs
https://sourceforge.net/projects/arduinoascomfocuserpro2diy/files/WINDOWS/MainApp/
Apologies to every one re my stuff up.
Regards
Robert
Thanks Robert,
it doesn't surprise, you've done a marvellous job over the years, and with the changes in technology etc. there were bound to be 'issues' cropping up over time, but keep up the great work....
Julian
FYI, I still get a 'Pulse' in motor movement & RX led when the "Please wait : focuser is moving" is being flashed to the screen, but I suspect that this will now be a limitation of the hardware not able to cope with the quick updates etc.
please explain pulse in motor movement?
Are you referring to a small audible pause like the motor stopped moving for a fraction?
If so this is normal.
I ask you to bounce a ball with one hand and be ready to catch something else with your other hand. So you are happily dribbling the ball away, and I throw another tennis ball towards your other hand - so there comes a slight hesitation or speed of dribbling suffers, because the brain has to splice together the competing requirements, and something has to give.
the controller is like that. It is a slow speed cpu, not a fast pc. There is no real multitasking or scheduling of tasks - the arduino basically chugs along moving the motor (bouncing the ball), when suddenly another command comes it - so it rushes off to process that, and whilst it is processing that - well it had to give up the bouncing of the ball (moving the motor) until the command was processed - so yes, there are these small blips - but, and it is important to note, that there are no missed steps. We just say "stop moving the motor for a bit" and go "process this command" and when finished with that "go back to moving the motor"
The esp32 version does not suffer from this drawback. If there was enough memory I would have coded the nano version the same way, but, alas, the nano does not have any space left to do this.
but I suspect that this will now be a limitation of the hardware not able to cope with the quick updates etc.
No, the app can only run as fast as the controller allows. Communication is send/response or send/no response.
So the app, once it determines it can send a command, sends it
Checks are for ismoving (one cannot move if already moving)
Check for Temp Comp enabled (one cannot move if TC is on - that would stuff up the temp comp handling code). If a response is required (get something command) then the app waits up to 5s for a response. Most responses would occur in less than 20ms. So there is a measure of "flow control". In addition, the app, after sending a command, waits a pre-determined amount of time before sending another command (which is a delay around 50ms in duration). So that means the controller can keep up with things, because if commands coming from the app are about 50ms apart, and the controller can send a response in < 20ms, then everything should go smoothly,
Back to the issue of a move timing out - the move command begins with :05
What was causing the issue in the code was that the code sent the move command (05) - then waited for a response and timed out after 5s.
There is essentially no reponse for an 05 move command.
This occured in two places in the code for the windows app, so I removed the offending lines of code that was waiting for a response.
The other code changes had to do with implementing the monitoring of the move by timer, rather than the huge amount of code that was in there before,
When a move is requested, the app
1. checks to see if temp comp on - if it is then move is cancelled
2. checks to see if focuser is moving - if it is, then the move is cancelled
3. determines the destination position
4. sends the move command to the controller
5. starts a periodic timer that monitors the move, checking once every second, by getting the ismoving state, and the position (which updates the position field on the form
6. when the periodic timer detects that the ismoving state is false, this means the focuser is no longer moving, so it reads the position from the controller and updates the form, then turns itself off.
So during a move,
1. The moving indicator at the botton of the form shows "moving"
2. The position field is updated to the position the focuser is at
3. The status message will show focuser is moving etc
Any pulsing of the rx or tx led's will be an indication that the app is talking to the controller, so when the app sends are you moving, you will see the rx led flash, then the tx flash as it sends back a response of (yes or no).
Sorry for the long explanation. A lot of things are going on under the hood, trying to make the app somewhat resistant to a bullet.
Thanks for explanation...
So from what you say, it may be better to use an ESP32 module instead of the nano's,...
But also to be honest, I don't use the application that much, as my systems are usually remotely driven on Linux/Windows systems, using KStars, Indi etc. or Sharpcap, SGPro, BackyardEos et al with the Ascom or native drivers, its just that with this Baader Steeltrack focuser, I'm mocking everything up on a workbench, before fitting it to a scope, so noticing these 'funnies'
I'm also going to mock up a board based on the Watterott TMC2209 driver module, but the circuit diagram of what is connected to what is a little confusing, what with the colour changes, connection blobs for some connections & not others, also there is no underneath image to confirm connections, unless I load the gerber files into a viewer..
The esp32 wifi is supported by INDI (use indi driver myfocuserpro2 in TCP/IP mode)
Also android phone, tablet, json, web interface, the list goes on
:-)
The Watterott TMC2209 is not supported
Last edit: brownrb 2021-10-03