Forum

Welcome Guest 

Show/Hide Header

Welcome Guest, posting in this forum requires registration.





Pages: [1] 2 3
Author Topic: New build and attempted firmware for step/dir drivers
lanthan
Newbie
Posts: 22
Permalink
Post New build and attempted firmware for step/dir drivers
on: February 5, 2012, 17:09
Quote

Hi,
Some pictures of my build, commissioned today:
http://www.flickr.com/photos/lanthan/sets/72157629185958843/with/6823716121/

I modded vandalized the firmware to use step/dir drivers (currently two stepsticks running with 1/16th microstepping). This appears to be working sweet with C1 commands (go to point, pixel and bitmap stuff), but not unlike what has been described in other posts, any call to C17 sends the gondola in weird and impossible trajectories.

Still have to find the right settings for 3200 steps per revolution and 40 mm per revolution, but so far, it is promising

Anyway, the code is here on github:
https://github.com/lanthan/polargraph4dirstep

Any help/comments/pointing out in the right direction highly appreciated.

Cheers,

sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: New build and attempted firmware for step/dir drivers
on: February 5, 2012, 18:43
Quote

Ianthan, this is badass, thanks for taking the time to give it a shot. I have been wanting to get away from depending on the motorshield because of the pins it uses makes it difficult to use SPI at the same time.

I'm definitely going to buy a couple of serial stepper boards and try this out. A slightly reduced-feature RAMPS shield would do the business.

When you say that you haven't found the right settings for 3200 / 40, I guess that means that 3200 and 40 don't work? What goes wrong with those? The controller gets very confused if you change stepsPerRev and mmPerRev, best off doing a save+restart after that.

Ok, doing my own trials with microstepping, a couple of things jump out as things that need fixing:

1. In the controller, the Upload machine spec function adds an extra 0.5 onto the stepsPerRev and the mmPerRev. Fix it by casting to an int for those commands:

void sendMachineSpec()
{
  // ask for input to get the new machine size
  String command = CMD_CHANGEMACHINENAME
+newMachineName+",END";
  commandQueue.add(command);
  command = CMD_CHANGEMACHINESIZE
+getDisplayMachine().inMM(getDisplayMachine().getWidth())
+","+getDisplayMachine().inMM(getDisplayMachine().getHeight())
+",END";
  commandQueue.add(command);
  command = CMD_CHANGEMACHINEMMPERREV+
int(getDisplayMachine().getMMPerRev())
+",END";
  commandQueue.add(command);
  command = CMD_CHANGEMACHINESTEPSPERREV
+int(getDisplayMachine().getStepsPerRev())
+",END";
  commandQueue.add(command);
}

2. More significantly, with so many microsteps, ints no longer have enough space to hold most position values. I should have guessed this was going to come up eventually, sorry folks. Int max value is 32,767, so it might move ok at the top, in the centre, but any further down than that, then the position rolls over and the gondola heads off to wobble around angrily at the top of the machine, presumeably looking for -32000 or something. Try changing all your positional ints to longs, and use asLong() to extract the params rather than asInt().

After that, C17 works ok for me. Very slow, but que sera. Accelstepper isn't known to work that well at high speeds (1000+), so you might want to get rid of it and use Stepper library directly, but I like acceleration, I think it makes for smoother drawings and a nicer noise!

Cheers!
Sandy Noble

lanthan
Newbie
Posts: 22
Permalink
Post Re: New build and attempted firmware for step/dir drivers
on: February 5, 2012, 19:14
Quote

Sandy, this comment is enlightening and you are pointing me in direction of The Truth!

That wrap-around behaviour looks much alike what I am seeing each time I send a vector or direct command.

