Topics

DEC Axis Homing problem....


Martin Bonfiore
 

I am running Onstep 22.h on an STM32 Blue Pill board.  I just finished adding home switches (feeding PB8 and PA13).  I have set the config.h correctly (I believe) and have tried various combinations of HIGH and LOW on the two Axes config sense variables to not avail.  The switches I am using are opto-interrupters such that the when the flag interrupts the beam, the output goes LOW, when the beam is open, the outputs go HIGH.   The flags subtend 180 degrees out of the 360 circle.  There are 2.4 K pullups on both opto-interrupters...I have measured their outputs with a DVM at their outputs and they swing from a few millivolts when LOW to 5 volts when HIGH.  

The problem is that while the RA axis works consistently, the DEC axis only seems to work when its flag interrupts the beam i.e. the output of the interrupters is HIGH.  When the DEC axis starts off with the flag out of the beam, a command to home results in a very short jog...maybe a couple of degrees or so...but it does not continue and reach the home flag transition edge.  This problem sounds somewhat like what another poster is wrestling with.  

Any ideas appreciated.  TIA.


Curly
 

Hi Martin 
I’ve given up trying to sort my home switches. OnStep flatly ignores the dec switch once the RA switch triggers. Or as you say moves a few degrees and stops of its own accord. Setting low or high changes the direction it turns without ever sensing the switch trigger. Mine are mechanical normally open switches fitted as std to the cge Pro. I’ve fitted new switches to both axis and totally rewired the mount but dec just doesn’t work. I’ve built 2x maxpcb v2 and v3.5 and neither work, I’ve added caps and pull-ups tried high low you name it it doesn’t work.
 Funny thing is when I first fitted OnStep to my mount I used a T4 on a Minipcb2 with a hacked pin map to add gps and home switches and it worked perfectly. I can’t remember exactly what I did but I think I made aux 6 and 7 home switches and left limit and reticle on 3 and 4 but anyway it worked with exactly the same wiring and switches on the mount that now don’t work with the max boards. 
 I wanted to keep OnStep updates straight forward so built a max board that included home switches but never got it to work. 
Would be nice to get an answer on this? Has anybody else got working home switches?
Curly

On Sat, 9 Jan 2021 at 18:19, Martin Bonfiore <marsbonfire0@...> wrote:
I am running Onstep 22.h on an STM32 Blue Pill board.  I just finished adding home switches (feeding PB8 and PA13).  I have set the config.h correctly (I believe) and have tried various combinations of HIGH and LOW on the two Axes config sense variables to not avail.  The switches I am using are opto-interrupters such that the when the flag interrupts the beam, the output goes LOW, when the beam is open, the outputs go HIGH.   The flags subtend 180 degrees out of the 360 circle.  There are 2.4 K pullups on both opto-interrupters...I have measured their outputs with a DVM at their outputs and they swing from a few millivolts when LOW to 5 volts when HIGH.  

The problem is that while the RA axis works consistently, the DEC axis only seems to work when its flag interrupts the beam i.e. the output of the interrupters is HIGH.  When the DEC axis starts off with the flag out of the beam, a command to home results in a very short jog...maybe a couple of degrees or so...but it does not continue and reach the home flag transition edge.  This problem sounds somewhat like what another poster is wrestling with.  

Any ideas appreciated.  TIA.


Howard Dutton
 

I checked the master and it had a little bug/typo in the axis2 guide routine that caused that axis to not respond to the command to start the homing motion on that axis.  Fixed now.  We all know not to use the master unless you are ready to accept a bit of instability.

The beta didn't have that issue and worked fine.
For release-3.16 I'm not wasting my time testing that as it not working WRT this is unlikely, to say the least.

I tested the master and beta using a MaxSTM3.6 board.  The design there is nothing fancy just its TVS protection devices (same as used on the MaxPCB3.6 BTW) and using MCU internal pull-up resistors with the lever switches on the mount.

Prior use with release-3.16 and a fair way along in the work on version 4 was with a MaxESP3 board.  Pretty sure I checked out a MaxPCB2 for this earlier too.  All using the default pinmap assigned home switch locations.


Martin Bonfiore
 

Howard,
thanks for fixing.  I will load up and test my setup...now, can you look into getting us some clear weather?🙂


Curly
 

Thanks Howard, is this also relevant to my issue on the cge Pro?
Fixed now.  We all know not to use the master unless you are ready to accept a bit of instability.
I am running 4.20o did this include the issue? Should I update to the beta? 
I was advised by your good self to install the master as 3.16 was crashing the teensy4 on connecting.

