Feature Request - Encoder input for ustepper addonboard

[adamfilip]

I am using a Ustepper add on board for my Nema 17 stepper motors to basically turn them into simple servos. The ustepper has an encoder to track stepper positon, The ustepper board is just a small arduino board mounted on top of a stepper motor

Can Encloder input support be added? Marlin : analogRead, uStepper : analogWrite

more info available at http://www.ustepper.com/index/ I have attached sample code for the ustepper to work with my Rumba controler for my 3d printer. uStepper_Hanin.txt

[Roxy-3D]

I opened the .txt file in notepad and it looked like some C code that needed to be Pretty Printed!

[adamfilip]

yes sorry, this was the code for the ustepper to work with Marlin on a rumba

#include <uStepper.h>

uStepper stepper;
int P2;                                       //uStepper_pin_2 (Rumba_enable_pin)
int P4;                                       //uStepper_pin_4 (Rumba_direction_pin)
volatile int P3;                              //uStepper_pin_3_INT1 (Rumba_step_pin)

void setup()
{
    stepper.setup();                          //uStepper_setup
    pinMode(2,INPUT);                         //////////////////////////////
    pinMode(4,INPUT);                         //    uStepper_pin_mode     //
    pinMode(3,INPUT);                         //////////////////////////////
    attachInterrupt(1,step_rising,RISING);    //uStepper_pin_3_INT1_hardware interrupt
    attachInterrupt(1,step_falling,FALLING);  //                  **    
}

void loop()
{
    P2=digitalRead(2);
    P4=digitalRead(4);
    if(P2==HIGH)                              //
    {
        digitalWrite(ENA,HIGH);               //A4988 stepper driver_enable_pin
    }
    else
    {
        digitalWrite(ENA,LOW);
    }
    if(P4==HIGH)                              //
    {
        digitalWrite(DIR,HIGH);               //A4988 stepper driver_direction_pin
    }
    else
    {
        digitalWrite(DIR,LOW);
    }
}

void step_rising()                            //
{
    P3=digitalRead(3);
    if(P3==HIGH)
    {
        digitalWrite(STEP,HIGH);              //A4988 stepper driver_step_pin
    }
    else
    {
        digitalWrite(STEP,LOW);
    }
}

void step_falling()                           //
{
    P3=digitalRead(3);
    if(P3==HIGH)
    {
        digitalWrite(STEP,HIGH);              //
    }
    else
    {
        digitalWrite(STEP,LOW);
    }
}

[Blue-Marlin]

Can Encloder input support be added?

Likely it could be done. But not with analogWrite(). A resolution of 256 positions would be too disappointing.

[jbrazio]

To get the position:

float getPos()
{
  float degree = 0.0;
  WRITE(SS, LOW);
  result1 = SPI.transfer(0xff);
  result2 = SPI.transfer(0xff);  
  WRITE(SS, HIGH);
  result1 &= 0b00111111;
  result1 <<= 8;
  result = (result1 | result2) >> 1;
  result &= 0xFFF;
  degree = ((float)result)/4096.0;
  degree *= 360.0;
  return degree;
}

I wonder what would be the resolution of this Hall effect sensor, do you have an idea ? It's very clever the magnet attachment and the overall board form factor.

[thinkyhead]

