Always Controller Reset on connecting (Ascom)

[Vincenzo Amarante]

I'm using last ascom driver 284 on WIN10. The controller reset when connected also if I uncheck "Reset Controller On Connect". The behaviour is the same with alla clients :Nina, SequencerPro or myAscomClient 1.3.1.11.
No problem using the windows App myFP2W 2.4.9.1.
Controller FW 321
Thanks, regards, VIncenzo, Rome

[brownrb]

Hi Vincenzo
Thanks for letting us know, I will take a look and report back

Regards
Robert

[brownrb]

Hi Vincenzo

I have gone over the code for the ASCOM driver. Nothing obvious.

On the ascom driver setup form, check the box called Trace on
Make sure the checkbox reset controller on connect is unchecked
Then click Connect

The trace file is stored in the users Documents folder, under ASCOM/logsxxx
named a bit like
ASCOM.myFP2ASCOM.0045.096310.txt
The numbers of course will be different

After connecting the application like NINA etc, and once connected, close the application
and send me the trace file.

Then next
Run the ascom profiler
Start - ASCOM platform 6, Profiler Explorer
In the left pane, click Focuser Drivers and expand it (+)
Click on ASCOM.myFocuser2ASCOM.Focuser
The right pane shows all the properties for the focuser ascom driver
I need you to do a screenshot. There are a lot of properties, so you will need to take a couple of screen shots, the second screen shot of the ones that show shen scrolled down.

I attach my screen shots so you know what I require.

regards
Robert

[Vincenzo Amarante]

Hi Robert thanks for the prompt answer.
You can find attached the two trace logs and the parameters shown in the profile explorer windows.
As I can read the "reset on connect parameter" is always false.
If can help I give you another info: If I start the myFP2W (2.4.9.1) after using the ascom driver, controller reset after the 2 seconds delay also if the checkbox is unchecked, only the first time. But until I run again the ascom driver I can restart myFP2W many times without any problem.
Thanks, Vincenzo

[Vincenzo Amarante]

Just another info: I've found an old Ascom driver 270 and does not have the problem. As workaround I can use this for now.

[brownrb]

Please try this version and let me know if the issue is fixed

Regards
Robert

[Vincenzo Amarante]

Yes, Robert, now it's fixed, thank you!
I take the opportunity to ask you another thing: I'm using the encoder and the backlash recover (already enable and working) does not work. It there something to enable in the source or the feature is not available on the encoder ?

[brownrb]

Hi Vincenzo
Thanks for the confirmation about the ASCOM driver. I will make the changes and post the updated driver to the files area.

No sure that I follow the question.
What do you think should happen when you do the "steps", I assume the following
1. rotary encoder is enabled
2. backlash is enabled

Backlash is only applied when the direction changes, assume the last move was out

1. move out 100 steps
2. move out 10 steps
3. move in 10 steps >>>> backlash gets applied
4. move in 100 steps
5. move out 5 steps >>>> backlash is applied

There are different settings and enable for In and Out
If backlash in is enabled, backlash only occurs if the last direction is out and the next work is in

If backlash out is enabled, backlash only occurs if the last direction is in and the next work is out

The main loop() monitors requests for "move"
These requests can come from the serial port, rotary encoder, keypad, touchscreen or push buttons

All "move" requests are checked for 0 and maxsteps, and the direction of the move checked to see if backlash is to be applied.

case State_InitMove:

is where backlash amount is determined, and if applying backlash is to be done.
That code, as stated, does not care about what caused the move, so it does not matter if it is rotary encoder, push buttons etc, it is a "move"

Backlash is always applied first before the steps to move. Backlash does not alter the focuser position, so it will step the required number of backlash steps first - without changing the position, then the move steps is done and the focuser positions on each step until the move is complete. Because backlash is in the same direction as the move request, it may not be detectable visually by the user depending on the settings that are applied.

I guess you are wondering if backlash is being applied.
I would suggest the following
Enable backlash in and out
Set the backlash steps to a high number for in and out, maybe 250

Use the rotary encoder, two clicks in
Next, rotary encoder two clicks out: this will trigger backlash out, by 250 steps
Next rotary encoder two clicks in, the will trigger backlash in by 250 steps

regards
Robert

[Vincenzo Amarante]

Hi Robert,
after some testing the situation seems more complicated :-)
The test was done with last firmware and the myFP2W 2.4.9.1 to change the parameters faster.
IN Backlash Enabled
OUT Backlash Enabled

Actually I'm using in and out 35 steps found some time ago and worked correctly with my last firmware (an old one. I dont' remember what).
The behaviour seemed correct after the firmware upgrade: if I advance 10 steps, then another 1 and then -1 I hear correctly that the sound is a little different and more pronounced. this indicated me that all was working well.
Now the weird... If I rise the steps until 200-250 (checking with the GET option of the client) and repeat the procedure, the "backlash sound" is always the same and it' not possible with a backlash of 100-200 steps. It seems that the backlash steps are correctly working until 30-50, but they do not change for backlash steps higher (the get command returns the steps correctly updated). This may be confirmed by the problem that if I set the backlash with a number higher than 300 it returns always "44".
Now about the encoder. I understand that the procedure should work the same no matter which is the source, but in case of the rotary controller for sure in my case it not apply the backlash compensation and advance always 1 step at time no matter the backlash settings. I dont' know if this can be related to the previous problem.
Tell me if I can do further tests to better investigate the problem.
Vincenzo

