Topics

OnStep version 3

Howard Dutton
 
Edited

The master branch of OnStep has been updated to version 3.0

What was the beta has been promoted to release 2.22.

*** Only experienced users should experiment with the master branch on GitHub, all others should use release 2.22 ***

This new master branch includes a re-design of the configuration system in OnStep along with a TON of refactoring.

Major changes:

1. The Config.xxx.h files are all gone and in their place is a single Config.h file (again.)   Prior configuration files (< FileVersionConfig 3) will not work.
2. I re-named (and in some cases re-designed slightly) the configuration options.  Tons of refactoring across OnStep to make this new design work (a mind numbing task.)  There are no more _ON _OFF parameters-as-#define-names instead there are ON and OFF values that are assigned (which should bring a smile to Khalids face) and all configuration options MUST be present in the Config.h file (this was not the case before.)  There is a much greater level of consistancy and organization of parameters vs. before.
3. The Focusers and Rotator can now (in theory) work with TMC2130 stepper drivers in SPI mode along with current setting control etc.  This is reserved for single SPI buss pin-map designs (all drivers Axis1..5 if present must be TMC SPI.)

Howard Dutton
 
Edited

Part of what makes the new single Config.h file way of doing things ok is that the configuration parameters are validated against the pin-map.

The idea is... if your PCB design/board doesn't support an option the compiler will tell you.  For my PCB designs I use "Aux" pins where a pin may work with more than one configuration option (though only one at a time.)  For these I attempt to check if the Aux pin is assigned and if it's assigned again the compiler will throw an #error telling you which (the last) option caused the conflict.

Not everything is checked but quite a bit is and I will make improvements as we go along here.

pfloyd36069@...
 

I wish i would have waited a few days to order the driver (TMC2100) for my focuser. I would've ordered a TMC2130 instead. Regardless though, this is awesome! I appreciate all you have done with this Howard. 👍

Howard Dutton
 

No PCB design currently supports the SPI mode focusers/rotator yet.  That needs an all SPI driver board.

I have a MaxPCB based design (calling it the MaxTMC) that has a single SPI buss to all four drivers. 

The Mega2560/Ramps/MKS Gen-L with some TMC2130 kits where the included jumper wiring is for a common SPI buss could work in theory but an updated pin-map would be needed.  Validation logic might need a change to allow it also.

Butchf
 

Wow Howard, this is great. Thanks I anxious to give it a try.😊

Great job!!!

Ufuk Sandalci
 

Hi Howard,
I've  just ordered the new MKS GEN L V2.0 which has been designed for TMC2130's which are driven by common SPI bus for all five axis.  I had a strong believe that sooner or later Howard would make the code suitable for this board and here we are :) Probably I will receive the board within some weeks from AliExpress and try OnStep V. 3.

Here is the link for the board in ebay:
https://www.ebay.com/itm/MKS-GEN-L-V2-0-MKS-TFT32-LCD-touching-display-3D-electronic-card-kit-controller-/173234434662
I thank you very much for creating and freely sharing  this extremely successful software. Bravo.

Howard Dutton
 

On Wed, Oct 2, 2019 at 11:37 AM, Ufuk Sandalci wrote:
I've  just ordered the new MKS GEN L V2.0
Support for this has been added, remember it's very experimental though.  It compiles with an TMC2130 in the Focuser1 position, that is all I can say.  I didn't list this pin map since it's new and untested... not that much of anything is tested in the latest OnStep and make no mistake there are changes just about everywhere.

PINMAP MksGenL2

Please verify the Pins.Ramps14.h file to double check my work and report back as you work on this if you get a chance.

Ufuk Sandalci
 

Thank you for this unbelievable fast support Howard. I will surely follow your advices when I get the board. In fact, experimenting is the most exciting part of this project. Thanks a lot.

Gilles Gagnon
 

Great work/changes/improvement!

I have just tested my "bench" configuration consisting of Teensy 4.0, TMC2130 (the TMC5160 have been put in the mount but not live tested yet) with the master branch version 3 and, apart from a few 'operator' problems, everything went well. Not having a web config tool like Khalid's makes it such that you have to be double careful to set the #defines with the appropriate parameters; but I guess a new version of the web config tool will be available some time not too far away.

As far as the 'issues' I encountered, as I said, operator errors. I specified TMC2130 instead of TMC2130_QUIET and was surprised at the chirping noise of the motors plus the fact that they did not seem to run as smoothly as with QUIET. Motors are running somewhat hot but the drivers just get barely warm.

I like very much the layout/order of the parameter definitions as its very logical and makes configuring the file quite easy if you have been working with OnStep even just a little. Another change I appreciated, setting the slew rate in degrees/second instead of the MaxRate value which was counter-intuitive.