My comment on microstepping was that now a lot of features appear tocome out real tiny - I should be scaling the grid up 8 times, right? it is step based rather than mm based, right? (haven't checked all the code)

Shields? you can go with a very, very simple contraption :
testboard_electronics
yeah I fried the boarduino, so I rebuilt this. I kept adding capacitors until engaging the servo didn't reset the board anymore (yes it is on the same power supply rail, 5V 2.2A wall wart). Will transfer to stripboard in a foreseeable future.

Acceleration: (it seems to me) a problem with current implementation is that it is not always in sync when the motors have different lengths to treat, so one side decreases speed faster than the other and the trajectory strays away from the ideal. Yes, the library is sort of slow. Some day I'll try looking into sprinter to check what they did - marlin is way better, but a very different beast.

Another idea:
I feel sort of kludgey to reposition the gondola with the current position on top, appears very, very tight at only 120 mm from the inter-axes line. What I have to do each time I recenter is:
-engage the motors
- disconnect the separate power supply for the motors (18V)
- manually place the gondola by pullng on both vertical cables
- once I have the gondola over the right guesspoint, plug in the motor power supply: it doesn't move anymore.
This could be much simpler if the home point was all the way down the board, with much less belt tension involved

sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: New build and attempted firmware for step/dir drivers
on: February 5, 2012, 19:42
Quote

Good stuff. I should have thought about the long vs int thing ages ago, but since I only ever used small machines with low steps, it didn't make much difference to me, ha!

I admit I'm not a fan of microstepping - it makes for smoother movement, but I don't like it for positional accuracy. I don't like the idea that the motors are suspended kind of in mid-turn, seems like it would be awful prone to dropping steps. Maybe I am just a wuss! Also makes an awful noise! That's the nicest thing about the adafruit motorshield in fact: The interleaved step style, it's a kind of half-step.

I figure the real precision of this machine, or the smallest unit worth addressing is the pen tip size, and that will almost always be pretty big compared to 1 steps-worth of movement (depending on your spool/sprocket size), and I see no need for more than 800 steps per rev, though I'm sure I'll be proved wrong soon enough.

But actually int wraparound might explain a few weirdnesses people have been reporting, and I'll change my server code as soon as I get time. I'm going to take your lead and make the motor objects a bit easier to swap out too. I'm also looking at splitting the core stuff (mm to steps, size, line drawing) out to a library, and you'd be able to pass in whatever motor implementation you liked when it get's initialised. Not done libraries before, so maybe not fast, but now I've got two versions of the code, it's necessary.

The home point can be moved to wherever you like on the setup tab (home pos x and y). The default is the centre, at the top edge of the page because it was easy to mark on the board, but like you noticed, that only really works on smaller machines where the angle of the cords isn't too tight.

And yes, once you've changed the stepsPerRev and mmPerRev you'll probably have to change a bunch of other settings to make things 8 times bigger, grid, image scaling, picture frame etc - sorry about that!

Cheers!
Sandy Noble

lanthan
Newbie
Posts: 22
Permalink
Post Re: New build and attempted firmware for step/dir drivers
on: February 5, 2012, 21:39
Quote

Microstepping is much in the ear of the beholder 😉 much discussed in the reprap forums recently. bottom line: no significant loss of accuracy (nothing that matters much for pen positioning at polargraph scale) but much less vibrations, harmonics in higher ranges for our musical enjoyment. Younger ears are more prone to be troubled by 'em.

casually looking ath the kritzler code: yes he does the positioning procedures with longs.

Gave a shot at the conversion it but looks like I'm going to wait to see your version of the conversion for guidance. There's something I must be doing awfully wrong:

polargraph4dirstep.cpp: In function ‘long int asLong(String)’:
polargraph4dirstep.cpp:668:6: error: redefinition of ‘long int asLong(String)’
polargraph4dirstep.cpp:662:6: error: ‘long int asLong(String)’ previously defined here
polargraph4dirstep.cpp: In function ‘byte asByte(String)’:
polargraph4dirstep.cpp:676:24: error: ‘asInt’ was not declared in this scope
polargraph4dirstep.cpp: In function ‘void setMachineSizeFromCommand()’:
polargraph4dirstep.cpp:743:44: error: ‘EEPROMWrite’ was not declared in this scope
polargraph4dirstep.cpp:747:46: error: ‘EEPROMWrite’ was not declared in this scope
polargraph4dirstep.cpp: In function ‘void setMachineMmPerRevFromCommand()’:
polargraph4dirstep.cpp:767:32: error: ‘asInt’ was not declared in this scope
polargraph4dirstep.cpp: In function ‘void setMachineStepsPerRevFromCommand()’:
polargraph4dirstep.cpp:773:35: error: ‘asInt’ was not declared in this scope
polargraph4dirstep.cpp: In function ‘void changeDrawingDirection()’:
polargraph4dirstep.cpp:835:43: error: ‘asInt’ was not declared in this scope
polargraph4dirstep.cpp: In function ‘void testPattern()’:
polargraph4dirstep.cpp:895:40: error: ‘asInt’ was not declared in this scope
polargraph4dirstep.cpp: In function ‘void testPenWidthScribble()’:
polargraph4dirstep.cpp:1000:58: error: call of overloaded ‘changeLength(long int, long int)’ is ambiguous
polargraph4dirstep.cpp:62:6: note: candidates are: void changeLength(int, int)
polargraph4dirstep.cpp:63:6: note:                 void changeLength(float, float)
polargraph4dirstep.cpp: In function ‘void drawRectangle()’:
polargraph4dirstep.cpp:1022:26: error: call of overloaded ‘changeLength(long int&, long int&)’ is ambiguous
polargraph4dirstep.cpp:62:6: note: candidates are: void changeLength(int, int)
polargraph4dirstep.cpp:63:6: note:                 void changeLength(float, float)
polargraph4dirstep.cpp: In function ‘void changeLength()’:
polargraph4dirstep.cpp:1125:26: error: call of overloaded ‘changeLength(long int&, long int&)’ is ambiguous
polargraph4dirstep.cpp:62:6: note: candidates are: void changeLength(int, int)
polargraph4dirstep.cpp:63:6: note:                 void changeLength(float, float)
polargraph4dirstep.cpp: In function ‘void drawTestDirectionSquare()’:
polargraph4dirstep.cpp:1358:32: error: ‘asInt’ was not declared in this scope
polargraph4dirstep.cpp: In function ‘void drawSquarePixel()’:
polargraph4dirstep.cpp:1377:30: error: ‘asInt’ was not declared in this scope
polargraph4dirstep.cpp: In function ‘void drawScribblePixel()’:
polargraph4dirstep.cpp:1533:30: error: ‘asInt’ was not declared in this scope
polargraph4dirstep.cpp: In function ‘void drawScribblePixel(long int, long int, int, int)’:
polargraph4dirstep.cpp:1563:50: error: call of overloaded ‘changeLength(long int, long int)’ is ambiguous
polargraph4dirstep.cpp:1142:6: note: candidates are: void changeLength(int, int)
polargraph4dirstep.cpp:1177:6: note:                 void changeLength(float, float)

Cheers,

lanthan

sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: New build and attempted firmware for step/dir drivers
on: February 5, 2012, 22:19
Quote

Ha like I know any better! Are you happy to use accelstepper? I'm a bit reluctant to bake that into the library if it's going to be a problem with faster stepping. But I do so love acceleration. It's so civilised.

Ok, well maybe my fear of microstepping is just irrational superstition...

Sandy Noble

lanthan
Newbie
Posts: 22
Permalink
Post Re: New build and attempted firmware for step/dir drivers
on: February 5, 2012, 23:29
Quote

As for me, I'd be more than happy without accelstepper. Simpler, faster code, easier to debug...
On the high performance side, for acceleration & planner needs, this looks surprisingly well annotated:
https://github.com/ErikZalm/Marlin/blob/Marlin_v1/Marlin/planner.cpp
might take some time to digest its substance, though.

But since we are dealing with an eminently pendular device, speeds will always have to be on the limited side. So maybe civilization is optional after all..

lanthan of the bush of ghosts

sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: New build and attempted firmware for step/dir drivers
on: February 5, 2012, 23:37
Quote

That looks terrifying.

lanthan
Newbie
Posts: 22
Permalink
Post Re: New build and attempted firmware for step/dir drivers
on: February 6, 2012, 20:55
Quote

Hi again,

Integrating r244 now. in the process,

void setMachineMmPerRevFromCommand()
{
  int mmPerRev = asInt(inParam1);

Shouldn't this a float?

sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: New build and attempted firmware for step/dir drivers
on: February 6, 2012, 21:24
Quote

Probably right Ianthan, I can only guess that I didn't put it as one because then I'd have to figure out how to store floats in EEPROM. Poor excuse I know.

lanthan
Newbie
Posts: 22
Permalink
Post Re: New build and attempted firmware for step/dir drivers
on: February 6, 2012, 22:57
Quote

Maybe this?
http://arduino.cc/playground/Code/EEPROMWriteAnything

from the talk there, it might have been integrated in the standard eeprom library?

Another question: is startLengthMM the initial distance from each sprocket/pulley to the tip of the pen?
checking this. currently -my bot is 1781 mm between sprockets- when homing 120 mm under the inter-axis line I should be setting that value to 898.549 mm (using a float). If I wanted to home 240 mm under the inter-axis line instead, I should be setting that value to 922.274 mm instead. Or am I straying?

sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: New build and attempted firmware for step/dir drivers
on: February 6, 2012, 23:14
Quote

Aha! That's true! I do remember seeing something about that, good spot.

StartLengthMM is exactly that, it's the length the machine thinks the cords are upon startup, unless it's told otherwise. It's pretty vestigial to be honest, since one of the first things that always gets done is to "set home" anyway. All it really serves to do is confuse me when I forget to home, and I wonder why the gondola is off driving down there. To be honest, I don't

But yes, that maths works for me, 922.274mm from top corner to 240mm down your centre. The easier way is to do it through the controller though. When you adjust your home point there, and hit "set home" I guess you should see something like:

C09, 73781, 73781, END

appear in the command queue. 73781 = (3200/40) * 922.274 give or take.

sn

lanthan
Newbie
Posts: 22
Permalink
Post Re: New build and attempted firmware for step/dir drivers
on: February 7, 2012, 18:02
Quote

Updated the firmware fork for stepper drivers on github with r243 changes, it is drawing vectors, positioning problems solved. THX Sandy!

sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: New build and attempted firmware for step/dir drivers
on: February 25, 2012, 22:38
Quote

Do you have a schematic for how you're wired up there? Got some new bits to play with. Don't want to blow them up.

woodpecker
Beginner
Posts: 33
Permalink
Post Re: New build and attempted firmware for step/dir drivers
on: March 13, 2012, 20:53
Quote

just a short question: i have to install it (polargraph4dirstep.ino) instead of the polargraph_server_ino, right?

sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: New build and attempted firmware for step/dir drivers
on: March 13, 2012, 21:02
Quote

yep, it's a replacement for the current firmware.

The rows you might need to edit would be near the beginning -

const int motoraStepPin = 10;
const int motoraDirPin = 9;
const int motorbStepPin = 12;
const int motorbDirPin = 11;

but not sure off the top of my head what the values should be. Ironing, you know 🙂
sn

bseishen
Newbie
Posts: 3
Permalink
Post Re: New build and attempted firmware for step/dir drivers
on: March 13, 2012, 22:08
Quote

I just wanted to say thanks to sandy and lathan for your hard work! I got my polar graph electronics now working, but iv'e hit a snag. Looks like all the C17 commands are not working. I am using the 32bit windows controller software and pulled the latest firmware from lathan's repository. Got any ideas?

bseishen
Newbie
Posts: 3
Permalink
Post Re: New build and attempted firmware for step/dir drivers
on: March 14, 2012, 15:35
Quote

Well I see polargraph_server_serialstepper_itead.ino has been recently updated. I'll give that a try tonight and see if it will work with my arduino uno/pololu A4988 driver setup. Looking over the source code, it looks like the stepper drivers will need to be configured for full steps.

sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: New build and attempted firmware for step/dir drivers
on: March 14, 2012, 15:56
Quote

Yep, I mentioned it on http://www.polargraph.co.uk/forum/?mingleforumaction=viewtopic&t=43.1#postid-283 it's speculative though, not tested, and nothing done with servo motors anyway.

This uses the arduino pin connections that the ITEAD motorshield uses, but other than that, I really don't think it's any different from lanthan's code

It also sets the step size to be full steps too, but that's configurable. If it won't ever change, then you can just configure it with wires and jumpers directly - it's only worth bringing them under the control of the arduino if you want to change it dynamically.

Not sure why C17 wouldn't be working though, pretty sure lanthan had it working on his machine. I've got a couple of those step sticks, so I might get around to giving it a shot while I'm waiting for the shield.

// pin outs for the ITEAD motor driver shield
const byte motoraStepPin = 2;
const byte motoraDirPin = 3;
const byte motoraMicrostep1 = 4;
const byte motoraMicrostep2 = 5;

const byte motorbStepPin = 6;
const byte motorbDirPin = 7;
const byte motorbMicrostep1 = 8;
const byte motorbMicrostep2 = 9;

AccelStepper motora(1,motoraStepPin, motoraDirPin);
AccelStepper motorb(1,motorbStepPin, motorbDirPin);
bseishen
Newbie
Posts: 3
Permalink
Post Re: New build and attempted firmware for step/dir drivers
on: March 26, 2012, 19:16
Quote

Das Doodler works now! Set up everything for 1/4 stepping and now works like a charm. Took it to a local convention past weekend for an attention getter for our maker space, and it stopped everyone! Though it sounds like a machine gun when drawing vectors, but I might just have the Max speed cranked up too high. Thanks again!

Pages: [1] 2 3
Mingle Forum by cartpauj
Version: 1.0.34 ; Page loaded in: 0.065 seconds.