(P.S., developers. If you're not familiar with the attachInterrupt function in Arduino, this would be a good time for us to get to know it. We can use it to set our ISR functions directly instead of having a static method call inside the ISR() declaration. But maybe Stepper::isr is already getting magically inlined…?)

[thinkyhead]

A resolution of 256 positions would be too disappointing.

Maybe I misunderstand the reason why. But it seems like it should be just fine if we're only concerned that the stepper was rotated by some fraction of a revolution. Then we can just take the difference in position since the last time it was read and apply that. This assumes that the range of values that it sends is guaranteed to be 0-255… But I assume all this logic is handled by the Ustepper board.

[bobc]

Surely the idea of ustepper is that it handles the position error, so that Marlin does not have to. The sample code posted for ustepper above isn't any sort of servo code, it just passes the control signals to the A4988 which is not adding anything useful.

[jbrazio]

Which ISRs are currently being in use by Marlin ?

I've found for stepper:

• ISR(TIMER1_COMPA_vect)
• ISR(TIMER0_COMPA_vect)

For temperature:

• ISR(TIMER0_COMPB_vect)

And @Blue-Marlin's favorite, watchdog:

• ISR(WDT_vect)

Am I missing something, weren't the "analog reads" done by an ISR/timer also ?

[Roxy-3D]

P.S., developers. If you're not familiar with the attachInterrupt function in Arduino, this would be a good time for us to get to know it.

Can we attach an interrupt to the Encoder Dial so we don't have to burn so much processing power to watch for a turn? And the same question would apply to the pin lcd_clicked() is watching. It would be nice if we could just wait for an interrupt and not have to spend time watching for lcd panel activity.

[jbrazio]

Roxy, yup we can.. but that's not a thing for RC !

[Roxy-3D]

Roxy, yup we can.. but that's not a thing for RC !

I agree! But if we can do this, it will save us some processing power and maybe extend the life of the 8-bit processors for a little bit longer. We should try to address this in a Development Branch when we get a chance.

[thinkyhead]

analog reads" done by an ISR/timer also

The temperature ISR does this currently.

[thinkyhead]

Can we attach an interrupt to the Encoder Dial…?

Not only that, but we could perhaps figure some way to to Hardware PWM. But I think this is a challenge when supporting so many boards, and we still need to get the legendary HAL in place.

[adamfilip]

I had a developer from ustepper check the code they suggested the following instead. with the comment "The only big issue with your code is that an arduino cannot have two different interrupt routines attached to an external interrupt as is the case in your code. Instead i have attached an interrupt routine to fire at any change (both rising and falling edge) and then just flip the step pin according to the input."

#include <uStepper.h>

uStepper stepper;                           

void setup()
{
    stepper.setup();                          //uStepper_setup
    pinMode(2,INPUT);                         //////////////////////////////
    pinMode(4,INPUT);                         //    uStepper_pin_mode     //
    pinMode(3,INPUT);                         //////////////////////////////  
}

void loop()
{
    if(digitalRead(2)==HIGH)                  //uStepper_pin_2 (Rumba_enable_pin)
    {
        digitalWrite(ENA,HIGH);               //A4988 stepper driver_enable_pin
    }
    else
    {
        digitalWrite(ENA,LOW);
    }

    if(digitalRead(4)==HIGH)                  //uStepper_pin_4 (Rumba_direction_pin)
    {
        digitalWrite(DIR,HIGH);               //A4988 stepper driver_direction_pin
    }
    else
    {
        digitalWrite(DIR,LOW);
    }
}

    void step_change()                          //
    {
        if(digitalRead(3)==HIGH)                //uStepper_pin_3_INT1 (Rumba_step_pin)
        {
            digitalWrite(STEP,HIGH);            //A4988 stepper driver_step_pin
        }
        else
        {
            digitalWrite(STEP,LOW);
        }
    }

[thinkyhead]

So in essence…

void loop() {
  WRITE(ENA, READ(2));  // Write A4988 stepper driver_enable_pin from uStepper_pin_2 (Rumba_enable_pin)
  WRITE(DIR, READ(4));  // Write A4988 stepper driver_direction_pin from uStepper_pin_4 (Rumba_direction_pin)
}

void step_change() {
  WRITE(STEP, READ(3));  // Write A4988 stepper driver_step_pin from uStepper_pin_3_INT1 (Rumba_step_pin)
}

[adamfilip]

I received an update from ustepper.

Currently, no code is implemented in the uStepper library for error correction. This means that currently, if the user of the uStepper wishes to do error corrections in case of lost steps, they will have to implement it themselves. However, I will be working on this particular feature during the summer, and have it incorporated into the currently implemented stepper algorithm, such that this is handled automatically by the uStepper.

Also, I think you are on to something about integrating the uStepper with marlin, and I have some ideas about how this would ideally be done:

In my opinion, the controller running the marlin software should handle everything other than driving the motors (e.g. LCD, Gcode parsing, trajectory calculations etc.). The uSteppers attached to the 3d-printer (or whatever machine), should be connected with each other through some communication bus (I am think SPI) The Marlin controller would then send calculated trajectories, with information about how each stepper should move, to one of the uSteppers (acting as a master). This master uStepper will then be in charge of distributing this information among the other uSteppers, meaning that each uStepper will be in charge of applying driving signals to the attached motor.

The above requires that a multiaxis feature is implemented for the uStepper, which I am also going to be working on during the summer.

[thinkyhead]

It will be interesting to see how it develops. Are the units in current production worth supporting? It seems like we should wait until the error-correction is improved before finalizing. But we could get a start on the feature if the interface isn't going to change much.

[uStepperOld]

Hi,

As mentioned earlier in this thread, we have been working on implementing closed loop control into the uStepper, utilizing the encoder for correction in case of lost steps. We are still in the early stages, but so far we have implemented a simple algorithm where the uStepper works as a drop-in replacements of the stepsticks in a 3d printer controller board, as can be seen in the following video:

https://www.youtube.com/watch?v=wp6koQZXqkw&feature=youtu.be

In the video the step/dir signals generated by the marlin software are wired to the uStepper, which then uses these signals to drive the motor with its onboard driver chip. Whenever the motor loses steps, or gets out of position, the uStepper bypasses the steps generated by marlin and takes control until the correct position commanded is obtained, once again.

The code is not ready for release yet, however we are confident that it will be no later than the end of august.

furthermore, we are going to work on implementing a closed loop algorithm, turning the uStepper into a true servo during the summer, and we expect this feature to be close to finished around mid-end september.

Best Regards, The uStepper Team

[jbrazio]

If we could offload the Marlin ISR and delegate the stepping routine to each stepper.. @uStepper how far can we go and replace the step/dir analog signal by a digital protocol (I2C) between Marlin and uStepper ?

[uStepperOld]

For communication between marlin and uStepper, the SPI bus is prefered over the I2C bus. There are two reasons for this: The encoder on the uStepper is interfaced using the I2C bus, which could complicate things. The SPI bus is alot faster than I2C.

The simplest way to replace step/dir with a digital protocol, would be for marlin to just send a serial stream of packets containing necessary information to perform the move (feedrate, number of steps etc.), for each uStepper.

Each uStepper will then implement Marlin's stepper generation algorithm, while correcting for any loss of steps.

Best Regards, The uStepper Team

[jbrazio]

I was suggesting I2C because we could daisy chain all the steppers on a stepper-bus of some kind and would allow us to broadcast stuff to all the participating steppers.

[uStepperOld]

That makes good sense, and this is quite possible.

[Roxy-3D]

@uStepper Can you consider making a few extra boards to send out for the early testing? I have a Folger Tech i3-2020 that I'm trying to convert to use 3mm filament. Unfortunately, the extruder motor is losing steps occasionally. This might just be the 'right' way to resolve the issue. If I had one of these to plug in to that machine, for sure it would get tested!!!

And with a little more thought... It would seem the 'correct' thing to do for an extruder motor that is losing steps is different than what should happen if an axis loses steps. For an axis motor it would be logical to get all of the axis positioned correctly and then continue. For an extruder motor, it might make sense to just slow down all of the other axis until the extruder motor catches up and is where it should be.

[Roxy-3D]

I was suggesting I2C because we could daisy chain all the steppers on a stepper-bus of some kind and would allow us to broadcast stuff to all the participating steppers.

If this was done I'm hoping there would be some intelligence on the board so only the desired location is sent via the I^2C bus and not all the traffic to control the real time stepping?

[jbrazio]

I was thinking on those lines, each stepper would be autonomous running its own stepping routine, Marlin would broadcast (or individually address) something like (in a binary optimized protocol): X move 10 and all the stepping pulse chain would no longer be under Marlin responsibility.

[adamfilip]

Roxy im willing to send you one of my usteppers

[Roxy-3D]

@adamfilip Thank You so much for the offer! But those boards are too expensive for an individual to be providing. If the company wanted some testing (and software development) done, I would take them up on that.

And there is another problem causing me to decline your offer. It looks like those boards need to be bolted to the back of the stepper motor. In the case of the extruder motor that is losing steps, there is no place to mount the board to the motor. In this picture you can see how Folger Tech copied what was done on the MK8 extruder and both ends of the stepper motor are hidden:

Is the little magnet that you put on the motor shaft used for the feedback to know if the motor is positioned properly? It seems like that magnet could slip and move.

[uStepperOld]

@Roxy-3D The boards are fully developed and has been for sale since february. We have also done some software development on them, but there is still a lot of work to do. What we have done now is to implement single axis feedback, which of course is not the best solution since the other axes continue without knowledge of what is going on.

The board and software is open source, but we do not expect to get free software development. Of course we would love to get some help from more experienced coders, and especially from the Marlin team, since we are mainly hardware developers (and only two of us). If we can expect to get help with software development for Marlin implementation, we are of course willing to contribute with some hardware for the developers.

If this is of interest for the Marlin developer team they are welcome to contact us on: administration at ustepper.com

Note for the final post. It is require to have the back of the stepper free yes. You can see how the board is mounted here: http://www.ustepper.com/wp-content/uploads/2016/04/instructions.pdf

Theoretically the magnet could slip, but because of the magnet strength we don't believe this would happen and have never experienced it. If it should happen, a drop of glue could be applied to the magnet before mounting it on the stepper.

[jbrazio]

@uStepper You provide the code used on the youtube demo ?

[uStepperOld]

@jbrazio The code used in the youtube demo is still a mockup code and not very easy to read. I will clean up the code and upload it to our github repository before the end of this week. You should however note that the code is by no means fully developed and that we are still working on it.

[Roxy-3D]

@uStepper Clean code is nice! But we have the tools to understand what the code does if we can access the code.

[Blue-Marlin]

@Roxy-3D Wise words! :-(

[uStepperOld]

I have created a branch called "Dropin" which contains the unedited code used in the youtube video.

[jbrazio]

Thanks !

[zh1609]

Another design to note with M0 and 14bit AS5047 D: https://github.com/jcchurch13/Mechaduino-Hardware

[adamfilip]

Any news / update @uStepper ?

[uStepperOld]

Hi Adam,

Within the next few days we are releasing a new version of the library for uStepper, where the drop-in feature with PID controller is implemented.

This implementation just takes in step pulses from the marlin based controller and controls the motors based on this, meaning that it is NOT an integration into the marlin firmware.

At the moment we don't have the resources to integrate this into the marlin firmware. Therefore i think we should close this issue for now, until our schedule clears up, or someone else offers to help on this development.

Best Regards, Thomas Olsen

[adamfilip]

Thomas can you show a picture of how to wire up the upstepper from a Control board like Rumba or Rambo. Im confused about how exactly it is wired up. I assume the stepper driver is still used, hoping no soldering is required.

[adamfilip]

Also how does Microstepping affect the ustepper. is it used. is there a limit to what microstepping it can handle.. 1/16, 1/32 what about 1/128 or 1/256.. is there a speed limit. also is there a lag between receiving a step pulse from the controller and when the ustepper will respond and send the new step to the stepper. sorry for all the questions but there isnt much documentation on your website.

[uStepperOld]

Hi Adam,

For uStepper product specific issues, i don't feel this is the correct place to discuss. Can you please contact me directly by email, and i will be happy to answer your questions?

Best Regards, Thomas Olsen

[adamfilip]

Sure. Will do.

[boelle]

is this one still relavant and wanted?

[Roxy-3D]

Bo... REALLY... Running around from thread to thread and asking "CAN WE CLOSE THIS ONE???" is much much worse than leaving the thread open.

I do NOT view that as adding any value. It is a distraction because now this thread sorts to the top of the 'Most Recently Updated' list and needs to be read.

PLEASE STOP RUNNING AROUND FROM THREAD TO THREAD AND MAKING ONE LINE POSTS.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.