×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Driver OnStep (LX200 like) for INDI

  • Posts: 452
  • Thank you received: 71
Hi James,

I agree from a technical standpoint, speed control is not necessary.
But soon or later one will come and ask why it is not feasible since OnStep allows it!
And now that DC motor is supported I am pretty sure many people will go for that since it far cheaper, and does the job (I went to stepper because OnStep didn't support DC!)

At least the situation where we are now allows anybody to use the focuser within Ekos and that is the most important.

As we say ... Rome wasn't built in one day!
5 years 1 month ago #35384

Please Log in or Create an account to join the conversation.

  • Posts: 452
  • Thank you received: 71
@all

It is abit complicated for me to follow and keep track in an efficient manner of all the reports and suggestions concerning the Driver.
Using Indi's GitHub issues was an option but I think we shoudnn't use it for "loud thoughts".
So finally I beleive the " OnStep Fork " is the right place to use since it will use only OnStep user's time.

@James,
I believe your Focuser Interface is at the right place since it is more indi related than pure OnStep, but leave up to you to open an issue as reference.

Regards
5 years 2 weeks ago #36325

Please Log in or Create an account to join the conversation.

  • Posts: 68
  • Thank you received: 2
Hello everyone !

Thank you again for the great job you all did on the indi_onstep driver!
Bravo, without you we never had a driver for indi !!!!

I come to solicit you again to create a new driver that will be a copy of the driver indi_onstep but slightly modified.
The goal would be to create the indi_teenastro driver!

The developer is ready to help and then to maintain it.

Unfortunately I can not help because I already develop the "NAFABox": github.com/Patrick-81/NAFABox

The project teenastro is a project of simplification and personalization of Onstep to make it accessible to the greatest number.
link: github.com/charleslemaire0/TeenAstro
5 years 1 week ago #36508

Please Log in or Create an account to join the conversation.

  • Posts: 452
  • Thank you received: 71
@Dragonlost,

looks a nice project too.
Unfortunately I am still busy with my observatory, still not motorized ... :-(
An many other things on the fire (Retired people never have time :-)
I will take a look on Teenastro at least to see how it is similar in terms of protocol.

Regards
5 years 1 week ago #36527

Please Log in or Create an account to join the conversation.

  • Posts: 322
  • Thank you received: 31

I personally think that instead of effectively forking OnStep into many projects and many drivers, it is better for us to convince Howard to move OnStep to a more friendly and simpler configuration. I wrote the Online Configuration Generator as one way to avoid editing the files. Me, as well as Charles, have advocated for this.

For example, instead of compile time values, we should have things that are run time (e.g. mount type: GEM, Alt-Az, Fork, ...etc.; motor steps per rotation, GR1, GR2, worm wheel steps per rotation). Using a USB tool (a Python program on the desktop, or the SHC), these values are configured, and Steps Per Degree, ...etc. are all calculated internally).

Charles even wrote a Teensy program loader.

Howard so far has been reluctant to entertain the idea. However, with enough voices calling for these changes, perhaps he will be convinced.

If we have this, we can have one universal binary for each MCU architecture and users will not even have to install the Arduino IDE at all.

Instead of addressing the symptom, let us go for the root cause.
5 years 1 week ago #36537

Please Log in or Create an account to join the conversation.

  • Posts: 322
  • Thank you received: 31
Anyone else facing issues with the latest packages from Jasem's repository?

I got this a week ago: indi-bin 1.7.7~201904141646~ubuntu18.04.1

When using OnStep as the driver, the refresh on KStars and CdC is very sluggish (lags by 5 seconds or so).

When I change the driver to LX200 Basic, everything works fine.

Any ideas what changed?
4 years 11 months ago #38135

Please Log in or Create an account to join the conversation.

  • Posts: 322
  • Thank you received: 31

Found the problem.

This is a process trace of the INDI driver.
15:14:12.543819 write(7, ":GXE9#", 6)   = 6 <0.000026>
15:14:12.543911 select(8, [7], NULL, NULL, {tv_sec=5, tv_usec=0}) = 1 (in [7], left {tv_sec=4, tv_usec=992207}) <0.007815>
15:14:12.551801 read(7, "0", 1)         = 1 <0.000020>
15:14:12.551872 select(8, [7], NULL, NULL, {tv_sec=5, tv_usec=0}) = 0 (Timeout) <5.005051>
15:14:17.557040 ioctl(7, TCFLSH, TCIFLUSH) = 0 <0.000048>
15:14:17.557213 write(7, ":GXEA#", 6)   = 6 <0.000036>
15:14:17.557384 select(8, [7], NULL, NULL, {tv_sec=5, tv_usec=0}) = 1 (in [7], left {tv_sec=4, tv_usec=992396}) <0.007623>
15:14:17.565092 read(7, "0", 1)         = 1 <0.000017>
15:14:17.565151 select(8, [7], NULL, NULL, {tv_sec=5, tv_usec=0}) = 0 (Timeout) <5.005136>

You can see that the :GXEA and :GXE9 commands above are timing out, after 5 seconds each.

They are for getting minutes past meridian east and west.

This configuration is for a fork mount, and the INDI driver requests this information regardless of the mount type.

So, the driver must check GU's output and only do these commands if there is an E in it, otherwise, these commands should not be issued at all.
4 years 11 months ago #38142

Please Log in or Create an account to join the conversation.

  • Posts: 174
  • Thank you received: 27
Hi All,

I implemented a new feature in INDI driver: support for driving output ports.
It adds a new tab "Outputs" which allows entering values for 10 outputs.
Both binary and analog values can be passed to Onstep controller.
Onstep will interpret the values accordingly:
  • if output is binary, then any value above 0 will toggle the output to high
  • if output is analogy, the analog output will be set per the input value
With my RAMPS based Onstep I can toggle output 6 as binary and set values between 0 and 255 on port 7.
This code intentionally does not impose any validations on values, passed to Onstep in order to support future enhancements in Onstep, e.g. implement more than 8-bit resolution.

I see that someone already started working on a similar concept, which introduces a couple of toggle switches, but looks like it is not finished. I used the same tab in INDI UI for my feature.

Here is a pull request for this change:
github.com/indilib/indi/pull/926

Please review, test and merge.

Alex
The following user(s) said Thank You: Jasem Mutlaq, dolguldur
4 years 11 months ago #38202

Please Log in or Create an account to join the conversation.

  • Posts: 452
  • Thank you received: 71
Alex,

thank you for the Output tab implemen,tation.
Could you please explain how to use this feature?
and how to set-up on Onstep side?

Thanks
4 years 11 months ago #38395

Please Log in or Create an account to join the conversation.

  • Posts: 174
  • Thank you received: 27
Alaine,

Using this feature is very simple: enter a number into a box and push the set button. As a result of it, the following command would be sent to OnStep:
:SXG7,10#
where 7 is port and 10 is value to be sent there.
The ports to be used are board specific. My Ramps based board has PWM analog output on port 7. I use this output for driving flat panel so I can change the brightness of it.
I have no idea which ports are available on other boards.

Here is the corresponding code in OnStep in Command.ino:
if (parameter[0]=='G') { // Gn: General purpose output
          long v=(double)strtol(&parameter[3],NULL,10);
          if ((v>=0) && (v<=255)) {
#ifdef Aux0
            if (parameter[1]=='0') { valueAux0=v; static bool init=false; if (!init) { pinMode(Aux0,OUTPUT); init=true; } if (v==0) digitalWrite(Aux0,LOW); else digitalWrite(Aux0,HIGH); } else
#endif
#ifndef MODE_SWITCH_BEFORE_SLEW_SPI
#ifdef Aux1
            if (parameter[1]=='1') { valueAux1=v; static bool init=false; if (!init) { pinMode(Aux1,OUTPUT); init=true; } if (v==0) digitalWrite(Aux1,LOW); else digitalWrite(Aux1,HIGH); } else
#endif
#ifdef Aux2
            if (parameter[1]=='2') { valueAux2=v; static bool init=false; if (!init) { pinMode(Aux2,OUTPUT); init=true; } if (v==0) digitalWrite(Aux2,LOW); else digitalWrite(Aux2,HIGH); } else
#endif
#endif
#ifdef Aux3
            if (parameter[1]=='3') { valueAux3=v; static bool init=false; if (!init) { pinMode(Aux3,OUTPUT); init=true; }
  #ifdef Aux3_Analog
              analogWrite(Aux3,v); } else
  #else
              if (v==0) digitalWrite(Aux3,LOW); else digitalWrite(Aux3,HIGH); } else
  #endif
#endif
#ifdef Aux4
            if (parameter[1]=='4') { valueAux4=v; static bool init=false; if (!init) { pinMode(Aux4,OUTPUT); init=true; }
  #ifdef Aux4_Analog
              analogWrite(Aux4,v); } else
  #else
              if (v==0) digitalWrite(Aux4,LOW); else digitalWrite(Aux4,HIGH); } else
  #endif
#endif
#ifdef Aux5
            if (parameter[1]=='5') { valueAux5=v; static bool init=false; if (!init) { pinMode(Aux5,OUTPUT); init=true; }
  #ifdef Aux5_Analog
              analogWrite(Aux5,v); } else
  #else
              if (v==0) digitalWrite(Aux5,LOW); else digitalWrite(Aux5,HIGH); } else
  #endif
