Home › Forums › TinyG › TinyG Support › Arduino Due + DRV8825 custom shield+ G2 issues
Tagged: Custom pin out, due, Questions
- This topic has 5 replies, 3 voices, and was last updated 6 years, 10 months ago by Zootalaws.
-
AuthorPosts
-
November 8, 2017 at 1:01 pm #10676PhaniKiranMember
Hi there!
I apologize ahead if I am posting in the wrong forum
Or if I am looking at the following issues the wrong way!
and for this really long post!I am a total and a complete nooob… building and trying out my first cnc!
I have the following set up:
X- axis – 1x Nema 23 (10.1kgcm)
Y- axis – 2x Nema 23 (10.1kgcm)
Z- axis – 1x Nema 17 (4.2 kgcm)4 Drv8825 polulu drivers on a perf board with a custom pin/wiring scheme
Which is as follows:
Enable for X- 8
Y-9
Z-10Direction Pins for X- 7
Y- 5
Z-11Step Pins for X- 6
Y- 4
Z- 3
12V 30A power supply and the Drv8825 get 3.3V and 12v as per the specsGt2 timing belt with 2mm pitch and 20 teeth pulleys for X, Y axis
I have been able to use a simple arduino code:
// The following is a simple stepper motor control procedures /*# define EN 8 //stepper motor enable , active low # define EN 9 //stepper motor enable , active low # define EN 10 //stepper motor enable , active low*/ # define ENX 8 //stepper motor enable , active low # define ENY 9 //stepper motor enable , active low # define ENZ 10 //stepper motor enable , active low # define X_DIR 7 //X -axis stepper motor direction control # define Y_DIR 5 //y -axis stepper motor direction control # define Z_DIR 11 //z axis stepper motor direction control # define X_STP 6 //x -axis stepper control # define Y_STP 4 //y -axis stepper control # define Z_STP 3 //z -axis stepper control /* / / Function : step . function: to control the direction of the stepper motor , the number of steps . / / Parameters : dir direction control , dirPin corresponding stepper motor DIR pin , stepperPin corresponding stepper motor " step " pin , Step number of step of no return value. */ void step (boolean dir, byte dirPin, byte stepperPin, int steps) { digitalWrite (dirPin, dir); delay (50); for (int i = 0; i <steps; i++) { digitalWrite (stepperPin, HIGH); delayMicroseconds (800); digitalWrite (stepperPin, LOW); delayMicroseconds (800); } } void setup () { // The stepper motor used in the IO pin is set to output pinMode (X_DIR, OUTPUT); pinMode (X_STP, OUTPUT); pinMode (Y_DIR, OUTPUT); pinMode (Y_STP, OUTPUT); pinMode (Z_DIR, OUTPUT); pinMode (Z_STP, OUTPUT); /* pinMode (EN, OUTPUT); digitalWrite (EN, LOW);*/ pinMode (ENX, OUTPUT); pinMode (ENY, OUTPUT); pinMode (ENZ, OUTPUT); digitalWrite (ENX, LOW); digitalWrite (ENY, LOW); digitalWrite (ENZ, LOW); } void loop () { step (false, X_DIR, X_STP, 400); // X axis motor reverse 1 ring, the 200 step is a circle. step (false, Y_DIR, Y_STP, 400); // y axis motor reverse 1 ring, the 200 step is a circle. step (false, Z_DIR, Z_STP, 400); // z axis motor reverse 1 ring, the 200 step is a circle. delay (1000); step (true, X_DIR, X_STP, 400); // X axis motor forward 1 laps, the 200 step is a circle. step (true, Y_DIR, Y_STP, 400); // y axis motor forward 1 laps, the 200 step is a circle. step (true, Z_DIR, Z_STP, 400); // z axis motor forward 1 laps, the 200 step is a circle. delay (1000); }
and all the motors moved as expected.
So I took the shopbotShield-pinout.h as i felt it met my needs better than the gshield pinout and modified it to fit the needs. Been able to compile it and upload it to the Due. I have not modified the motate_pin_assignments.h as I did not see a point in modifying it as all the pins in use are defined here??
The pinout and compiled filesHere are the issues
1) Chilipeppr- Cant jog and get {“sr”:{“stat”:3}} when I try to make it jog. I do edit the config settings like velocity and jerk and step.. use whole steps (Would love if chilipeppr supported 32 microsteps)But when I ask for the default chilipeppr logo G code to be sent over serial. I actually have the x and y axis moving. Not sure about the accuracy as i haven’t tested that yet. But yes there is definite movement to match the directions and values shown in the DRO.
2) Goko- Cant jog get the same {“sr”:{“stat”:3}}
I understand that “stat”:3 is machine has encountered program stop. Is there a jog enable command?
3) UGS version 2.0, Platform versions- nothing happens. I select Tiny G from the drop down and it says
“**** Connected to COM9 @ 115200 baud ****”
when i give it a jog command
like move Y20 3times
>>> {“gc”:”G21G91G0Y20F1″}
>>> {“gc”:””}
>>> {“gc”:”G21G91G0Y20F1″}
>>> {“gc”:””}
>>> {“gc”:”G21G91G0Y20F1″}
>>> {“gc”:””}
>>> {“gc”:”G21G91G0Y20F1″}
thats all i get and it just goes non responsive.What am I doing wrong?? Why cant I get it to jog?
Other questions:
What tool do you guys recommend to be used for sending the Gcode?
Is chillipeppr good?? I feel it makes me a little claustrophobic… way too many dialog boxes and clutter on the screen.Does Mach 3 work well in this custom scenario? How about Linux CNC?
Firmware Build 100
{fb:100.xx}
- This topic was modified 7 years ago by PhaniKiran.
November 8, 2017 at 2:16 pm #10678cmcgrath5035ModeratorLots of good info here, more than I can comment on in depth but will provide some hints.
I assume you are building from a fork of G2core edge, creating a custom 100.26 or later $fb.
While I am at it, if you are not familiar with this issues interface https://github.com/synthetos/g2/issues It is more focussed on specific issues than this Forum, but reading thru issues and solutions may give useful hints.
G2core 100.xx runs the new Line mode Protocol, which may or may not be fully supported or debugged when interfaced by Chilipeppr/SPJS. I doubt UGS is ready, I have no idea about Goko.
To my knowledge , current Mach3 and LinucCNC are not compatible with G2core, both have their own motion logic nand output Step/Dir Enable directly to drivers.I would suggest you start first by interfacing G2core with CoolTerm or equivalent (I use putty from Linux).
Unless you have changed it, $ej=1 and G2core is locked in JSON mode by default. I find it easier to set $ej=2 and use text commands (my legacy hangup), up to you to choose. ultimately you will want to migrate back to JSON.
There is nothing magic about jogging, CAM interface joging simply sends the appropriate G1 XxYx gcode command to G2core. So experiment moving your machine around with G0 or G1 movesI do not believe the Chilipeppr Parameter widget is currently working with fv=100 builds, there are many new parameters that the widget does not accomodate.
G2core does support mircrosteps=32, but Chilipeppr does not as yet
I highly recommend only making parameter changes from the commandline, one at a time, in mm mode. As your parameter settings mature, change the settings.h file and recompile to make your parameters the defaults.
It will likely be some time before Chilipeppr widget catches up.
Once you can get one, create a $$ dump, paste results to a cloud drive and provide a URL. That saves a lot of questions.And, as you for sure realize, you have made a ton of changes that make your environment unique. Add to that G2core being significantly changed and enhanced with fv=100.x. There could be a lot of items to sort out
December 8, 2017 at 11:40 am #10703PhaniKiranMemberThank you @cmcgrath5035. My apologies for such a late reply. Been busy with school and work.
I assume you are building from a fork of G2core edge, creating a custom 100.26 or later $fb
You are absolutely correct. I am on 100.26
G2core 100.xx runs the new Line mode Protocol, which may or may not be fully supported or debugged when interfaced by Chilipeppr/SPJS. I doubt UGS is ready, I have no idea about Goko.
Ok that is interesting the new Line mode Protocol. Hmm yes that might be the reason.
I have gone back and compiled from an older source. But keep getting issues because the source tree looks like its missing some files….G2core does support mircrosteps=32, but Chilipeppr does not as yet
I highly recommend only making parameter changes from the commandline, one at a time, in mm mode. As your parameter settings mature, change the settings.h file and recompile to make your parameters the defaults.True.. I have been playing around with various settings and I finally see it going somewhere!
And, as you for sure realize, you have made a ton of changes that make your environment unique. Add to that G2core being significantly changed and enhanced with fv=100.x. There could be a lot of items to sort out
Yup I only realized that later. I am trying to wrap my head around all the changes and understand if I have made some other mistakes..
Anyways Thanks a lot cmcgrath5035 I am going to keep working at it. Shall post back with the completed and working settings and such!
January 20, 2018 at 9:02 pm #10786ZootalawsMemberLate to the party…
John Lauer has set up a simple way to modify chilipeppr, to create your own modules, etc. and has documented the process well.
Forking it to add 32-step support should be straightforward.
If you find chilipeppr claustrophobic, turn off the bits you don’t want – it’s eminently tailorable.
You might want to look at creating a custom workspace, or look at the TinyG tablet workspace for some inspiration: http://chilipeppr.com/tinygtablet
January 22, 2018 at 3:49 pm #10788cmcgrath5035Moderatorw.r.t. Chilipeppr support for microsteps = 32.
I assume you want to manually set your drivers for $_mi=32, but need to inform G2core of the setting so the right number of pulses come out.I’ll further assume that you want the tinyG config widget to do the $_mi=32 setting for you. It was the developers intent that the next generation of that widget would be able to determine what the setting option were, by observing the response to a $$ command, for example. I don’t think that was ever implemented. G2core now has numerous options that are not supported by the config menus that are hard coded. Tackling a comprehensive redo could have a much deeper bottom than you realize.
To test $_mi=32, simply go the the CP serial console and enter the command $_mi=32, _ is the motor number. CP does not do anything with the mi value, aside from sending it to tinyG or G2core, so you could also compile it in.
Also be aware that microstepping is achieved with a phase relationship tweak. There is some loss of holding torque when microstepping. For deep info, read the TI 8825 data sheet.
January 28, 2018 at 9:23 am #10799ZootalawsMemberAnd… high microstepping ain’t it’s all cracked up to be.
Unless your mechanicals are so coarse that you can’t get the resolution you need is the only reason I would go so high – for micrometer accurate placement on a pick and place or hundredths of a mill accuracy – at this level of hobby controller, it’s often easier to change drive pulleys or screw if that’s the case.
Going from a 20 to 10 tooth pulley or halving the pitch of your screw is pretty easy and does the same thing, although not without some cost.
I have (literally) hundreds of drive pulleys in machined aircraft alloy in tens of different sizes if you want to play around.
-
AuthorPosts
- You must be logged in to reply to this topic.