Testing the board

[Matthew Green]

Hi, Me again :-)

The breadboard is built, and I can communicate with it over USB, and it pops up as a USB Mass storage device, so all of that side is going well.

I'm trying to test it before fixing everything to the router, so I've got the motors wired up to the Pololu a4988 boards, but I can't get the motors to turn.

Tonight I'm going to check my connections, to make sure I've got all he pins right, but I just wanted to check on a way to get the Smoothie to move them.

Right now I'm logging on to the serial terminal and typing "G91 X10 Y10" to see if I can just spin the steppers. Is that right? Or is there a better way?

Cheers,

Matt

[Arthur Wolf]

Hey !

Not sure what G91 is, maybe try G1 ?

Also, do you get an "ok" as an answer to your messages ?

Cheers :)

2013/1/26 Matthew Green <me...@mephi.co.uk>

--
 
 

--
Courage et bonne humeur.

[Matthew Green]

I took G91 from the list of supported gcodes on the smoothie site:
Relative mode : passed coordinates will be considered relative to the current point

I get an ok back, I'll try G1 as well next time.

Cheers,

Matt

[Arthur Wolf]

Hey :)

Yes, G91 changes the way G1 reads coordinates, it does not itself take coordinates or do any moving. You want to use G0 or G1 here.

Cheers.

2013/1/26 Matthew Green <me...@mephi.co.uk>

--

[Matthew Green]

Ahh ok, understood.

I've tried it again I'm sending the commands:

G1 X20 Y20 Z20

G1 X-20 Y-20 Z-20

And it's all getting a bit strange.

I believe should make all three motors spin one way and then change directions.

Motor X spins slowly one way, then changes direction

Motor Y doesn't spin at all

Motor Z quickly spins one way and the carried on the same way when Motor X changes direction

I've tried re-arranging the motors and drivers to see if it's a hardware issue and the issue stays with the same microcontroller pins.

This made me think it was an issue with the wires connecting the microcontroller and the drivers, but I've continuity tested them and they're fine.

The configures pins are: 

alpha_dir_pin is set to 2.7

alpha_step_pin is set to 2.8

beta_dir_pin is set to 2.11

beta_step_pin is set to 2.12

gamma_dir_pin is set to 0.28

gamma_step_pin is set to 2.13

And just for reference, here's a picture of my board:

Cheers,

Matt

[Arthur Wolf]

Hey.

Can you try isolating which pins do not work whatever you do, and try using other pins for the functions you assign them currently ?

I think what is going on is that smoothie expects those pins you are using to do something else.

You can look at the smoothieboard schematic and copy the pinouts, probably a good idea : https://github.com/arthurwolf/SmoothieBoard

Cheers.

2013/1/27 Matthew Green <me...@mephi.co.uk>

[joseph perry]

If I may expound from my experience with cnc? G0, G1, G2, and g3 are modal interpolation moves. On the cnc controllers I've used you have to have a feed rate at some point in the program for everything but G0. G1 is linear, g2 is clockwise, g3 is counter-clockwise, and g0 is linear rapid. g91 is relative to the coordinate system zero and g90 is absolute. On some machines simultaneous axis movement (3 or more) is an upgrade that the boss has to pay the machine manufacturer to unlock. So, assuming your machine has the travel to make the move, you could type g0 g91 x20. y20. z20. which would cause it to travel at maximum feedrate to x+20 units, y+20 units, and z+20 units relative to it's current position. All machines I've worked with use trailing zeros so if you don't include a period after the units in the code, 20 would be 20 of the smallest units the machine can move i.e. 20 ten-thousandths of an inch or .002" Hope this helps at least THAT issue.

joe

[Arthur Wolf]

Hi !

We are inheriting the meaning of gcodes from grbl. I'm pretty sure they have the same meaning in other reprap electronics/firmwares too.

G0/1/2/3 move the head to the coordinates passed as parameters.

G91/G90 change, for all the commands following them, wether their parameters are absolute or relative, but do no movement themselves.

Do you have a link to somewhere describing another meaning/usage of G91/G90 ?

Cheers !

2013/1/29 joseph perry <cnc...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David BOZEC]

Hi!

you can have a look at this document (p40-41)

Regards,
David.

2013/1/29 Arthur Wolf <wolf....@gmail.com>

[Daniel Dumitru]

I didn't know that Gerber it's same thing with G-Code.

[David BOZEC]

So far as I know Gerber format is based on Gcode, instructions are almost the same.
There are only few more ones in Gerber, relative to the "apertures"

2013/1/29 Daniel Dumitru <dand...@gmail.com>

[Arthur Wolf]

My references for gcode are :
http://reprap.org/wiki/G-code#G91:_Set_to_Relative_Positioning

and http://en.wikipedia.org/wiki/G-code

2013/1/29 David BOZEC <d.b...@gmail.com>

[bobc]

On Tuesday, January 29, 2013 6:36:52 AM UTC, joseph perry wrote:

If I may expound from my experience with cnc? G0, G1, G2, and g3 are modal interpolation moves. On the cnc controllers I've used you have to have a feed rate at some point in the program for everything but G0. G1 is linear, g2 is clockwise, g3 is counter-clockwise, and g0 is linear rapid. g91 is relative to the coordinate system zero and g90 is absolute. On some machines simultaneous axis movement (3 or more) is an upgrade that the boss has to pay the machine manufacturer to unlock. So, assuming your machine has the travel to make the move, you could type g0 g91 x20. y20. z20. which would cause it to travel at maximum feedrate to x+20 units, y+20 units, and z+20 units relative to it's current position. All machines I've worked with use trailing zeros so if you don't include a period after the units in the code, 20 would be 20 of the smallest units the machine can move i.e. 20 ten-thousandths of an inch or .002" Hope this helps at least THAT issue