[brownrb]

change for backlash steps higher (the get command returns the steps correctly updated). This may be confirmed by the problem that if I set the backlash with a number higher than 300 it returns always "44".

Backlash steps over 250 is not supported. If the value is higher it becomes indeterminate,
What are you using to change the backlash? Windows? or ASCOM?

Now about the encoder. I understand that the procedure should work the same no matter which is the source, but in case of the rotary controller for sure in my case it not apply the backlash compensation and advance always 1 step at time no matter the backlash settings. I dont' know if this can be related to the previous problem.

Sorry, but as I said, a move is a move and the firmware works on a move - it does not check what caused the move (encoder, ir-remote, keypad etc.

What happens is the move if generated by the push-button or encoder or ir-remote etc, and the move consists of how many steps and in what direction.

Then this data , steps and direction, are fed into the backlash code. If the direction has changed, then backlash is applied first. The motor is moved in that direction by the amount of backlash steps, and the focuser position does not change.

Only after this is the move started, where the focuser position starts to change

Having said all of that, I do have a focuser unit here that has a rotary encoder on it. So I will take a look at the two issues with that unit.

Which firmware file are you using?
myFP2_DRV8825HW203_321?

What are the configuration options in focuserconfig.h
Rotary Encoder, Display, Stepper Power On, etc

and what are you using to test, is it
rotary encode only
windows app
ascom app
linux indi driver

[Vincenzo Amarante]

Hi Robert,
I hope to not bother you.

What are you using to change the backlash? Windows? or ASCOM?
Windows 10 myFP2W 2.4.9.1

Having said all of that, I do have a focuser unit here that has a rotary encoder on it. So I will take a look at the two issues with that unit.
Yes, try by yourself please. Probably I'm doing something wrong but on my side the encoder does not trigger the backlash compensation. I also try to further investigate.

Which firmware file are you using?
myFP2_DRV8825HW203_321?
Yes

What are the configuration options in focuserconfig.h
Rotary Encoder, Display, Stepper Power On, etc
Attached the config file. Yes Stepper power ON

I'm using ASCOM and Windows App to test. In both cases backlash works correctly ( I just have some doubts on the effettive backlash steps applied). With the encoder when I invert the direction backlash does not apply.

Is there a debug switch o something else to enable to trace the effettive step number applied on the motor?
Thanks, regards, Vincenzo

[brownrb]

Hi Vincenzo

Debug uses the serial port for messages. the problem is that the serial port is also used by windows and ascom, so you cannot debug firmware if using ascom or windows .

If you enable debug code, you are left with debugging by hand. I will give a quick overview of this. But first, it is best to use full step mode, slow motor speed to debug.

Next, you need to use protocol pdf to know what the codes are.
https://sourceforge.net/projects/arduinoascomfocuserpro2diy/files/Documentation/myFP2%20Comms%20Protocol%20v252.pdf/download

When I look at the pdf, these commands are useful
00#
which returns position of focuser, preceeded by P and terminated with #
:64xxxx#
which is relative move, xxxx can be negative or positive
For example
:64500# will move the focuser inwards by 500 steps
and
:64120# will move the focuser outwards by 120 steps

Let me describe the process, rather than the how, which I will get to

WHAT TO DO
I would first use Windows application to set backlash enable on for both in and out, and set the backlash steps to 50

Next I would send this to move the focuser out by 10 steps
:64100#
I would expect the focuser to move 1/2 a revolution ( a nema motor moves 200 steps per revolution - unless you are using a 0.9 degree motor that would be 400 per revolution)

Next I would send this to test backlash in
:64-1#
which should move 50 steps (1/4 of a revolution in the opposite direction), followed by 1 step for the move. If it only moved 1 step, then backlash in is not enabled or the in steps are set wrong or there is an isssue

Next I would send this to test backlash out
:641#
which should move 50 steps (again 1/4 of a revolution in the opposite direction) followed by the move of 1 step. . If it only moved 1 step, then backlash out is not enabled or the out steps are set wrong or there is an isssue

HOW TO DO
Goto the folder where you have the firmware file. Save the main file .ino in another location.
Download the the attached .ino file and use that instead of the one you have.

Now Load Arduino with the firmware file and connect usb cable to the focuser.
Click on the myDefines.h tab
scroll down to line 102 and change to
#define DEBUG 1
(remove the // comment so that debug is enabled)
next, in the main file, I have added code at line 882 onwards to help with debug

On the top right of the Arduino IDE is the Serial Monitor, which you open.
The speed should be set to 9600, no carriage return of line feed

I attach screenshot

Type
:00#
and click send
I would expect a response like
P4000#
where 4000 means the focuser position

This is a test to see if we are talking to the focuser. If you get no response then there is an issue, perhaps wrong speed or wrong com port

When we are talking to the controller, then it is time to start the tests I outlined above.
Starting with what to do
Next I would send this to move the focuser out by 10 steps
:64100#
all down to
:641#
as outlined above

The text output in the serial monitor window should give you a good indication about what happened, When the tests are finished the text can be copied into a text file.

Now, and do not forget this, you cannot use that to test with windows or ascom
After the tests, you need to disable the DEBUG and replace the main .ino file with the one you saved.

[Vincenzo Amarante]

Thank you Robert I'l try with your indications.
Regards, VIncenzo

[brownrb]

No need to try
I have found an issue with backlash.
I will be posting a firmware update later today.

regards
Robert

[brownrb]

Hi
I have posted a fix, firmware release 322
Thanks for posting the issue, backlash was not working like it should,

https://sourceforge.net/projects/arduinoascomfocuserpro2diy/files/ARDUINO%20FIRMWARE/myFP2-Firmware-322.zip/download

[Vincenzo Amarante]

Hi Robert,
I take the holyday opportunity (and the bad weather) to spent some time playing with your project...
Unfortunately your last fix does not solve my problems.
Recapping the two issues I have:
1 - the backlash steps are not correctly applied.
I've found the cause of this problem on my controller. When the backlash is applied ( case State_ApplyBacklash: ), the command (in my case) is done without the necessary delay and the motor does not move correctly (due the too short time between move commands). I've fixed the problem with the workaround of adding a delay(1) inside the if backlash_count)...
I dont' know because the timing is not the same in a normal step move and in a backlash move, but adding 1ms to any backlash step here works.
2 - Using the rotary encoder the backlash is not applied and the "case 4" goto 0 with 4 push does not work.
I'm trying to dive in the code to find the problem but until now I've not yet seen the light...
The fact is that here the backlash with the encoder is not applied.
The three step amount with push button work correctly and the subsequent moves use the new correct 1-10-100 steps. But the fourth case does not work (correctly send the four beeps) and the position is not updated to 0.

This is the situation now.
Thanks for your cooperation.
Regards, Vincenzo

[Vincenzo Amarante]

Sorry Robert I didn't understund the meaning of 4 push. It's not a GOTO 0 command but a reset to 0 the current position. So it's correct the actual behaviour.

[brownrb]

Hi Vincenzo

I undertand the reason for the delay, it was not in the test code I ran on a different focuser because it was not required for that driver type.

However, as you point out, it is needed in others. So I will post 323 version later today. Fix is below, I am still looking at the rotary encoder/backlash and I fail to see why it is not working for you.

case State_ApplyBacklash:
  //Serial.print("State_ApplyBacklashbacklash count: ");
  //Serial.println(backlash_count);    
  if ( backlash_count )
  {
    (movedirection == MOVINGIN) ? MotorStepAntiClockwise() : MotorStepClockwise();
    delay((long)driverboard->getstepdelay());
    backlash_count--;
  }

  Regards
  Robert

[Vincenzo Amarante]

Hi Robert, thanks for the fix, meanwhile, I update my code.
Good news here, I've found the bug (I hope)!
Inside the updaterotaryencoder() there is the statement:
myfocuser.focuserdirection = movedirection;
and in case State_InitMove:
the statement if (movedirection != myfocuser.focuserdirection)
is always false so backlash never applies
commenting the line myfocuser.focuserdirection = movedirection; the backlash is appied as needed.
Can you please check?
Regards, Vincenzo

[Vincenzo Amarante]

Robert, pay attention that stepdelay is in microseconds and delay() is in millisecond so, or you use stepdelay/1000 or you should use delayMicroseconds() but Nano clock and its resources I think cannot manage this statement.

[brownrb]

Yes,
Looking back now, some of the code is a product of an older version that reflected the way the motor was controlled. When that change occurred, the older code residing in several places was not changed. So thanks for pointing that out.

I looked through that today. I believe the old code residing in these functions has to go
void updatepushbuttons(void );
void updaterotaryencoder(void);
void updatejogging(void);

No change is necessary to
void updateirremote()

I will code that very soon. My time is split at present gearing up for release of mysqm+ version 133 and myesp32db release 021. This is an issue for me because it takes my aging brain a little time to catch-up - remember when I switch back to another project that I have not looked at for some time. So my mistakes tend to be increasing more as the months pass.

Regards
Robert

[Vincenzo Amarante]

Hi Robert, first of all Merry Christmas and all the best for you and your family. I understand and in any case congratulation for your amazing work devoted to the community. I'm intrigued in both mysqm and myesp32 and probably I'll try to build them too.
If you need some help in testing let me know, I dont' have so much free time but I' can do something for sure.
Thanks again, best regards, Vincenzo