External Drivers with TinyG

Home › Forums › TinyG › TinyG Support › External Drivers with TinyG

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • January 14, 2019 at 1:04 am #11275
    fixxxer
    Member

    Does anyone have experience with external drivers and TinyG? I bought some gecko drives (g203v) to run some 7 amp motors and I’m getting strange results. Specifically, the motor is pausing breifly before beginning motion and more importantly it’s not moving the correct distance. I believe I have the travel set properly.

    January 14, 2019 at 5:42 am #11276
    cmcgrath5035
    Moderator

    As a general statement many users have reported good luck using geckodrive external drivers, but this is the first reference to the G203V I have seen.

    The interface is Step,Dir,Disable speaking positive logic, which I interpret to be compatible with tinyG, which is Step,Dir,Enable[bar,active low].
    The gecko input specs are good for logic voltages a low as 2.5V, tinyG is 3.3V logic.

    A difference I see from other drivers is that the G203V is hard coded as 10 microsteps per step.
    What setting are you using for $_mi?
    Setting $xmi = $ymi = $zmi = 10 should work, but your CAM software(e.g. Chilipeppr) may barf on that value as the native (on-board) tinyGdrivers don’t accept $_mi=10.

    If problems continue, provide a list of your tinyG parameters.
    Run $$ in a console, copy the results to a file and post the file to a cloud drive, provide us with a URL. Parameter sets pasted directly into this interface are difficult to read.

    Other pertinent info might be what current setting you are using on the gecko and a description or picture of you tinyG to gecko wiring

    January 14, 2019 at 9:09 am #11277
    kiwigrant
    Member

    I had an issue where the step pulse rate was higher then the maximum step and pulse frequency my drivers was able to accept. This resulted in missed step pulses. My suggestion is to check the math in this area to ensure that you are not exceeding the maximum pulse output of the TinyG or the maximum pulse input of the Gecko drives.

    Its easy to get carried away in trying to obtain the best step resolution at the expense of over driving your hardwares capabilities.

    January 14, 2019 at 10:50 pm #11278
    fixxxer
    Member

    Okay so right now I’m only communicating with motor group 2, mapped to y axis. The other motors are disengaged and the other motor drivers are not powered. I set the tr values to the machine as described by cncrouterparts.com. I’ve changed the $2mi from 1 to 10 and I don’t see any difference in performance. I didn’t read the documentation clearly enough on the gecko website. I assumed incorrectly that the 10 meant max, not default native hardcoded. I’m assuming I’ll have to exchange them but here’s a link to my $$ dump just in case you guys have a brilliant alternative:
    https://gist.github.com/GregRobinson85/7a44f173506ed13655c4bec4c3c7b1a4#file-gistfile1-txt

    As an aside, a new development when I power on my tiny g. There used to be just a red light that would flash on reset but now all four green motor lights flash along with the red one. Once it’s all reset and happy, it’s just the blue on LED. Are there more settings somewhere other than the $$?

    January 14, 2019 at 11:25 pm #11279
    fixxxer
    Member

    One note regarding the specific performance issues. Besides the fact that motor doesn’t move the gantry the specified distance, the thing that really gets me is the pause. On the old machine, with no external drivers the machine would respond as soon as I hit enter on a G move. Now there are 1-3 second before I can detect any movement. I’m sure it’s just the incompatibility of the drivers with the tiny G but I wanted to be thorough. I’ll make another post asking about gecko drivers in general.

    January 15, 2019 at 5:48 pm #11280
    cmcgrath5035
    Moderator

    tinyG with $2mi=10 should work fine with this external driver.
    I had to read the gecko document a couple times too, first I have seen a driver with fixed microstepping.

    Does Y move at all? If you command Y to move 10mm, how far does it move?
    What Voltage are you driving the motors with, and what is your current setting for the gecko?

    The LED behavior you report sounds OK.
    The red flashing on reboot/startup is the bootloader waiting for possible communication with Avrdude wanting to download new code.
    Once boot delay is done, tinyG starts up with all motors energized at current location for $mt time, in your case, 2 seconds.

    Your $2pm=2 setting is the usually prefered value, motor energised when any motor is moving. If things still not working right you can try $2pm=1, but that is overkill.

    Your $2tr = 24.9350 mm is a bit strange, too large for a screw machine but on the low side for a belt machine. Are you sure it is correct, and not the right value for a different controller? I am not aware of an available belt and pulley combo that would yield 24.935mm per revolution

    The delay on command send does sound strange.
    Are you sure of proper connection to step, dir and enable plus ground?
    Schematic are here https://github.com/synthetos/TinyG/tree/master/hardware/v8schematics

    January 15, 2019 at 7:49 pm #11281
    fixxxer
    Member

    g0 y100 moves about 60mm (reading with tape measure so it’s not bomber). However I changed $2pm and now =1. The motor responds immediately and moves the correct distance. My concern is, doesn’t $2pm= 1 essentially keep motors at freehold? I don’t know but I’ve heard that motors can over heat that way. Is there any truth to that?

    I’m glad you mentioned the $2tr because I forgot to correct it to 24.9351. It’s a 3.2 reduction on a 1″ drive pulley via belt. http://www.cncrouterparts.com/pro-rack-and-pinion-drive-nema-34-p-226.html, down about half way.

    Anyway the thing works now thanks to you. Will try running it through it’s paces after I get my limit switches configured.

    Earlier you’d said “…but your CAM software(e.g. Chilipeppr) may barf on that value as the native (on-board) tinyGdrivers don’t accept $_mi=10.” Are you saying that the tinyG might send bad values to chilipeppr (that is what I use) even though it can send the drivers the right info?

    For future reference, I talked with gecko tech support and they have a “daughter” board for the g203 v with a jumper selectable step configuration that modifies the step driver and turns it into the g213v that I should have probably purchased in the first place.

    Here’s a link: https://www.geckodrive.com/g901x-stepper-multiplier.html
    One would have to remove the cover and unplug something and then put this modifier board in essentially. But then I think you can select 1,2,5 or 10 micro.

    That’s the route I’ll go if chilipeppr gives me trouble.

    January 15, 2019 at 10:50 pm #11282
    cmcgrath5035
    Moderator

    The chilipepper issue is that the parameter widget will only allow $_mi of 1,2,4,8.
    So don’t try to use the parameter setter widget.
    tinyG actually computes with whatever value is entered. 1,2,4 and 8 are the fixed available values of $mi for the on board drivers.
    $2mi=10 will work fine.

    If $2pm=1 fixes the issue, it sounds like there is some sort of phasing issue with the enable lead relative to step pulse. With $2pm=1, the enable lead from tinyG is always low, so a step pulses make it to the motor.
    Perhaps the gecko needs a longer setup, or time before step that enable must be tru (or in gecko, disable false.

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