Well, it sort of helps, except that the G-code standard is pretty complex, and firmwares like Reprap and grbl use a small subset of the standard, and there is a lot of things that don't work how you might expect.

In the standard, G0 to G3 cause movement, G90/G91 set the distance mode. In standard G-code you can have multiple G codes on one line provided you use one code from particular groups, and there is a particular execution order. In addition, the G0 to G3 commands are modal, which means that they stay in effect for subsequent lines. If you don't specify a G-code on a line, it should repeat the last move command with any new parameters.

In the RS274D and RS274X standards you can also use implicit decimal formats.

That is the standard, which you probably are familiar with; Reprap firmwares typically don't implement any of those features!

In general, Reprap firmwares do not support multiple code words per line (the last one is used), do not support implicit decimals, and do not support modal commands. The best description of the Reprap flavour of G-code is at the link Arthur gave, http://reprap.org/wiki/G-code, but implementations vary.

Personally I use the document http://www.nist.gov/customcf/get_pdf.cfm?pub_id=823374 as a guide to how implementations should behave, but current implementations diverge too much to use it as a guide to how implementations actually behave. 

[joseph perry]

Lol Arthur. My references are in my head built up over the last 25 years using gcode. I'm embarrassed to admit that I really don't know of any links to references. Lol. I've never been asked that before. Leave it to Wikipedia to explain something ad nauseam ;) Good link by the way. I had to look in my machinist handbook today to see for myself where gcode even came from. I like bobc's explanation of the differences between what I use in the industry versus what to expect from reprap firmware. In light of those differences my advice for Matthew on gcode could quite possibly be in error. Sorry Matthew!

On Tuesday, January 29, 2013 5:36:33 AM UTC-8, Arthur Wolf wrote:

My references for gcode are :
http://reprap.org/wiki/G-code#G91:_Set_to_Relative_Positioning

and http://en.wikipedia.org/wiki/G-code

[Matthew Green]

No problem, it's always nice to be able to delve into a bit of detail on a new subject :-)

Right now I'm just trying to get all the motors movingin an expected way, I'm going to be checking all of the smoothie pinouts tonight as per Arthur's recommendation and hopefully that'll fix it :-)

Cheers,

Matt

[joseph perry]

Thanks Matthew. I hope you post your findings because I'm hoping there are enough pins to implement a fifth axis on this rev of the smoothie! ;-)
Take care buddy,

joe

[Arthur Wolf]

Hi !

There are plenty of free pins. One connector is specifically pins broken out just to add a 5th driver, but you can pretty easily add a 6th and a 7th, no problem.

Cheers.

2013/2/3 joseph perry <cnc...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Matthew Green]

Hurrah!!!! It's working now :-D

I've ended up with the following config:

alpha_dir_pin                               2.7            

alpha_step_pin                            2.8          

beta_dir_pin                                2.5            

beta_step_pin                             2.4          

gamma_dir_pin                            2.6 

gamma_step_pin                         2.13

And all the motors spin how they should.

I'm expecting to find that my previous tinkering damaged the original pins, as I also managed to damage two stepper drivers...

Now to hook everything up, finish the dremel attachment (I'm using that as my router for now) and see if I can make stuff!

Thanks for all your help, I'm sure I'll be back here with more questions soon enough...

Cheers,

Matt

On Sunday, 3 February 2013 17:37:17 UTC, Arthur Wolf wrote:

Hi !

There are plenty of free pins. One connector is specifically pins broken out just to add a 5th driver, but you can pretty easily add a 6th and a 7th, no problem.

Cheers.

2013/2/3 joseph perry <cnc...@gmail.com>

Thanks Matthew. I hope you post your findings because I'm hoping there are enough pins to implement a fifth axis on this rev of the smoothie! ;-)
Take care buddy,

joe

On Sunday, February 3, 2013 5:56:22 AM UTC-8, Matthew Green wrote:

No problem, it's always nice to be able to delve into a bit of detail on a new subject :-)

Right now I'm just trying to get all the motors movingin an expected way, I'm going to be checking all of the smoothie pinouts tonight as per Arthur's recommendation and hopefully that'll fix it :-)

Cheers,

Matt

On Wednesday, 30 January 2013 08:09:29 UTC, joseph perry wrote:

Lol Arthur. My references are in my head built up over the last 25 years using gcode. I'm embarrassed to admit that I really don't know of any links to references. Lol. I've never been asked that before. Leave it to Wikipedia to explain something ad nauseam ;) Good link by the way. I had to look in my machinist handbook today to see for myself where gcode even came from. I like bobc's explanation of the differences between what I use in the industry versus what to expect from reprap firmware. In light of those differences my advice for Matthew on gcode could quite possibly be in error. Sorry Matthew!

On Tuesday, January 29, 2013 5:36:33 AM UTC-8, Arthur Wolf wrote:

My references for gcode are :
http://reprap.org/wiki/G-code#G91:_Set_to_Relative_Positioning

and http://en.wikipedia.org/wiki/G-code

--
Courage et bonne humeur.

 
 

--

Courage et bonne humeur.

[joseph perry]

Congrats Matthew! Hope you make a vid!

joe