Thanks for all those changes.

Gilles Gagnon
 

Forgot to mention, on my bench setup, I am running the TMC2130 using the AXISn_DRIVER_IHOLD, IRUN and IGOTO defines, not the VRef adjustment on the TMC2130, which I set at the prescribed voltage of ~2.5V.

As far as the driver modes are concerned, TMC2130 was the noisest and did not seem to run smoothly with my motors (particularly AXIS1); TMC2130_QUIET was more silent as could be expected but when an AXIS1 (RA) slew was (seemed to be) over but not the AXIS2 (DEC) slew, the RA would continue running by "macro" steps until the DEC slew was over. The best mode as far as noise and smoothness, is the TMC2130_VQUIET; virtually silent, and very smooth running.

I will soon try the Teensy 4.0 and TMC5160 on my mount to see if things behave nicely, and then outside, weather permitting, to test under the stars.

Khalid Baheyeldin
 

On Wed, Oct 2, 2019 at 11:50 AM, Howard Dutton wrote:
The master branch of OnStep has been updated to version 3.0

What was the beta has been promoted to release 2.22.

*** Only experienced users should experiment with the master branch on GitHub, all others should use release 2.22 ***
As a result, the OCG now works for version 2.22 (and maybe 1.1, let me know if you test it).

The OCG does not work with master (3.x) yet, but as it is tested more, I will change the OCG to cater for master.

This new master branch includes a re-design of the configuration system in OnStep along with a TON of refactoring.

Major changes:

1. The Config.xxx.h files are all gone and in their place is a single Config.h file (again.)   Prior configuration files (< FileVersionConfig 3) will not work.
2. I re-named (and in some cases re-designed slightly) the configuration options.  Tons of refactoring across OnStep to make this new design work (a mind numbing task.)  There are no more _ON _OFF parameters-as-#define-names instead there are ON and OFF values that are assigned (which should bring a smile to Khalids face) and all configuration options MUST be present in the Config.h file (this was not the case before.)  There is a much greater level of consistancy and organization of parameters vs. before.
Excellent! Thanks for doing this. I edited the file and stuck in my parameters and everything compiles.
Will let you know when I test it on the mount.

One improvements is cosmetic, but will help a lot: rather than having the description on the same line,
the descriptions should be above the parameter, and a blank line in between. This way, it is readable
on narrow windows for everyone, and also the file is the documentation that we can link to directly,
without having to explain each and every parameter in the Wiki.


// ABCD: This feature does such and such
// Values: ON, OFF
#define ABCD ON

// AXIS1_STEPS_PER_DEGREE: This other feature does so and so
// Values 333.0 to 128000.0
#define AXIS1_STEPS_PER_DEGREE 12800.0

I am volunteering to do this reformatting. Let me know.

Howard Dutton
 
Edited

On Wed, Oct 2, 2019 at 04:47 PM, Khalid Baheyeldin wrote:
One improvements is cosmetic, but will help a lot: rather than having the description on the same line,
the descriptions should be above the parameter, and a blank line in between. This way, it is readable
on narrow windows for everyone, and also the file is the documentation that we can link to directly,
without having to explain each and every parameter in the Wiki.


// ABCD: This feature does such and such
// Values: ON, OFF
#define ABCD ON

// AXIS1_STEPS_PER_DEGREE: This other feature does so and so
// Values 333.0 to 128000.0
#define AXIS1_STEPS_PER_DEGREE 12800.0

I am volunteering to do this reformatting. Let me know.
Sorry, that would drive me nuts.

One of the things I dislike about looking at OCG output (when helping folks) is that searching for the parameters takes 4x as long.  The first 2x as long because they are out of order vs. the "OEM" files and then another 2x as long due to a lack of compact formatting.

Khalid Baheyeldin
 

I hear ya ...

On the other hand ...
Here is how it looks to me, on a laptop (I don't use any desktop).

http://imgur.com/NgxxKdkl.png

Any smaller font will be very tedious for me. The maximum is 132 columns,
like the good old COBOL days ...

Howard Dutton
 

No big-screen desktop required.  I can view the file fine on a normal resolution (nothing fancy) 15" Laptop in the Arduino IDE, Notepad (with Word Wrap OFF!) etc.

Gilles Gagnon
 

COBOL!?!? I guess that, give or take, we are in the same age group ;-)

I never got to learn COBOL though. APL, RCA 1802 (COSMAC), 6502, 6809 assembly yes... but I digress here, sorry! :-)

As far as the OCG is concerned, I think its a great tool when you don't know what and where parameters need to be changed in the config file(s); particularly when one starts with OnStep. On the other hand, I liked my experience (first time) in changing the version 3 single config file by hand. It was rather painless except in a few places where I was not quite sure what values I could/had to put (e.g. in the config.h vs OCG, do the microstep goto parameter needs to be changed to the same value as the microstep parameter or left to OFF? What value should I put for the slew rate, 1 degree/sec, 2,... , now that there is no MaxRate to set?). Nothing major but I had to experiment... and get the warning or the results that required changes. 

