No. I’ve never had homing switches. You really are running. Can you jog and get position reports back?
Actually, in your screenshot you do have a value in your X axis. Looks fine. It’s probably now just your motor settings. You’re probably barely moving at all on the steps/mm and so you just think it’s not working but probably is.
Looks like a very nice driver build! Mine’s not so pretty, repurposing an old Sony DVD chassis.
There are some issues that need to be considered when connecting a Due directly to many external stepper drivers such as my TB6600 based ones. I just finished designing and testing my own integration (using a custom shield hacked based on a proto shield) last night. I searched for a g2core board type that’s suitable but did not find one in the current Master branch. Therefore I created a custom board and custom settings in my private copy of g2core source and hacked the step pulse polarity (not motor direction). Here’s what I found:
-
The default g2core ‘step’ pulse polarity output by the Due was wrong for a direct connect to the stepper drivers’ opto isolators. With the wrong polarity, the motors actually turned, but the drive torque was so low that stalls occurred without any load. With a different stepper driver (possibly yours), the motor might not turn at all. That some other Arduino code moved the motors does NOT guarantee that the pulse polarity is correct in g2core. When I reversed my g2core build’s drive polarity, torque was great. I ended up hacking the low level code in g2core/device/device/step_dir_driver as g2core does not seem to support configuration of the ‘step’ pulse polarity in the settings files or anywhere else. Some g2core notes that I saw somewhere listed adding pulse polarity config settings to the g2core code as needed enhancements sometime in the future, but for now I edited 2 lines of code that override the stepStart() and stepEnd() virtual functions. You may be able to rewire your outputs to the stepper drivers inputs to sink instead of source as an alternative to changing the SW. With my direct connect, the Due’s 6mA sink current is marginal.
-
This is likely unrelated to your problem, but may enable you to connect directly without the need for logic level shifters on your shields. The opto isolators used in my Chinese stepper drivers require 5mA (per specs) for proper switching. Not all Due pins are capable of sourcing this current. D2 (the gShield default for X-axis step pulses) can only source 3mA. It may ‘work’ but then again it may not be reliable. So I selected different Due output pins, all capable of sourcing 15mA. Also, I split the shared Enable into 3 different pins (for my 3-axis rig) to keep the individual pin drive requirements below 15mA. This was accomplished by creating a new entry in http://boards.mk, a new g2core/settings/settings_my_custom_board.h file and a new g2core/board/ArduinoDue/my_custom_board.h file. I used D10 for Xstep, D5 for Xdir and D8 for Xenable. With my build, 3.3->5V logic level converters were unnecessary, but should solve any output current limit issues in other cases. YMMV with different stepper drivers.
I can put the sources up on github or get them pulled into Master if anyone feels this would be useful. I’m pretty new to the g2core community (just did my first build this week). It seems likely that others have faced the same hurdles in the past and posted their solutions, but I couldn’t find them.
Hi Alex, thanks for your reply! I for one would be most interested in seeing your g2core sources. As you say, it seems like other must have done this already but like I haven’t found any examples yet. I spent some time playing with the code yesterday but unfortunately I am not an expert (more like a novice) in this area. I think I was able to walk myself through most of setting up a custom settings file ok, but I guess I’m not sure what you mean by “hacking” in the step_dir_driver file? I did find the stepstart() stepstop() lines but it was not obvious what/how to change them? I also found a number of things that had to do with “polarity” but they all seemed to be changing motor direction not the step signal polarity.
I also tested my drivers without the level shifters using the same “arduino” code I wrote and they seem to work fine. As you say this doesn’t mean that g2core is setup correctly but it is my current understanding that this test at least means the drivers should work fine once g2 is setup? I have a basic understanding of how steppers work but that doesn’t mean much if I don’t know what the code is trying to do I guess.
I’m also a newbie to g2core, and found it took some digging to figure out how to configure. I didn’t see a way to configure the step pulse polarity, so I dove in to find the code that actually sets/clears the step pulse pins. The file I’ve referred to is g2/g2core/device/step_dir_driver/step_dir_driver.h. The mods I made to change the polarity are commenting out the two lines that set/clear the step line and adding lines that clear/set the step lines instead:
//void stepStart() override { _step.set(); };
void stepStart() override { _step.clear(); };
//void stepEnd() override { _step.clear(); };
void stepEnd() override { _step.set(); };
I believe that these functions along with numerous other functions/parameters get written into a structure the defines behaviors for each motor. It would be cleaner to have this polarity configurable from the settings files and settable on a per-axis basis, and it seems that this is on the coders’ todo list. I would have done that if I felt had a better understanding of the code and how it’s configured. But for now this is a hack. The benefit is that I can drive my optoisolated stepper driver hardware directly from a Due without any level shifters or other active HW. I chose to put a 33 Ohm resistor in my implementation so that the 3.3V output drives about 7mA into optoisolators – slightly over the 5mA minimum and well under the 15mA current source capability of the Due pins that I assigned to pulse the step lines.
You can change your step polarity by fiddling with the wires, selecting one of these options:
- hook the stepper driver’s + step input to Vcc and the - step input to your control output
- hook the stepper driver’s - step input to ground and the + step input to your control output.
But the Due’s outputs can source a lot more current (15mA max for many pins, 3mA for other pins) than they can sink (9mA max for many, 6ma for others). And common optoisolators may require up to 10 mA input current for normal operation. So fiddling with the wires as above may not be enough. The older Arduinos can source and sink at least 20mA, so there was no need for SW pulse polarity before g2core. Now there’s a need for SW configuration of step pulse polarity.
I’d like to thanks Alex Bobtek… I reversed the steps and the ultimately the enable pins and I’ve got a $15 chinese Due w/ a prototype board running my TB6064 stepper drivers from massmind (connected via a raspberry pi 2)… Works great so far, need to check that everything is kosher and probably slow it down a bit… thing flies now vs. my linuxCNC machine. So yeah, it’d be really nice to have a configuration operation for inverting these signals to work with separate drivers… I’d gladly by a real tiny G board if it didn’t have integrated steppers that I’m not going to use, so far this is much better than having an entire LinuxCNC pc, monitor, keyboard, etc out in the garage.
http://www.massmind.org/techref/ecomprice.asp?p=416074
Also… for anyone else troubleshooting this type of setup… if you notice the machine is making noise, but not making any steps, apply light pressure to an axis while jogging… if when it tries to jog the machine moves then stops after… your enable signals are inverted 
Finally had a break in my classes to work on this project and … success! Thanks to Alex and others for the help. I had to bring in my younger brother who is a lot more computer savy than me to understand the g2code structure and then I made the changes as Alex laid out above. My drivers (Chinese MA860H) ended up needing to have a level shifter between them and the Due. Still not quite there settings wise but I just need to spend some more time with it. Currently it seems that when a rapid jog is run the motors stall at the higher rpm. Maybe this is microstepping problem? (I have the driver jumpers set to the same value as in the settings_mybaord.h file) Could also just be a limitation of these motors as I know stepper torque drops way off with increasing rpm. Anyways glad to have it working if even only partially at this point.
It could be that your level shifters can’t act as fast as the steps coming out of TinyG. I’ve tried to capture step signals in a GPIO interrupt and it’s near impossible, so that’s my guess. What if you do no micro-stepping to reduce the amount of steps sent to the driver? Or change the max feed rate setting on your TinyG so it doesn’t go beyond the speed of steps you can support.
Lucas, a possibility in addition to one John mentioned is drive current’s impact on torque and there’s also a an inevitable stall speed. What is the drive current, how is the low-speed torque, and what speed (microsteps/s) are you pulsing at when it stalls? Stepper motors lose torque at higher speeds and eventually reach speeds at which they stall even with no load. Apologies if I’m telling you things you already know.
If you turn the drive current slightly up or down near the speed where stalls start to occur, you should be able to confirm (if current makes no difference) John’s hypothesis of pulse issues or refute (if current makes a difference) that there is a pulse duration issue.
So after playing with it a little more I determined I had a couple wires mixed up and that fixed some of the issues I was having. I am 100% sure that I my connections are good now (i have basically tried all possibilities at this point ). In this process I also found that I no longer needed the level shifters so those are eliminated in terms of my remaining problems.
What I am encountering now is a strange mixing of input from different axes to one motor… for example X+ jogs the “x” motor one direction, but X- jogs the “y” motor? Also Y+ moves both “x” and “y” equally but Y- only elicits movement in one motor but still in the same direction. Also the I get good, smooth operation in some directions and stutter/rough operation when sending the reverse of the same direction.
I have tried just running one motor/driver to simplify wiring and found that X+ jogs work equally well with pin combos 2(step) + 5(dir), 2+6, and 2+7. This leads me to think there is something wrong with pin assignment for direction pins although the pinout file I am using seems to look and work correctly if I change a value. I also don’t see how multiple pins can function the same if they aren’t shorted/ connected somewhere… Pretty confused by this one…
FYI I am using “gshield” as my board type in the http://boards.mk entry and working from the pinout diagram for the gshield on the Due / by what is specified in the copy of gshield-pinout.h I am referencing in my build.
One other thing I was wondering is whether the gShield pinout will work for my purposes when used directly from the arduino or if it undergoes some further transformation in the gShield circuitry that precludes it from working directly?
Update: I just got things working 100% a few minutes ago. I ended up being able to borrow some smaller drivers and motors from work to test with the Due and determined that I just needed to reference ground instead of 5V. Hopefully I will get everything put back into the machine and calibrated this weekend. Once I get it going I will definitely post some pics of the final build for those interested. Very grateful for the help I got here, thanks!
An update on polarity. Many of the cheap TB6600 drivers that are available on eBay (where I got mine) apparently have a counterfeit TB6600. For reference: go to youtube and search for “counterfeit TB6600”. Despite what some of these videos correctly demonstrate (that the chips don’t work in some cases where the genuine ones work), I found that the counterfeits can be made to work if the pulse reference/polarity is reversed. I believe that what Lucas and I found (e.g., ‘referencing ground instead of 5V’ in his case and my polarity SW hack) are all manifestations of this. My hypothesis is that the guys that counterfeited the design left out some buffer logic, and that pulse set up and hold time requirement are very different on genuine vs counterfeit chips.