TinyG with external drivers: J19 (motor3) and J20 (motor 4) don't work

Home › Forums › TinyG › TinyG Support › TinyG with external drivers: J19 (motor3) and J20 (motor 4) don't work

Tagged: 

Viewing 15 posts - 1 through 15 (of 17 total)
1 2
  • Author
    Posts
  • February 17, 2016 at 8:19 am #9351
    lquiroz
    Member

    I need to use external drivers for my design. I bought a TinyG V8 to work with four cheap M540T drivers. I connect them to just step and direction pins of J17 – J20 and 3.3V from the same TinyG outputs (not from J17 3.3V output). Before, I shifted signals to 5V but I realize that M540T works fine also with 3.3V.
    The result was I had drivers connected to J17 and J18 working fine but those connected to J19 and J20 didn’t work. I tested drivers connecting every one to J18 and all of them worked fine. So my first conclusion was J19 and J20 had a some kind of hardware problem on my board.
    I bought another TinyG V8 board and the behavior is the same.
    Are there something different between J17-J18 and J19-J20 from the firmware side?
    I put an oscilloscope and signals looks the same form (but I am not an oscilloscope expert user) when I apply the same movement to J18, J19 or J20. I was not able to see if there are some difference in timing or pulse width.
    Please, any help or suggestion will be appreciated.

    February 18, 2016 at 7:05 am #9357
    cmcgrath5035
    Moderator

    Look closely at your tinyG board and find what release version you have.
    somethin like tinGV8j, or V8k, etc.
    The schematics can be found here

    in pdf format.

    What you will see is that J17-J20 are simply pins tied to the on-board driver device inputs, they are not unique to the external interfaces or uniquely addressed in FW.

    If only one board behaved this way, it could be the board but since both do, something else is in play.

    What do you know about the input side of your external drivers-
    Are they opto-isolator inputs(many are)?

    Did you try J19 and J20 with the 3.3V to 5V level shifters?

    I have seen some opto-isolator inputs that were marginal with 3.3V drive.
    You might even find that a buffered (higher current capability) 3.3V signal would work.

    Do the green leds for driver 3 and driver 4 on tinyG flicker when you send movement commands? They should, even with no motor attached.
    Are you sure you have the drivers enabled? $3pm=2, $4pm=2 ?

    February 18, 2016 at 6:43 pm #9358
    lquiroz
    Member

    Thank you for your answer.
    Both boards are 131v8h
    I tested each external driver (four) connecting each one to only one conector (J18) and every one works fine. No one of the four external drivers works fine connected to J19 or J20 connector. That means to me that the driver is not the problem.
    I don’t know very much about the input side of the external drive, except the connection information http://www.omc-stepperonline.com/images/typical-connection-m542.jpg. It seems to have opto-isolation.
    I tested again with 3.3V to 5V level shifting for J19 connector. I have the same behavior. The same driver connected to a level shifted J19 doesn’t work but connected to a level shifted J18 works fine.
    When I send movements commands without drivers connected the four green leds are lit and then go off, no matter what axis is driven. I have $3pm=2 and $4pm=2.
    I was thinking about timing or pulse width. Could be different for J19 or J20 compared to J17 or J18?
    The driver specification says: “For reliable response, pulse width should be longer than 1.5μs” and “For reliable motion response, DIR signal should be ahead of PUL signal by 5μs at least” I will try to measure pulse width.
    Thanks again for any help.

    February 18, 2016 at 7:44 pm #9359
    lquiroz
    Member

    I have the following measures of pulse width:
    J17: 5.2 μs
    J18: 5.2 μs
    J19: 2.5 μs
    J20: 1.4 μs

    So, there are a difference in firmware for each port. Is it normal?
    This could explain that J19 and J20 doesn’t work. May be the drivers don’t really like 2.5us (in spite of specification of >1.5μs) or 1.4us (well, it is under 1.5μs)
    Do you know where to change this settings if it can be done?
    Someone could say me or test (I don’t know how to do it) if the DIR signal is ahead of PUL signal by 5μs at least?

    Thanks again.

    February 19, 2016 at 8:30 am #9362
    cmcgrath5035
    Moderator

    That is odd, indeed.
    Can you describe your setup a bit?

    What firmware are you running?
    How do you set up and run your tinyG? (CoolTerm, ChiliPeppr, other)?
    Maybe post a $$ parameter dump to a cloud drive and provide a link

    February 19, 2016 at 8:34 pm #9365
    lquiroz
    Member

    Thanks cmcgrath for your answer.
    The setup on both boards is a X,double Y,Z. One board is set with 1.25 mm/rev and the other one with 5 mm/rev. There is some differences with speeds also.
    The firmware on both boards is 440.20 version 0.97
    I use Coolterm or ChiliPeppr. The behavior is the same (same pulse width)
    Here are the links to both boards parameter configuration.
    https://www.dropbox.com/s/jfz9g7c8n3fl5jg/TinygV8-1.txt?dl=0
    https://www.dropbox.com/s/bhdagnianrsqmk8/TinygV8-2.txt?dl=0
    I have connected four stepper motors to one board outputs. Of course the four motors work fine because the on board drivers can handle pulse width of less than 1μs (at my knowledge)
    Thanks you for your time.

    February 20, 2016 at 8:35 pm #9367
    lquiroz
    Member

    Because of https://github.com/synthetos/TinyG/issues/61, I downgrade the firmware to 412.01 on one board to see if I can have 5μs that scottcarlson found.
    I mesure now:
    J17: 5.2 μs (same)
    J18: 4.0 μs (a bit lower)
    J19: 4.0 μs (greater)
    J20: 1.4 μs (same)

    So, now the driver connected to J19 works fine, of course. Also J17 and J18.

    Someone else could compare my mesurements with his/her board?
    I cannot figure out why I have different pulse width on each port. It was programmed intentionally like that?
    Thanks in advance for any help.

    February 21, 2016 at 5:58 am #9368
    cmcgrath5035
    Moderator

    Since you have obviously done your homework, you probably seen these items

    There has not been much step pulse width discussion since the days of FW 438.02, when Alden reworked some internals to get PWs in the 4-5us range and commented (I can’t find that) that due to hardware limitations, that was probably all we could get.
    Of course, you are not getting 4-5us across all drivers.

    You parameters look OK to me (I do a ‘diff’ between yours and a ‘known work OK’ set to highlight differences to look at).

    One oddity in this parameter set – you have all four channels set to either $_tr=5 or 1.25mm. Unusual values for belt machines. I assume you did that for testing purposes, or perhaps you are targeting a large (based on $_tm values) screw machine.
    If you rerun your test with all $_tr=40mm (GTX2 belt typical setting), get same results?
    You could be identifying an issue with uniformly low $_tr values; I would guess most testing is done with belt machine parameters that might have just one(the Z axis) in the $_tr value in the 1-2mm range.

    I have asked the developers to stop by here for a look as well, I am sort of out of ideas and useful info.

    February 22, 2016 at 8:42 am #9369
    lquiroz
    Member

    cmcgrath: Thank you for your answer.
    Before to send my post here I read all posts related to external drivers and pulse width.
    You are right. My parameters are for a screw drive machine.
    I do some test with all $_tr=40, as you suggested, but I have the same results.

    Exploring the code I found on stepper.c
    // pulse stretching for using external drivers.- turn step bits off
    PORT_MOTOR_1_VPORT.OUT &= ~STEP_BIT_bm; // ~ 5 uSec pulse width
    PORT_MOTOR_2_VPORT.OUT &= ~STEP_BIT_bm; // ~ 4 uSec
    PORT_MOTOR_3_VPORT.OUT &= ~STEP_BIT_bm; // ~ 3 uSec
    PORT_MOTOR_4_VPORT.OUT &= ~STEP_BIT_bm; // ~ 2 uSec

    between 530 and 534 lines. I am not a programmer but I see some code done to provide longer pulses for external drivers. Comments show me that the pulse width is not the same for all ports. Am I right?
    cmcgrath: May be I must start a new thread on pulse width? PW of 4-5us is fine but only if we have the same in all ports.

    Thanks you again.

    February 22, 2016 at 11:34 am #9370
    cmcgrath5035
    Moderator

    OK, good info to have on results with $tr=40.
    Are you back to $fb=440.20 ?

    $fb=412.01 is quite outdated.

    This thread will do for now, I believe. Hopefully the devs will stop in and comment.

    February 22, 2016 at 2:33 pm #9371
    lquiroz
    Member

    Sorry. I forget to mention it. I return to 440.20 before the test with $tr=40.
    Thanks you for your concern.

    March 14, 2016 at 9:21 pm #9428
    lquiroz
    Member

    I found a solution to adapt the pulse width to needs of external drivers.
    Warning! I have not evaluated yet the impact on the performance (and I am not a programmer).
    I modified stepper.c adding a delay as a function

    #include <util/delay.h>

    void delay(int us) {
    while(us–) { // loop adds some overhead
    _delay_us(1);
    }
    }

    and inside of each “if” in ISR(TIMER_DDA_ISR_vect) I put a delay of 2 and followed by step bit off:

    if ((st_run.mot[MOTOR_4].substep_accumulator += st_run.mot[MOTOR_4].substep_increment) > 0) {
    PORT_MOTOR_4_VPORT.OUT |= STEP_BIT_bm;
    st_run.mot[MOTOR_4].substep_accumulator -= st_run.dda_ticks_X_substeps;
    INCREMENT_ENCODER(MOTOR_4);
    delay(2);
    PORT_MOTOR_4_VPORT.OUT &= ~STEP_BIT_bm;
    }
    Without the delay I had a pulse width of 1.4 us . Now pulse width for all motors is 3.4us. I measure this with an oscilloscope.
    Now J19 and J20 are working and I know why.
    I hope it will be helpful for all people that tried to use external drivers with tinyg.

    March 16, 2016 at 12:22 pm #9440
    cmcgrath5035
    Moderator

    Sort of hard to tell if you will have introduced side effects.
    Keep your eyes open as FW evolves (later versions may have a different sort of fix).

    June 10, 2016 at 6:08 am #9785
    Splocal
    Member

    Lquiroz,
    I tried searching for the driver you mentioned but had no luck. I need to hook up an external driver for my duel Y axis to free up a spot for an A axis. I would really appreciate you sharing which driver you are using, thanks!!!

    July 22, 2016 at 7:30 pm #9855
    lquiroz
    Member

    Hi Splocal,

    I am sorry to take a while to answer you. The driver I use is a cheap M542T and you can buy from:
    http://www.omc-stepperonline.com/24-phase-nema-23-stepper-motor-driver-2450vdc-15a45a-256-microstep-m542t-p-293.html

    Four of this drives are working fine on each mill controlled by tinyg with a configuration X, doubleY, Z and the mentioned modification to firmware of tinyg.

    I hope it will help you.

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 17 total)
1 2
  • You must be logged in to reply to this topic.