On Tue, 12 Jan 2021 at 12:48, Martin Bonfiore <marsbonfire0@...> wrote:
Howard,
thanks for fixing.  I will load up and test my setup...now, can you look into getting us some clear weather?🙂


Howard Dutton
 

On Tue, Jan 12, 2021 at 06:09 AM, Curly wrote:
I was advised by your good self to install the master as 3.16 was crashing the teensy4 on connecting.
My bad, I should know better.


Curly
 

Haha yes you should ;)
In W hich version do you think the error crept in? Thinking about it I think I maybe running 4.22o. So which version would you recommend I install? 
Thanks for all your time I appreciate it. 

Martin, I’m looking forward to seeing if this fixes your mount please keep us updated. 
Curly 

On Tue, 12 Jan 2021 at 14:28, Howard Dutton <hjd1964@...> wrote:
On Tue, Jan 12, 2021 at 06:09 AM, Curly wrote:
I was advised by your good self to install the master as 3.16 was crashing the teensy4 on connecting.
My bad, I should know better.


Martin Bonfiore
 

Unfortunately I won’t have access to my mount until this coming weekend to do test...stay tuned


Khalid Baheyeldin
 

On Tue, Jan 12, 2021 at 07:48 AM, Martin Bonfiore wrote:
now, can you look into getting us some clear weather?🙂
The Clouds Be Gone (CBG) feature will be in master (5.x), but you have to wait till April 1st for it.
Before that, Howard is working on Light Pollution Elimination (LPE) feature ...


Howard Dutton
 

On Tue, Jan 12, 2021 at 07:15 AM, Curly wrote:
In W hich version do you think the error crept in?
Thinking about it I think I maybe running 4.22o.
5.1g

So which version would you recommend I install? 
The master branch isn't static, it evolves.  At times the master branch is stable and fairly safe, now isn't one of those times.

The Beta branch will become release-4.xx and is essentially what you're using now with some fixes and (not too risky) new features thrown in.


Curly
 

Thanks Howard,
It looks like my version 4.22o is not affected and looking at Martin’s post he is running 22h which I guess is 4.22h? So the error in the master is not his issue either. Funny we both have the same issue but with different trigger methods, optical verses mechanical switches and only affects the dec axis. 


On Tue, 12 Jan 2021 at 22:01, Howard Dutton <hjd1964@...> wrote:
On Tue, Jan 12, 2021 at 07:15 AM, Curly wrote:
In W hich version do you think the error crept in?
Thinking about it I think I maybe running 4.22o.
5.1g

So which version would you recommend I install? 
The master branch isn't static, it evolves.  At times the master branch is stable and fairly safe, now isn't one of those times.

The Beta branch will become release-4.xx and is essentially what you're using now with some fixes and (not too risky) new features thrown in.


Howard Dutton
 
Edited

I'd update to the latest Beta and turn on the verbose logging, perhaps that would provide a clue.

My mount during another test this morning:

07:35:43.151 -> MSG: Homing started phase 1
07:36:14.323 -> MSG: Homing limit detected, stopping guide on Axis1
07:36:46.294 -> MSG: Homing limit detected, stopping guide on Axis2
07:36:47.245 -> MSG: Homing started phase 2
07:36:54.036 -> MSG: Homing limit detected, stopping guide on Axis1
07:36:55.597 -> MSG: Homing limit detected, stopping guide on Axis2
07:36:56.003 -> MSG: Homing done


Martin Bonfiore
 

I am not surprised the trigger method does not have bearing on the problem...as far as the SW, a switch is a switch, optical,mechanical,magnetic,other.  that said, we both may be experiencing signal integrity issues...noise, switch “bounce”, crosstalk....though I don’t think it is the likely root cause.


The fact that we are both having dec axis issues with similar behaviors suggests to me more than coincidence.  I am itching to try the beta version, probably on Saturday.


Howard Dutton
 
Edited

On Wed, Jan 13, 2021 at 08:19 AM, Martin Bonfiore wrote:
The fact that we are both having dec axis issues with similar behaviors suggests to me more than coincidence.  I am itching to try the beta version, probably on Saturday.
There is certainly more potential for an unknown issue in an earlier version 4.x  leading up to the current Beta.  The current Beta is tested and known to work for at least myself.

The current Master has significant changes to how home switch detection works at the request of a CEM70 OnStep user who needed analog sensing w/deadband, thresholds, etc.  That was all rolled up into a class that transparently handles digital input or analog input.  Then said class was also used for limit sense and PEC sense.  He tested this new home sense support and had success getting it working.  As I said the master also worked in my tests.