Anyway, thanks to you both Howard and Khalil for putting so much effort and energy into the OnStep project, its very much appreciated.

Howard Dutton
 
Edited

On Wed, Oct 2, 2019 at 06:28 PM, Gilles Gagnon wrote:
I was not quite sure what values I could/had to put (e.g. in the config.h vs OCG, do the microstep goto parameter needs to be changed to the same value as the microstep parameter or left to OFF?
Either will work.

Leave the entire stepper driver Axis1/2 section as-is and the compiler will warn you that the stepper drivers will need to be configured manually.
...put an unsupported stepper driver name in and it'll complain/refuse to compile.
...fix that, but no microstep setting and it'll complain/refuse to compile.
...fix that, but silly microstep setting like 33x and it'll complain/refuse to compile.
...fix that, but use a microstep_goto setting that's > the microstep setting (which you shouldn't do) and it'll complain/refuse to compile.
...fix that, but using TMC2130 drivers and status (fault detection) is enabled for your MiniPCB however SERIAL_B_ESP_FLASHING ON uses the same Aux1 pin and it'll complain/refuse to compile.
...fix that, but enable Focuser1 AXIS4_DRIVER_POWER_DOWN ON so your focuser motor powers off automatically... which on the MiniPCB there is no ENable pin assigned for that task and it'll complain/refuse to compile.

Howard Dutton
 

On Wed, Oct 2, 2019 at 06:28 PM, Gilles Gagnon wrote:
What value should I put for the slew rate, 1 degree/sec, 2,... , now that there is no MaxRate to set?). Nothing major but I had to experiment... and get the warning or the results that required changes.
Correct, there is no MaxRate to set.

SLEW_RATE_BASE_DESIRED

BASE means the "starting point" which for 1 deg/sec... allows 0.5 deg/s to  2 deg/s at runtime (0.5x to 2x.)

DESIRED means the rate you ask for might not be what you get, but it often is, especially on faster hardware.  If the processor can't step fast enough it will automatically lower the rate so you can't crash OnStep by setting too fast a rate.  This check happens at run-time since the calculation is involved.

Naturally your motors/drive need to be able to operate reliably at 2x the desired rate.

Gilles Gagnon
 

Thanks for your information, all very helpful.

One last interrogation on my side, is there any document (Trinamic spec sheets?) or info source to read in order to understand better the selection of the driver currents, AXIS[1,2]_DRIVER_IHOLD, ...IRUN and ...IGOTO, and their impact on the performances of a mount operation (optimization of torque, speed, heat dissipated, etc...)?

I understand that the config will set AXIS[1,2]_DRIVER_IHOLD as AXIS[1,2]_DRIVER_IRUN/2 if #define AXIS[1,2]_DRIVER_IHOLD OFF is used, but I would like to get a better understanding of why IHOLD and IGOTO can benefit from currents different that IRUN which, I assume, should be set close but no higher than the motor RMS current.

Thanks again.

Howard Dutton
 
Edited

On Wed, Oct 2, 2019 at 08:15 PM, Gilles Gagnon wrote:
One last interrogation on my side, is there any document (Trinamic spec sheets?) or info source to read in order to understand better the selection of the driver currents, AXIS[1,2]_DRIVER_IHOLD, ...IRUN and ...IGOTO, and their impact on the performances of a mount operation (optimization of torque, speed, heat dissipated, etc...)?
The Trinamic datasheet describes IHOLD and IRUN but IGOTO is an OnStep thing and they also don't go into why one would use it.  This is up to you and your intended use/design/requirements.  You have options, experiment if you like.

IHOLD can be quite low on most mounts, perhaps the exception would be Dobsonians (etc.) with friction and/or timing belt drives where the mount can try to move the motor.  Worm/wheels don't let that happen so why waste the power.

IRUN and IGOTO can be the same value in many cases (like other stepper drivers do.)

I use IGOTO lower than IRUN with my G11 as the motors have mid band resonance and make noise loose torque if IGOTO is too high but during tracking I keep the current high since this isn't running off of a battery and I want the best possible responsiveness during tracking from those tiny microsteps.

Others with portable setups might want IGOTO higher than IRUN to save power when running on a battery.  Especially if the reduction ratio is on the higher side and the motors don't suffer from mid-band resonance.

Howard Dutton
 

If using TMC2130/5160 stepper drivers with this version of OnStep be sure to update to the very latest (at a minimum 3.0d.)

There were TMC SPI driver setup errors in the code.