#endif
#ifdef Aux6
            if (parameter[1]=='6') { valueAux6=v; static bool init=false; if (!init) { pinMode(Aux6,OUTPUT); init=true; }
  #ifdef Aux6_Analog
              analogWrite(Aux6,v); } else
  #else
              if (v==0) digitalWrite(Aux6,LOW); else digitalWrite(Aux6,HIGH); } else
  #endif
#endif
#ifdef Aux7
            if (parameter[1]=='7') { valueAux7=v; static bool init=false; if (!init) { pinMode(Aux7,OUTPUT); init=true; }
  #ifdef Aux7_Analog
              analogWrite(Aux7,v); } else
  #else
              if (v==0) digitalWrite(Aux7,LOW); else digitalWrite(Aux7,HIGH); } else
  #endif
#endif
#ifdef Aux8
            if (parameter[1]=='8') { valueAux8=v; static bool init=false; if (!init) { pinMode(Aux8,OUTPUT); init=true; }
  #ifdef Aux8_Analog
              analogWrite(Aux8,v); } else
  #else
              if (v==0) digitalWrite(Aux8,LOW); else digitalWrite(Aux8,HIGH); } else
  #endif
#endif
#ifdef Aux9
            if (parameter[1]=='9') { valueAux9=v; static bool init=false; if (!init) { pinMode(Aux9,OUTPUT); init=true; } if (v==0) digitalWrite(Aux9,LOW); else digitalWrite(Aux9,HIGH); } else