Again, I advise to use the DEBUG VERBOSE mode and see what it says.  It can potentially provide feedback about why the find home operation wasn't carried out successfully.


Howard Dutton
 
Edited

On Wed, Jan 13, 2021 at 10:47 AM, Howard Dutton wrote:
The current Master has significant changes to how home switch detection works at the request of a CEM70 OnStep user who needed analog sensing w/deadband, thresholds, etc.  That was all rolled up into a class that transparently handles digital input or analog input.  Then said class was also used for limit sense and PEC sense.  He tested this new home sense support and had success getting it working.  As I said the master also worked in my tests.
I figure the new master home sw features aren't confusing enough so I added a third homing phase.

  • Phase1 moves at guide rate 7 in the direction of the home switches and stops as they are encountered.  This is fairly fast and overshoots the switches.
  • Phase2 moves at guide rate 6 in the direction of the home switches and stops as they are encountered.  This is slower and moves back toward the switches then doesn't overshoot much before stopping.
  • Phase3 (new) does a final timed guide according to user settings (four of them one for each axis and each direction) to trim the final position.
    • Defaults are 0 so it does nothing, adjust as you like these are in ms and it moves at 2 arc-minutes/second.  Negative values move in the opposite direction (i.e. _E set to -1000 moves 2 arc-minutes West.)
      • #define HOME_AXIS1_TRIM_TIME_E 0
      • #define HOME_AXIS1_TRIM_TIME_W 0
      • #define HOME_AXIS2_TRIM_TIME_N 0
      • #define HOME_AXIS2_TRIM_TIME_S 0

I also added to the analog digital switch class switch bounce protection.  So home switches have a default 10ms window where the polled signal must be stable before being recognized as valid.

Basic testing done and working on my mount.


Martin Bonfiore
 

4.22h gives success messages in verbose mode even though dec home is not found and there is no dec movement when dec flag starts in position that returns High to controller.  Works fine when dec starts in flag returning Low position.

5.1o works just fine...will stick with it. 


Howard Dutton
 

On Sat, Jan 16, 2021 at 11:07 AM, Martin Bonfiore wrote:
4.22h gives success messages in verbose mode even though dec home is not found and there is no dec movement when dec flag starts in position that returns High to controller.  Works fine when dec starts in flag returning Low position.

5.1o works just fine...will stick with it. 
AFAIK the only relevant difference between the two is that 5.1o has switch de-bouncing.


Martin Bonfiore
 

Interesting.  During the homing on the dec axis there is no nominal switch transition since the axis is not moving and its flag is no where near the opto interrupter.  If I understand the switch debounce it would also serve to filter out noise spikes.  In my case that would suggest that a noise source is coupling into the dec sensor line and causing a false trigger when the dec axis starts in the LOW state I.e. the output NPN transistor is turned on and holding the line LOW.  This suggests noise spikes on the ground line...I am guessing possibly inductively coupled inside the controller box since there are no lines that switch inside of the cable that carries the home sense signals and 5 volt power.  
I may revert back to 4.22h and play around with the grounding and cable dress and may add ferrites and maybe small filter caps.  I would prefer to solve the signal integrity issue rather than count on a filter.


 


Martin Bonfiore
 

My intuition was incorrect...it definitely looks like a noise pickup issue in my setup.  I reverted from 5.1o (which works with my setup) back to 4.22h which exhibits the failure to home on the DEC axis. 

I then added an R/C filter immediately adjacent to where the DEC home signal enters the STM32 (at the four pin header...PA13)...so 1K resistor in series; 0.47 uf cap between the PA13 pin and the ground pin on the four pin header.  The homing now works properly on 4.22h. 

Howard's SW addition of the debounce filter appears to have addressed the root cause (noise) in my setup. 

What remains interesting and possibly a coincidence is why Curly's system shows a very similar behavior?? 

I am also curious where the noise is getting coupled into my setup.  My current guess is that even though the Home signals travel on their own cable there is a small but possibly significant area where the signal cable passes near the wiring to the RA stepper motor (an artifact of how I mounted the cable connectors in my setup).  

Thanks again to Howard.


Mike Ahner
 

Hi Martin, I wonder if it's picking up noise or just needs a Pullup resistor at the STM32 module? It seems your pullups are at the opto-isolators and depending on where they're located, the line might still be floating. That could explain why Curly has the same issue. Did you measure the voltage at the four pin header on the STM32 or at the opto-isolators? The internal STM32 pullups may not be strong enough in this case.

Either way, good work finding a solution.