Skip to main content
Posted in

finally got a chance to install and mess around with 0.82. very cool.

a couple of things.

• home is now working in both directions! awesome. however when i attempt to make multiple large move like:
> move 0 0 50000
> move 0 0 50000
> home 0
it only sends the motor back around 35000 not 100000 steps.

• (laymen's question) since the schematic hasn't been posted i couldn't quite figure out which pins were 14 and 15. also how is the sleep wire set up? does that wire just go to every axis sleep port?

• i was also getting "ERROR: Timeout Reading from engine"
does that have something to do with the camera and focus pin not being connected? couldn't figure out why that was happening. slim scripts still ran great.

also noticed the same thing mentioned here: http://openmoco.org/node/141
anyway to make it like home and have the ability for more? just curious.

many thanks!

Hey man! Home should be

Hey man!

Home should be working, even at 100k steps. Does it say it actually moved 100k? ('s moved 0' and 's home 0' before the move, and then check after sending home) I'll look at the code, it's strange as I recall fixing all home issues! doh! (I just looked and all of the functions look correct - I also remember testing this, I'll check it again.)

14 and 15 are analog 0 and 1. I don't know why they don't label 'em that way on the arduino - 14-19 are analog 0-5.

What command gives you ERROR timeout? If it's the move 50000 command, then you can set it longer in the TimeLapse.pm file. I'll set it higher in the distribution version.

While I could make 'move now' go further, you would only get that capability with that command -- the steps between shots and move motor actions would still be limited, due to how the actions and keyframes are stored. I'm not sure if it's ok to have two different standards there, let me know what you think.

!c

thanks c! regarding the

thanks c!

regarding the standards... i wouldn't be the best judge of that ;)... fine with me either way. i was just making large moves to simulate having a hell of a long custom dolly or realtime stuff. so not sure how many people this would actually effect.

fyi, if i have debug on and i try to set_motor 0 home i get:

[32] > set_motor 0 home
DBG: set_motor:0:home
Use of uninitialized value in concatenation (.) or string at openmoco-slim.pl line 492, <> line 7.
[set_motor] Set Motor 0 'home' => ''

without debug on it works fine. i have no idea what that code on line 492 is so can't tell if that was intentional.

as for the home issue... here's 3 examples:

here's a home with small moves, works a.o.k.:

[1] > port /dev/tty.usbserial-A...
[2] > c
[3] > set_motor 0 home
[4] > debug 1
[5] > move 0 0 20000
DBG: move:0:0:20000
[move] Move Motor '0', Dir '0', Steps '20000'
[6] > move 0 0 20000
DBG: move:0:0:20000
[move] Move Motor '0', Dir '0', Steps '20000'
[7] > home 0
DBG: home:0
[home] Sent motor '0' home
[8] > status moved 0
DBG: status:moved:0
moved, 0 = 80000

everything acted exactly as it should have.

here's one with large moves:

[1] > port /dev/tty.usbserial-A...
[2] > c
[3] > set_motor 0 home
[4] > debug 1
[5] > move 0 0 50000
DBG: move:0:0:50000
[move] Move Motor '0', Dir '0', Steps '50000'
[6] > move 0 0 50000
DBG: move:0:0:50000
[move] Move Motor '0', Dir '0', Steps '50000'
[7] > home 0
DBG: home:0
[home] Sent motor '0' home
[8] > status moved 0
DBG: status:moved:0
moved, 0 = 200000
#right here it just moved around 20k-30k back.
#so i send it back to the original home manually
[9] > move 0 1 60000
DBG: move:0:1:60000
[move] Move Motor '0', Dir '1', Steps '60000'
[10] > move 0 1 5000
DBG: move:0:1:5000
[move] Move Motor '0', Dir '1', Steps '5000'
#now it's about in the right spot but the rotator is still a few degrees shy of where it
#needs to be so i try out the home.
[11] > home 0
DBG: home:0
[home] Sent motor '0' home
# now that sent it back around 65000 steps to a new place it thinks is "home"?
[12] > status moved 0
DBG: status:moved:0
moved, 0 = 330000

one more try with large moves but this time overshoot the manual adjustment and it finds the correct home:

[1] > port /dev/tty.usbserial-A9007OKF
[2] > c
[3] > set_motor 0 home
[4] > debug 1
[5] > move 0 0 50000
DBG: move:0:0:50000
[move] Move Motor '0', Dir '0', Steps '50000'
[6] > move 0 0 50000
DBG: move:0:0:50000
[move] Move Motor '0', Dir '0', Steps '50000'
[7] > home 0
DBG: home:0
[home] Sent motor '0' home
#now its around 65k steps shy of where the home really is
#so i send it around home manually
[8] > move 0 1 65000
DBG: move:0:1:65000
[move] Move Motor '0', Dir '1', Steps '65000'
#now i overshoot the original home by a few K steps
[9] > move 0 1 5000
DBG: move:0:1:5000
[move] Move Motor '0', Dir '1', Steps '5000'
#wrong command i meant "moved" just so you can see what the tally was
[10] > status motor 0
DBG: status:motor:0
motor, 0 = 0
[11] > status moved 0
DBG: status:moved:0
moved, 0 = 270000
#now that it's over shot the original home by a few K i send it back home
[12] > home 0
DBG: home:0
[home] Sent motor '0' home
#now the engine goes back to the correct place, only 2-3K steps in the 0 direction,
#but status says it has moved 70K steps.
[13] > status moved 0
DBG: status:moved:0
moved, 0 = 340000

as for the "ERROR: Timeout Reading from engine". I think that there may be a problem with my arduino? i previously stated the scripts where running great and that proved to be wrong. i ran the scripts heard the motors making a noise and believed the script to be running fine. after setting up the cam (with new wiring, thanks!) and trying to let one run through i realized the cam was only firing "initializing?" about half the time i ran a slim script and the motors weren't moving at all. after adjusting the pots, ala brian's instructions, it still didn't work. sometimes the same script spits out a error and sometimes not (then cam fired but motors don't move). i downgraded to 0.81 and rewired to test and the same problems were happening. strange because the motors are moving a.o.k. with the "move" commands but all the scripts that were working fine a couple of weeks ago are now not working.... so all those tests above may be inaccurate due to a faulty board?

also, while running those scripts i'd exit slim the re-enter "perl openmoco-slim.pl" then load a new script. if i forgot to exit and loaded a new script it would just spit out a ton of errors.

i.e.:
Actions
[_openmoco_command] ERROR: Unable to write to device
[_openmoco_command] ERROR: Unable to write to device
...

I'm thinking you have a

I'm thinking you have a hardware issue going on. The 's moved 0' command is showing exactly the right now number of steps at each stage as I'd expect, and I'm sure 's home 0' would show you exactly as far from home as your move commands should take you.

For example:

motor 0 home
move 0 1 20000
move 0 0 20000
s moved 0
# ^^ should result in 40000
s home 0
# ^^ should result in 0
move 0 1 60000
move 0 1 60000
s moved 0
# ^^ should result in 200000
s home 0
# ^^ should result in 120000
home 0
s moved 0
# ^^ should result in 320000
move 0 0 50000
move 0 0 5000
s home 0
# ^^ should result in -55000

I'm thinking you have a wiring problem first - did you check to make sure that your arduino and the stepper drivers share a good ground connection? Also, the timeouts may be coming from the default min/max step times. You can adjust these using the 'stepper' command in slim. Setting them lower makes the stepper step faster.

!c

ok, grounds checked. all

ok, grounds checked. all looking good.

hey here is that 3rd test again just showing the "s home 0" values as well.

[1] > port /dev/tty.usbserial-A....
[2] > c
[3] > set_motor 0 home
[4] > debug 1
[5] > stepper min_stp 150
DBG: stepper:min_stp:150
[stepper] Set step control param 'min_stp' to '150'
[6] > move 0 0 50000
DBG: move:0:0:50000
[move] Move Motor '0', Dir '0', Steps '50000'
[7] > move 0 0 50000
DBG: move:0:0:50000
[move] Move Motor '0', Dir '0', Steps '50000'
[8] > s moved 0
DBG: s:moved:0
moved, 0 = 100000
[9] > s home 0
DBG: s:home:0
home, 0 = -100000
[10] > home 0
DBG: home:0
[home] Sent motor '0' home
[11] > s moved 0
DBG: s:moved:0
moved, 0 = 200000
[12] > s home 0
DBG: s:home:0
home, 0 = 0
# this really only moved it around 30k so i return it back to the "real" home manually
[13] > move 0 1 65000
DBG: move:0:1:65000
[move] Move Motor '0', Dir '1', Steps '65000'
[14] > s moved 0
DBG: s:moved:0
moved, 0 = 265000
[15] > s home 0
DBG: s:home:0
home, 0 = 65000
#now i overshoot the "real" home
[16] > move 0 1 5000
DBG: move:0:1:5000
[move] Move Motor '0', Dir '1', Steps '5000'
[17] > s moved 0
DBG: s:moved:0
moved, 0 = 270000
[18] > s home 0
DBG: s:home:0
home, 0 = 70000
[19] > home 0
DBG: home:0
[home] Sent motor '0' home
# at this point it finds the "real" home
[20] > s moved 0
DBG: s:moved:0
moved, 0 = 340000
# and it only moved around 3k
[21] > s home 0
DBG: s:home:0
home, 0 = 0
[22] >
#only thing that's boggling me is that it is totally repeatable, only happens with large number steps, and is very accurate to where it's moving even though it's the "wrong" place.

new test based on yours:

[1] > port /dev/tty.usbserial-A9007OKF
[2] > c
[3] > set_motor 0 home
[4] > debug 1
[5] > stepper min_stp 150
DBG: stepper:min_stp:150
[stepper] Set step control param 'min_stp' to '150'
[6] > move 0 1 20000
DBG: move:0:1:20000
[move] Move Motor '0', Dir '1', Steps '20000'
[7] > move 0 0 20000
DBG: move:0:0:20000
[move] Move Motor '0', Dir '0', Steps '20000'
[8] > s moved 0
DBG: s:moved:0
moved, 0 = 40000
[9] > s home 0
DBG: s:home:0
home, 0 = 0
[10] > move 0 1 60000
DBG: move:0:1:60000
[move] Move Motor '0', Dir '1', Steps '60000'
[11] > move 0 1 60000
DBG: move:0:1:60000
[move] Move Motor '0', Dir '1', Steps '60000'
#this is where our totals look a tad different ;)
[12] > s moved 0
DBG: s:moved:0
moved, 0 = 160000
[13] > s home 0
DBG: s:home:0
home, 0 = 120000
[14] > home 0
DBG: home:0
[home] Sent motor '0' home
[15] > s moved 0
DBG: s:moved:0
moved, 0 = 280000
#at this point the rotator is about 175º away from home, or looks like it moved around 60k.
# so i manually get it closer back to home
[16] > move 0 0 50000
DBG: move:0:0:50000
[move] Move Motor '0', Dir '0', Steps '50000'
[17] > move 0 0 5000
DBG: move:0:0:5000
[move] Move Motor '0', Dir '0', Steps '5000'
[18] > s home 0
DBG: s:home:0
home, 0 = -55000
#now i'm going to try the overshoot (it's still about 6º away from where home should be)
[19] > move 0 0 10000
DBG: move:0:0:10000
[move] Move Motor '0', Dir '0', Steps '10000'
#almost there
[20] > move 0 0 5000
DBG: move:0:0:5000
[move] Move Motor '0', Dir '0', Steps '5000'
#over by 3º or so
[21] > home 0
DBG: home:0
[home] Sent motor '0' home
#this moved it back to the "correct" home or exactly 0º
[22] > s moved 0
DBG: s:moved:0
moved, 0 = 420000
[23] > s home 0
DBG: s:home:0
home, 0 = 0

and after messing with the pots a little more, noticed one driver was warm and the other wasn't, i got both motors spinning during the script. (1 down)... but i'm still getting a "[_openmoco_command] ERROR: Timeout Reading from engine". it's not effecting anything as far as i can tell. scripts still run great, it just pause for 20-30 seconds before it's fully loading / running the script. seems to be hanging around the 5-7 lines regardless of if it put "stepper min_stp 150" before or after it.

no idea what it is... regardless scripts are running fine.

Quote: noticed one driver was

Quote:
noticed one driver was warm and the other wasn't

Not generally a good sign. And, I do believe it is related to your problem.

(Sorta - but anyway, I say that, because I've caused it intentionally in the past =)

I think what's happening is you're tripping the overheat protection circuitry in the driver during your long moves.

First, we need to get rid of those timeout errors, as, in fact, you are in an instable position when this happens. (There will be unexpected data in the serial buffer generally.) Find your installed copy of TimeLapse.pm, and change the following line:

        # default timeout is 60 seconds
 $self->{'timeout'}        = 60;

Now, the next thing we're going to do is _slow down_ the motors.

stepper min_stp 1000
stepper max_stp 3000

Now, try a big move and see if it misses any steps - at this slow step rate, you should be able to hear any missed steps. Any gaps in the sound means you're missing steps. The first cause is likely to be the overheating circuitry in the driver. If you miss steps, reduce the current adjustment to the stepper. You're more than likely missing lots of steps during each move, it's just that on smaller moves its less noticeable - should be practically non-quantifiable visually on small moves =) (That's why we try to set a very slow step rate, so we can hear each individual step and listen for gaps.)

Both drivers really should be at the same temperature if you have the same motors attached to them.

But the fact that the counts are right indicates that you're either missing steps, or you have a lot of backlash* that isn't accounted for.

* - I haven't asked if there's a gear-chain, ignore me completely if there's no gear chain involved, and you're just running flags on the stepper shafts =)