#endif
4 years 11 months ago #38423

Please Log in or Create an account to join the conversation.

  • Posts: 161
  • Thank you received: 39
Do note that the reason that I stopped with the implementation, and I'm a little confused as to why this went in upstream, is:

THERE ARE NO CHECKS ON IF THE PIN IS IN USE. Aux pins ARE used for other things as well, so this has the potential to screw up OnStep, or things connected if you mess up what you are outputting to.

The best Idea I have is that this should be encapsulated with a control turning it on that's basically a warning to that effect. Or we should see what board it is (currently not possible, but I've got a branch I worked on yesterday that should work for that, so we can make it as safe as possible, ie, heaters/etc on RAMPS, etc.)
4 years 11 months ago #38440

Please Log in or Create an account to join the conversation.

  • Posts: 174
  • Thank you received: 27
James,
I think the implemented approach is very safe - even though commands for driving outputs can be sent to the controller for all Aux ports, I don't think any damage can be done because processing the output command is surrounded by #ifdefs like this:
#ifdef Aux7
            if (parameter[1]=='7') { valueAux7=v; static bool init=false; if (!init) { pinMode(Aux7,OUTPUT); init=true; }
  #ifdef Aux7_Analog
              analogWrite(Aux7,v); } else
  #else
              if (v==0) digitalWrite(Aux7,LOW); else digitalWrite(Aux7,HIGH); } else
  #endif
#endif

These #defines are set appropriately in the Pins header files, e.g. in Pins.Ramps14.h we can see the following:
// The multi-purpose pins (Aux3..Aux8 can be analog (pwm/dac) if supported)
#define Aux0          11
#define Aux1          29
#define Aux2          37
#define Aux3          62
#define Aux4          24
#define Aux5          30
#define Aux6           8    // heater
#define Aux7           9    // heater, analog (pwm)
#define Aux7_Analog
#define Aux8          10    // heater, analog (pwm)
#define Aux8_Analog
#define Aux9          39    // general purpose
#define Aux10         41
#define Aux11         43
#define Aux12         45
#define Aux13         47
#define Aux14         32

whereas in Pins.MaxESP2.h we see this:
#define Aux3          21    // Home SW for Axis1 (or I2C SDA)
#define Aux4          22    // Home SW for Axis2 (or I2C SCL)
//#define Aux5          "V0"  // Virtual Aux Pin0 (usually maps to AXIS1_ENC_A_PIN)
//#define Aux6          "V1"  // Virtual Aux Pin1 (usually maps to AXIS1_ENC_B_PIN)
#define Aux7          39    // Limit SW, Status LED2, Reticule, etc.
#define Aux8          25    // Status LED, PPS, Tone, etc.

So based on this, I think that the implementation is very safe.

Alex
4 years 11 months ago #38463

Please Log in or Create an account to join the conversation.

Time to create page: 1.137 seconds