MyFocuserPro Disconnecting On First Command

[Ian Lauwerys]

Hi all,

I recently built a focuser based on another project, but found the included ASCOM driver was throwing errors when SGPro tried to query isMoving, suggesting something not right in the driver. I thought I'd give this project a try as the firmware and driver / control software are much more developed and would likely give me a bit more confidence.

I have run in to a communications issue which I can't really figure out. I can sucessfully connect the myFocuserPro Windows application to the focuser and it reports it is happy having retrieved all status data, driver version, etc. As soon as I try to send a command (e.g. click the Get Position button), the application quickly times out and disconnects the focuser stating there was no response (see log at end of post).

This is rather odd as if I immediately fire up the Arduino IDE and connect with the serial monitor I can successfully send commands manually and receive the expected responses (e..g. send :P0# and get P5000# back immediately) which suggests the Arduino side is still working (possibly it has reset between these steps but I don't think so as far as I can tell).

The hardware is a non-geared NEMA17 (with belt and pulley connection to focuser), driven by an EasyDriver board and a Pro Micro clone board (ATmega32U, 32K with 1K EEPROM).

I'm using single stepping as the belt drives the 10:1 fine control knob on a Baader Diamond Steeltrack (Yes I have read all the dire warnings about driving fine control knobs, but Baader's own motor unit is designed to drive it using the same pulley and belt system and German engineers know what they're about!)

It all works fine with the other project's driver and firmware, save for the SGPro error, so I'm happy the hardware and electronics are correct. I have had to modify the Focuserv262_DRV8825_HW203 in a couple of ways as I didn't start with this project's hardware design:

1. Amended the control pin numbers for the EasyDriver to match the ones I am using - trivial change and should not cause any issues.

2. For some reason, the Pro Micro clone doesn't define serialEventRun(), which checks the serial buffer for data and if there is some calls serialEvent() to process it. This is a common issue and easily resolved by adding a definition for the missing function:

void serialEventRun() {
if (Serial.available()) serialEvent();
}

If this function isn't added, then myFocuserPro fails to initialise the board (as expected) as the Arduino never processes the incoming commands, but everyting springs in to life as soon as it is added in.

I've tried a few things like increasing the delay on connect to 10 seconds, and the delay on serial read timeout to 20 or 30 seconds and trying with "Reset Controller On Connect" enabled and disabled to no avail. I have also tried different port speeds from slow to fast and again no joy.

I've also tried a (software) serial port tap to watch the flow of data between the application and the focuser but no clues there. The outgoing initialisation commands are sent and the responses come back as per the log below. As soon as the first (non-initialisation) command is sent, it goes out but no response comes back. This suggests an issue at the Arduino firmware end rather than the windows application end.

I'm at a bit of a loss as to where to go from here to diagnose the problem and wondered if anyone else had seen anything similar. I know I'm a bit off piste from the "official" releases but can't really see any reason why this should be happening given the board will respond merrily to manual commands immediately afterwards when I fire up the IDE and serial monitor.

I did wonder if there was some kind of internal crash, out of memory condition or other blocking/looping event but as I've said, the only material code change I've made is to add the missing serialEventRun definition. The compilation/upload suggests there is plenty of memory available, especially as this is a minimal build with no buttons, displays, temperature probes or any of the extras.

Thanks in advance for any wisdom that may shed a light on this.

--

The tail of the log is attached below showing the last step in the initial connection process completing OK, followed by an attempt to get the current position which causes a timeout and disconnect:

:
:
14/12/2017 17:00:16: Calling CommandString(:80#)
14/12/2017 17:00:16: CommandString(): =START=========================================================
14/12/2017 17:00:16: CommandString: Serial Port is Open
14/12/2017 17:00:16: CommandString: Try to write command: :80#
14/12/2017 17:00:16: CommandString: Command was sent.
14/12/2017 17:00:16: ReceiveString(): =START=========================================================
14/12/2017 17:00:16: ReceiveString: Command retcmd = 7
14/12/2017 17:00:16: ReceiveString: Buffer recbuf = 70#
14/12/2017 17:00:16: ReceiveString: Value retstr = 0
14/12/2017 17:00:16: ReceiveString raw response for get backlash OUT steps was: 70#
14/12/2017 17:00:16: ReceiveString(): =END===========================================================
14/12/2017 17:00:16: CommandString(): =END===========================================================
14/12/2017 17:00:16: Back from CommandString
14/12/2017 17:00:16: enableall(): =START=========================================================
14/12/2017 17:00:16: enableall(): =END===========================================================
14/12/2017 17:00:16: ======CONNECT END TIME
14/12/2017 17:00:16: Connect(): =END===========================================================
14/12/2017 17:00:26: GetPosition(): =START=========================================================
14/12/2017 17:00:26: GetPosition: Serial Port is Open
14/12/2017 17:00:26: GetPosition: ConnectedState is true
14/12/2017 17:00:26: GetFocusPosition(): =START=========================================================
14/12/2017 17:00:26: GetFocusPosition: Serial Port is Open
14/12/2017 17:00:26: GetFocusPosition: ConnectedState is true
14/12/2017 17:00:26: Calling CommandString(:00#)
14/12/2017 17:00:26: CommandString(): =START=========================================================
14/12/2017 17:00:26: CommandString: Serial Port is Open
14/12/2017 17:00:26: CommandString: Try to write command: :00#
14/12/2017 17:00:26: CommandString: Command was sent.
14/12/2017 17:00:26: CommandString(): =END===========================================================
14/12/2017 17:00:26: Back from CommandString
14/12/2017 17:00:32: GetFocusPosition: ERROR: NO RESPONSE/TIMEOUT. CLOSING SERIAL PORT
14/12/2017 17:00:32: disableall(): =START=========================================================
14/12/2017 17:00:32: disableall(): =END===========================================================
14/12/2017 17:00:32: GetPosition: ERROR: GETFOCUSPOSITION RETURNED INVALID STATE
14/12/2017 17:00:32: GetPosition(): =END===========================================================
14/12/2017 17:00:34: Exit(): =START=========================================================
14/12/2017 17:00:34: ExitBtn: exiting
14/12/2017 17:00:34:
Number of focuser moves = 0
Number of Temperature calls = 12
Number of Firmware calls = 12
Number of Connects = 8
Number of Set Focuser Position = 0
Number of Get Max Steps = 12
Number of Set Max Steps = 0
Number of Get Step Mode = 9
Number of Set Step Mode = 0
Number of Coil Power Changes = 0
Number of Reverse Direction Changes = 0
Number of Motor Speed Changes = 0
Number of Display Enables = 0
Number of Display Disables = 0
Number of Display Enables during Moves = 0
Number of Display Disables during Moves = 0

14/12/2017 17:00:34: ExitBtn: Com port closed: exiting
14/12/2017 17:00:34: FormClosing: Start
14/12/2017 17:00:34: FormClosing: Serial port not connected
14/12/2017 17:00:34: FormClosing: Save application settings
14/12/2017 17:00:34: FormClosing: Stop timers
14/12/2017 17:00:34: FormClosing: Finish
14/12/2017 17:00:34: FormClosing: Start
14/12/2017 17:00:34: FormClosing: Serial port not connected
14/12/2017 17:00:34: FormClosing: Save application settings
14/12/2017 17:00:34: FormClosing: Stop timers
14/12/2017 17:00:34: FormClosing: Finish

[brownrb]

Hi Ian
I am happy to work on this with you.
But I need you to follow precisely what I need to bedug this further in the quickest time.

1. Please send me the firmware file you have modified and have loaded into the controller
2. I will need to know the Windows app version you are using.
3. I will need the logfile, all of it, unedited, but to generate that see below

I assume from the logfile that you connected to the controller using the windows app, it connected ok, then when you tried to get current position it timed out? Is that correct?

So, can I please ask you do the following in the order outlined
1. Connect the controller via USB
2. Delete any previous windows application log files
3. Start the Windows application
4. Enable logging (if not already enabled)
5. Connect to the focuser
6. Wait till all the commands have been completed and it is "READY"
7. Click the Get Position button
8. Wait till the command is completed - if a time out occurs, please close the windows application and send me the logfile. I have an account on yahoo, name is brown_rb
9. If the command did not time out, click move +100, wait till that is complete and then exit the app and send me the logfile.

I also need a screen capture of your Windows application "Extra Settings" screen so I can match initialization commands to that screen.

There is one further thing I would like you to check also. Can you confirm what hardware build? Does it have any push buttons? Does it have LCD? Does it have temperature probe?

Regards
Robert

Cheers
Robert

[Ian Lauwerys]

Thanks Robert - really appreciate your help with this.

I will send everything over to you asap,

[Ian Lauwerys]

I've emailed the files and information over - hopefully they will get to you but let me know if not!

[brownrb]

For anyone interested in this thread, Ian has been testing some new code that looks promising for the Micro (Arduino variant). When finished these will be migrated into the Windows App and ASCOM drivers.

Regards
Robert

[Mike W]

Are the changes needed to deal with the Arduino Mico wanting to act like a USB-HID device (keyboard, mouse)?

[brownrb]

Hi Mike
Not really. The Micro combines both the USB and Serial port together, whereas in the Nano they are actually two separate parts of hardware. This means one has to take a little more care in dealing with serial comms with a micro compared to a Nano.

I have posted the latest files to test on the myArduinoDIY yahoo users group for anyone that has a Micro instead of a Nano.

The project recommends using a Nano and its what we test against. We are not supporting the Micro as an alternative controller, just trying to help Ian with an issue.

Regards
Robert

[Ian Lauwerys]

Thanks to Robert for his help with this

As stated, there is no particular reason to use a Micro instead of a Nano given the price is pretty much identical. I just happened to have a spare Pro Micro clone and had built the hardware based on another project before running in to some (possible) driver problems with it, so changed projects mid-way through.

If anyone needs help getting a Pro Micro working then more than happy to let you know what changes are needed but I'd recommend sticking with the official build unless you have specific reasons for doing otherwise!

[Rofear]

I am using the Pro Micro with the DRV8825 because I need to make it as compact as possible, but I cannot find the pin equivalences to transition from the Nano to the Pro Micro.

Above all, I need to use microstepping

[brownrb]

Hi Rofear
I am not familiar with a Pro Micro. After a quick Google search, I see that the pins would not be compatible with the Pro Micro. For example 2, 3 are used for temp probe and drv8825 step.
In the pro micro they are used for I2C.

That would require a considerable amount of time to create a schematic, then write the firmware that would be required to go with those pin changes.

It would be cheaper using a Nano, honestly, unless time is not measures by $.

regards
Robert