!c

I have a similar issue. I can

Matt's picture

I have a similar issue.
I can move my dolly along my track about 10 x 10 000 steps. If I try to move it 100 000 steps, it stops just about in the middle of the track.
I assume it's because the move now command can't take values larger than 65536, because it does work fine with all values below (like 50000).
Now that I know, I can work around it, but it would be great to do larger moves. I have a project coming up, where we want to do a transition between a TL shot and a realtime shot. I guess the 65536 steps will be just about enough for the realtime shot, but it could be close...

Anyway, great job with 0.82, Chris. I can do 4 axis (pan, tilt, dolly, focus) moves with keyframes now. It's so much fun !

Matthias

Hello, first of all thank the

Hello, first of all thank the efforts made to develop this project.   I am interested in writing for a project of motorized slider with two engines. I woulduse it to timelapse (at different speeds), panoramic photography and HDR video,continuous video, 3D, etc. ..
 Could you use your project for this purpose?Is it possible to pan having an object centered?In the event that only use 2 engines, can give error.
 I guess you need a driver for each motor, what do you recommend?
I really appreciate your help and if you can put a link where to download the wiringdiagram and how to use the software.
 Thank you very much,
Greetings.

people are pursuing for Louis

people are pursuing for Louis vuitton handbags cool, unique, stylish and innovative. Whether it is discount Louis Vuitton or fashion accessories all means a lot for modern society of today. Same is the case with trendy looking burberry handbags. When these are, the excitement just gets doubled. Most chic looking burberry outlet are in fashion now. These are one of the favorite fashion abercrombie and fitch sale accessories for men and women long time ago. If you have not yet tried Louis Vuitton Outlet, it's time to own one and feel the difference it can make burberry bags to your personality. These are just brilliant and fabulous louis vuitton sale . They are most iconic and can provide burberry bags you with a new feeling and enhance confidence. The quality of louis vuitton online is just superior to what you have dreamt of. Today owning a new and trendy looking louis vuitton bagsare not only meant for the wealthy people. They are most iconic and can provide you with a new feeling and enhance abercrombie and fitch online confidence. The quality of abercrombie sale is just superior to what you have dreamt of. Today owning a new and trendy looking abercrombie outlet sale are not only meant for the wealthy people.

The newest style of Coach

The newest style of Coach Purses Outlet offer ferragamo bags online. Coach Outlet have cheap Coach Diaper Bags, Coach Hobos Handbags ferragamo handbags, Coach Totes Handbags, Coach Outlet Online for cheap, Coach Poppy Handbags, Coach Outlet Online and Coach wallets. Coach Tote Bags are one of the most popular and versatile handbag styles.are well received by the females, especially the young. Stylish design, colorful painting, practical function attract the public's attention soon. All ferragamo outlet we offer here are stylish trims and innovative designs. Coach Outlet Store Online are mostly welcomed and loved by women and even men. Cheap Coach handbags use the unique and fine leather material which is extraordinary in the world. Take your time to select ferragamo sale our best Coach bags cheap for sale with discount wholesale and free and fast shipping. Online register as a member on this website and enjoy your online shopping. Welcome to enjoy shopping our salvatore ferragamo outlet! Our aim is Best quality top service. Just take action! Don't miss the opportunity to own one of these fasionable Discount Coach Handbags on discounted price. Free shipping and non sale tax! Buy ferragamo shoes now and enjoy the fashion world!