It is currently Mon Sep 21, 2020 11:10 pm




Post new topic Reply to topic  [ 56 posts ]  Go to page Previous  1, 2
 Project Zeus 
Author Message

Joined: Tue Apr 05, 2011 6:16 am
Posts: 487
Post Re: Project Zeus
Jack Ripper wrote:

That would be awesome!

When i first started looking into timelapse i got sort of ticked off, because i saw few vendors, many DIY systems, and zero standard for communication. I went with i2c because it is simple, and most DIY enthusiests with minimal arduino experience can introduce it into thier own DIY designs and hopefully integrate them with other systems. my other goal was to develop multiple motion control options and systems that are independantly intelligent, with that simple commands passed back and forth should offer whatever integration is needed.

I agree there is no point in having a VCR vs Betamax, if i can implement it i would be happy to do so. My biggest stumbling block is most of the code on your site is nearly undecipherable for me. I am good at engineering my own code, but cant for the life of me reverse engineer a lot of more complex coding because i have so much to learn.

ill take a look over there, and i would be happy to use it if i can figure it out.


Yeah, I feel ya - why do you think I started openmoco? =)

Certain things in coding will be fairly complex to new developers, but admittedly, some of the old TLE was way more complex than it needed to be. Which is why, when I designed the nanoMoCo board (soon to be on-sale, once we finish working out production issues like programming and testing these things 500 at a time) I went back and re-designed everything software-wise and started on the OM libraries. The OM libraries are there to keep people from having to worry about the really complex stuff, and to simplify their lives for simple things. OMState, for example, can reduce your code by about 90% in complex timing cycles - no need for crazy bitflags, and deeply nested chains of if/else, just a few callbacks and function calls to indicate the current state where needed, for example, the massively huge timing control mechanism that existed in the main loop function of the old TLE has been reduced to this with the new libraries:

Code:
void loop() {


   // check to see if we have any commands waiting     
  Node.check();
     
    // toggle debug led state if requested
   if( debug_led_enable )
     debug_flash();
   
      // if our program is currently running...
     
   if( running ) {
     
            // update run timer
 
     run_time += millis() - last_time;
     last_time = millis();
     
       // if we're the slave and a interrupt has been triggered by the master,
       // set to clear to fire mode (for multi-node sync)
     if( ComMgr.master() == false && ComMgr.slaveClear() == true )
       Engine.state(ST_CLEAR);
     
       // check current engine state and handle appropriately
     Engine.checkCycle();
   }


}


That handles multi-node sync, bus command processing, and all cycle timing, and is backed up by helper functions that the state engine calls when needed. Here is an example of one of these helper functions for determining, once a move has been started, whether or not we can go ahead and fire a camera, which won't block at all if we're in continuous motion mode:

Code:
void cycleCheckMotor() {
         // still running?
     
     // do not block on continuous motion   
      if( Motor.continuous() == false && Motor.running() == true )
        return;

    // no longer running, ok to fire camera
   
    if( ComMgr.master() == true ) {
        // we are a timing master
      Engine.state(ST_CLEAR);       
    }
    else {
        // we are a slave - block until next slaveClear signal
      Engine.state(ST_BLOCK);
     }
}


I also tried to add a lot of examples to show how to do things - take a look at the node example, it's fully functioning (and the master/slave sync examples in OMComHandler are fully-functioning too).

Now, the issue with i2c as a transport layer, is it isn't actually designed for this purpose. As the name implies, it was designed for communication between IC's installed on the same circuit board, with a fixed network architecture. Generally, the spec is used for bus lengths less than a few inches max. You can certainly go further, and do more with it using very intelligent designs and buffers and amplifiers, but once you get into networks of indeterminate topologies, it becomes a nightmare to manage bus capacitance without a lot of external hardware. SPI will get you a longer bus for free (with more wires, of course), but you're still stuck with a standard bus topology. With more industry-standard RS-485 (it is, after all, the transport layer in nearly every factory and industrial device in the world, although now they're moving to ethernet and wifi with modbus over TCP), you can support mesh, ring, and bus topologies with only two wires. (You're likely faking a star topology currently, but it will come back to bite you later.) It's also much less sensitive to network capacitance than i2c. You don't get the high-speeds of i2c (although you rarely will achieve these speeds with disparate devices anyhow), or the bi-directionality of SPI or RS-232 (ok, bi-directionality is possible over RS-485, but with more hardware), but you get instead a highly-reliable, simple layer than supports very long bus lengths - hundreds of meters or more when smartly designed. There are arduino clones out there with built-in RS-485, usually using the CANBUS spec instead of MODBUS.

i2c has once nice feature that RS-485 doesn't, in arbitration, but if we're controlling the masters, the masters can ensure they don't talk over each other by simply never sending data when they have read data in their buffers.

Of course, another drawback of i2c is if a single device faults, your entire bus can be down. In RS-485, a single faulted device usually is self-limited and can't see the network.

All of the mocobus devices we're designing will use a simplified hook-up for the end user, modeling more like MIDI, where you have IN and THRU, and all devices can be daisy-chained using standard RJ-45 (Cat6 to support extreme bus length) cabling.

If you go deep back in the archives here, you'll find three years ago I started with i2c too on my first dolly, because it was fairly easy and "there already," but I did abandon it as time went on and its limitations became clear. Here's the question I asked myself, that led me to abandon it:

"What must my pull-up resistor value be for a network with three devices, with a total bus length of 3m, and a wire gauge of X. Now, what must it be for 10 devices, with a total bus length of 20m?"

!c


Thu Dec 08, 2011 12:43 pm
Profile

Joined: Tue Apr 05, 2011 6:16 am
Posts: 487
Post Re: Project Zeus
I went ahead and started a discussion focused on requirements and design of such a specification: http://openmoco.org/forums/openmoco-dev ... -control-d

!c


Fri Dec 09, 2011 8:42 am
Profile
User avatar

Joined: Wed Mar 16, 2011 2:58 pm
Posts: 1348
Location: Denver, Colorado
Post Re: Project Zeus
Awesome ill check it out as soon as i get some time.

ill see if i can get a list of questions, once i get the grasp of something i can run with it pretty well, i suppose what helps the most is a way to set a commucation example up with a set of arduinos or something and just experiment around. kind of a test lab.

I'm looking forward to getting this all to sync up!

it will be a real time saver if i can just buy somebody elses part and know it will work with my own, so i dont have to make my own. lol. Then rather work on things that other people have done i can start working on developing a few new moco tool i have been wanting to try out. :)

_________________
http://www.BioLapse.com
http://www.TheChronosProject.com


Fri Dec 09, 2011 9:06 am
Profile

Joined: Tue Apr 05, 2011 6:16 am
Posts: 487
Post Re: Project Zeus
Jack Ripper wrote:
it will be a real time saver if i can just buy somebody elses part and know it will work with my own, so i dont have to make my own. lol. Then rather work on things that other people have done i can start working on developing a few new moco tool i have been wanting to try out. :)


Want a mocobus network-ready integrated stepper driver/controller, with all the camera hardware needed for a really low price? *grin*

I just sent off another round of nanomoco boards to be made, the last batch had a part snafu that caused the whole thing pretty much to be trashed. But, in the meantime I got to delete some unnecessary stuff and make it a hellofalot easier to interact with.

!c


Fri Dec 09, 2011 12:22 pm
Profile
User avatar

Joined: Wed Mar 16, 2011 2:58 pm
Posts: 1348
Location: Denver, Colorado
Post Re: Project Zeus
tmp-shutterdrone wrote:
Jack Ripper wrote:
it will be a real time saver if i can just buy somebody elses part and know it will work with my own, so i dont have to make my own. lol. Then rather work on things that other people have done i can start working on developing a few new moco tool i have been wanting to try out. :)


Want a mocobus network-ready integrated stepper driver/controller, with all the camera hardware needed for a really low price? *grin*

I just sent off another round of nanomoco boards to be made, the last batch had a part snafu that caused the whole thing pretty much to be trashed. But, in the meantime I got to delete some unnecessary stuff and make it a hellofalot easier to interact with.

!c

Will it run unipolar?

_________________
http://www.BioLapse.com
http://www.TheChronosProject.com


Sat Dec 10, 2011 7:59 am
Profile

Joined: Tue Apr 05, 2011 6:16 am
Posts: 487
Post Re: Project Zeus
Jack Ripper wrote:
Will it run unipolar?


No, why do you need unipolar?

!c


Mon Dec 12, 2011 9:32 am
Profile
User avatar

Joined: Wed Mar 16, 2011 2:58 pm
Posts: 1348
Location: Denver, Colorado
Post Re: Project Zeus
tmp-shutterdrone wrote:
Jack Ripper wrote:
Will it run unipolar?


No, why do you need unipolar?

!c



it seems that the more powerful high volt/low amp steppers are all unipolar, while bipolar seems to be more common for smaller motors.

i dont claim to be an expert on steppers, but in trying to find a strong motor that will not kill the battery real fast unipolar seems to be the only option. all the bipolar ones i found are 3-6 volt and 2-3 amp./phase.

ive tried hooking my stepper up as bipolar but it seems to sap the strength from it.

the one im using is nema 23, 12v, 125oz-in, .68 amp/phase. With a unipolar driver it works great, it is strong as hell and runs all day on a small 4800mah li-ion battery.

i have not found a single 12v bipolar stepper that gets more than 58 oz in of torque. With the second chronos rail i built for a fellow in canada i used a unipolar 111oz-in stepper and the top end speed really suffered, going from 10min end to end to 13 min end to end. Not a big deal for timelapse, but a significant drop in speed and high end torque.

ive searched quite a bit online, so far the only steppers i find with enough strength that are low amp, high voltage high strength are unipolar.

if you have any leads for 100+ oz in bipolar motors that pull under .75 amps per phase, you will be my hero! cause i can swap to an easydriver and free up 4-5 pins on my arduino.

if i could swap out my electronics with one of your boards i would be happy to do so, my entire goal with chronos is simplicity, a pre-made board would be awesome, especially if it can drive AND allow me to run a display at the same time.

_________________
http://www.BioLapse.com
http://www.TheChronosProject.com


Mon Dec 12, 2011 10:02 am
Profile

Joined: Tue Apr 05, 2011 6:16 am
Posts: 487
Post Re: Project Zeus
Unipolar steppers are less efficient and require a lot more power to achieve the same oz/in of torque. Unipolar motors can run faster at the same voltage and current than a bipolar, but again, with less torque. Unipolars waste more energy as heat than bipolar, so for the same torque output, bipolar will use less battery.

The only "unipolar only" motors are those that have five wires, if they have six or eight, you can wire it bipolar and get more torque out of it. This should help you visualize the difference between uni- and bi-polar windings: https://probotix.com/stepper_motors/unipolar_bipolar/

Greater than 100 oz/in of torque is a big motor, any way you shake it. But, there are lots of options for bi-polar, let's start with: http://anaheimautomation.com/products/s ... =75&cID=19 111 oz/in of torque using 0.85 A with series driving, but no chopping drive @ 12V due to the 9.5v badge rating, instead you can go with something that consumes more current at a much lower voltage (much less winding resistance), and then fully utilize a chopping driver at 12V to get higher speeds. There are a whole host of steppers in the nema 23 frame size that meet these requirements - personally though, I opt for lower torque with gear train reduction, and find that once you account for drivetrain efficiency, you can get more speed at a higher torque with less power, because the requirements on the motor are lower. But, you can't have your cake and eat it too, as they say: if your requirements are high-speed and high-torque, high voltage and high current come along with it. Which is why you see people running 6V motors at 48V+. Refer to the great articles by Jones (google "Jones on Stepping") for more info on how this works. To get 600 steps/second out of a stepper at 12V is good. A thousand is great.

Alternatively, your problem with your bi-polar motor could've been related to using the wrong wiring: series vs. parallel. Try switching between the two.

Note: the nanoMoCo is -not- intended to drive a display, it's intended to sit on a bus with a master that configures it - hence the whole "network of discrete devices which communicate with each other" =) It's also how we get the advanced easing profiles, step rates up 5,000 steps/second, and complex timing out of the little atmega328p =) But, if you can get built-in camera isolation, multi-drop bus support, high-current stepper motor driving AND the ability to run a UI for $35 retail or less, let me know! The idea with nanoMoCo is you just have to figure out what your controller looks like, and the NMs deal with the hard work of driving complex motion profiles, synchronizing between multiple independent motors, and synchronizing movement with camera controls.

!c


Mon Dec 12, 2011 10:29 am
Profile
User avatar

Joined: Wed Mar 16, 2011 2:58 pm
Posts: 1348
Location: Denver, Colorado
Post Re: Project Zeus
Quote:
The only "unipolar only" motors are those that have five wires, if they have six or eight, you can wire it bipolar and get more torque out of it. This should help you visualize the difference between uni- and bi-polar windings: https://probotix.com/stepper_motors/unipolar_bipolar/


you see, that was my understanding as well. i have a 6 wire motor, and i can hook it up bipolar simply by tying the two middle leads together ,however when i do that it works but not as well.

maybe i did not wire it right, i guess i can play around with it a bit and see if i can get some more oomph out of it. The strength is fantastic, but i would be happy to get a little more speed out of it. But, the speed is not a big deal for me i suppose, if i can get it running as bipolar without suffering i would be pretty happy.

_________________
http://www.BioLapse.com
http://www.TheChronosProject.com


Mon Dec 12, 2011 11:38 am
Profile
User avatar

Joined: Wed Mar 16, 2011 2:58 pm
Posts: 1348
Location: Denver, Colorado
Post Re: Project Zeus
tmp-shutterdrone wrote:
But, if you can get built-in camera isolation, multi-drop bus support, high-current stepper motor driving AND the ability to run a UI for $35 retail or less, let me know! The idea with nanoMoCo is you just have to figure out what your controller looks like, and the NMs deal with the hard work of driving complex motion profiles, synchronizing between multiple independent motors, and synchronizing movement with camera controls.

!c


what sort of user interface does this system use? it is not laptop dependent is it?

_________________
http://www.BioLapse.com
http://www.TheChronosProject.com


Mon Dec 12, 2011 12:03 pm
Profile

Joined: Tue Apr 05, 2011 6:16 am
Posts: 487
Post Re: Project Zeus
Jack Ripper wrote:
what sort of user interface does this system use? it is not laptop dependent is it?


Whatever you want to build =) It has a well-defined protocol. We'll be producing several different types of interfaces, (actually, already are building would be correct) including a GUI, stand-alone hardware, and other more complex things. There will be an LGPL-licensed client library for software development on PC/MAC/Linux/Android, but the libraries for running on atmega328's are GPL'd.

But the idea is that you can take something like this, and the libraries, and build whatever cool thing you want to - without worrying about designing the hardware and software for complex motor networks.

!c


Mon Dec 12, 2011 2:32 pm
Profile
User avatar

Joined: Wed Mar 16, 2011 2:58 pm
Posts: 1348
Location: Denver, Colorado
Post Re: Project Zeus
HOLY CRAP..

so i grabbed an old easydriver i had laying around, firgured what the hell, lets give this another shot right

the wiring is
Black/Green with Yellow center
Red/Blue with white center.

wiring up black/green and red/blue have me about the same performance

then i swapped to Black/Yellow and Red/Green

and i damn well doubled the top speed! Where i was sitting about 10 min end to end, im now sitting at 5 minutes end to end. it hauls ass!

So my top speed is now roughly 140-150 RPM, instead of about 80rpm, on the low end im getting about 5 RPM, actually, maybe even lower.


with those numbers my travel time end to end is 5 min to 144 minutes, well over 2 hours

This is fantastic, if i go with a 16 thread rod, i could knock the speed down to about 4 minutes end to end, which will give me 9 inches per minute, or .15 inches per second.


Now to play with the AFmotor board, depending on how well it works i may start a Chronos 2.0

_________________
http://www.BioLapse.com
http://www.TheChronosProject.com


Tue Dec 13, 2011 8:18 am
Profile

Joined: Tue Apr 05, 2011 6:16 am
Posts: 487
Post Re: Project Zeus
Jack Ripper wrote:
So my top speed is now roughly 140-150 RPM, instead of about 80rpm, on the low end im getting about 5 RPM, actually, maybe even lower.


*grin*

Now, time to get it faster AND slower =) A better algorithm and some tuning should get you to 180RPM, and well, 0.0000001 RPM.

The only limit to low-end should be the effective range of a float.

EDIT: I realized you're probably running more than one motor per arduino, so the following is probably not what you want... I left it here in case I'm wrong about this, but I seem to recall you wanted more than one motor per arduino...


I highly suggest swapping OMMotor for AFMotor, you should be pleasantly surprised =) Consider that AFMotor is blocking, and OMMotor is 100% non-blocking, if you intend to run a UI on the same Arduino, I don't know how you do it effectively with blocking moves, unless you're jumping through hurdles to slice the move up.

For example, here's a complete, non-blocking move executed over a specified time, with quadratic easing in and out (over specified times) using OMMotor:

Code:
Motor.easing(OM_MOT_QUAD);
Motor.move(dir, steps, totalTm, accelTm, decelTm);


Oh, and shoot-move-shoot? Takes care of that for ya too:

Code:
Motor.easing(OM_MOT_QUAD);
Motor.plan(dir, totalSteps, shots, accelShots, decelShots);

for int(i = 0; i < totalShots; i++ ) {
   // do something to fire the camera...

     // now execute the next move in the shoot-move-shoot sequence
   Motor.planRun();
    // wait for motor to stop moving - better to just check for this later, and not block
    // but this is a simple example
   while( Motor.running() );
}


For maximum performance, OMMotor requires you to use a fixed step pin (digital 9), but it's a small trade-off, and can be worked around by changing the port register used in the ISR if you need pin9 for another use. (pin9 was chosen as it allows, if one desires, to use Timer1 directly with controllable periods for stepping, but I don't do that =)

!c


Tue Dec 13, 2011 9:41 am
Profile
User avatar

Joined: Wed Mar 16, 2011 2:58 pm
Posts: 1348
Location: Denver, Colorado
Post Re: Project Zeus
OMmotor i assume works with easydriver?

right now i just have AFmotor with aan adafruit motor shield, my testing for the easydriver was library-less at the time.

ill check out OMmotor

and no, im only running one motor per arduino. i could go more, but i think that may start making things difficult.

so i have been playing around a bit, on the slow end i can get 1 foot per hour, probably less, it seems to be just fine doing that, im sure the motor is going to heat up pretty good though. maybe if running bipolar it wont get as hot.

on the fast end with the Afmotor shield im stuck at 6 min end to end, i was able to get 5min end to end with the easydriver. Makes me wonder if the immediate limitations are the drivers not the motor.

by blocking, i assume you mean i have to constantly tell it how far to move right? ie, move 200 steps, repeat?

yeah i was just going a single doublestep at a time.

the UI is not overly important to me. i have on tap with the oldschool buttons and dials 3 speeds of continuous, 3 speeds of velocity ramped, 2 set number of shots per end to end travel with SMS, and 13 levels of delay, and camera trigger support.

Project ZEUS is going to be the UI for Chronos. basically it will just take chronos over and provide a UI, i figured i would do it that way so i dont have to worry about the arduino controlling chronos getting all bogged down, it will just be a puppet.


HOWEVER, i have been playing around with the MiniE engine that is shown on openmoco.org, and after a lot of grief (library issues with more than one rtclib out there)i have the basics of one assembled.

So i figured i would set it up with chronos, the results are so/so, i cant seem to get a speed control, worked out, and it struggles.

I am going to head to my machinists later today, i figured i would pick up my spare stepper so i dont have to have chronos pulled apart and play with it more.

my first impressions as far as functionality, wow, and it looks pretty sweet, however, it takes a while to get in there and change this or that. im not a fan of the interface and it seems to get in its own way. Ill see if my mind changes once i get the stepper dancing to my tune with it.

Chronos itself is gettting a lot of attention, i believe we have 7 builds going on now in 5 countries. I think having the option of using the MiniE engine might be something some people are interested in, i dont plan to use it much myself though because im not a good enough programmer to start changing things around.

_________________
http://www.BioLapse.com
http://www.TheChronosProject.com


Tue Dec 13, 2011 3:16 pm
Profile

Joined: Tue Apr 05, 2011 6:16 am
Posts: 487
Post Re: Project Zeus
Jack Ripper wrote:
OMmotor i assume works with easydriver?


Yup, any Step/Dir driver, like the ED, or the pololu ones (even gecko ones if you really wanna spend some duckets =)

Jack Ripper wrote:
on the fast end with the Afmotor shield im stuck at 6 min end to end, i was able to get 5min end to end with the easydriver. Makes me wonder if the immediate limitations are the drivers not the motor.


Yes, the driver makes all of the difference in the world. On the motor shield, they have an h-bridge, which is functional, but not really "high performance," as there's no chopping circuit, AFAIK. The driver chip on the ED and related boards is made for nothing more than bi-polar stepping, with all the accompanying features to justify a $4+ street price for a single IC =) If you really want to get wild, go read the datasheet for the A4983 - it will illuminate you, after much head-scratching, into how exactly everything behaves and why *grin*

Jack Ripper wrote:
by blocking, i assume you mean i have to constantly tell it how far to move right? ie, move 200 steps, repeat?

yeah i was just going a single doublestep at a time.


By blocking, I mean the CPU is unable to do anything else while fulfilling the entirety of your request - hence, the CPU is "blocked" from servicing any other activities. You'll notice in the AFMotor code, there's a loop in there with pin change, delay, pin change, delay - even worse, since they're using an H-Bridge, they have to choose between four different pins to activate at exactly the right time in exactly the right sequence. While your move is occurring, nothing else can happen.

In non-blocking, your command returns pretty much immediately, so you may go on to do other stuff. In the case of OMMotor, the movement is achieved through an interrupt service routine, that runs at a fixed period of time. The maximum amount of CPU time that will ever be used by the actual stepping of the motor is 25% (max step rate, complex move, measured over 1 second), leaving 75% of your time available to do other stuff. Since we only have to deal with a single pin to make a step, and we fix that as pin 9, the code becomes extremely stream-lined (well, there's more to it than that, but ya dig...), such that it can hit 5,000 steps/second* even with quadratic easing applied to the move in real-time - while your code is off doing something else.

* - no, there's nothing you can do with an ED and the motor you have to hit 5,000 steps/second =)

Since OMMotor takes care of timing for you, and it also handles the complex easing calculations - all you really have to do is tell it what you mean "Go the whole distance of my track in one hour, accelerating for this time and decelerating for this time", and it just does it.

Jack Ripper wrote:
Project ZEUS is going to be the UI for Chronos. basically it will just take chronos over and provide a UI, i figured i would do it that way so i dont have to worry about the arduino controlling chronos getting all bogged down, it will just be a puppet.


That's exactly what the NM boards are made for - you make your UI, and it does the heavy lifting.

Jack Ripper wrote:
HOWEVER, i have been playing around with the MiniE engine that is shown on openmoco.org, and after a lot of grief (library issues with more than one rtclib out there)i have the basics of one assembled.

So i figured i would set it up with chronos, the results are so/so, i cant seem to get a speed control, worked out, and it struggles.


Yeah, I haven't played with his project yet - but it hits all the right buttons for the new guys. (i.e. simple enough to not have a steep learning curve, but just complex enough to be worth a project.) I, personally, don't have a need for such a simple UI, but I'm not exactly the best use-case here =) (We do some fun non-video stuff every now and then, we converted a broken stage zero dolly and a refurbished MX2 into an automated kevlar belt measuring and cutting machine last week. No software or hardware changes required, other than to move everything around so the hardware elements were in the right place. That thing is f*%^^#$ dangerous. Imagine a big, carbon-steel blade being forced into position with an air solenoid running at 100PSI! Yeah, we tore it down until we can build a proper safety cage. But, you see why I focus on "odd features" =)


Jack Ripper wrote:
Chronos itself is gettting a lot of attention, i believe we have 7 builds going on now in 5 countries. I think having the option of using the MiniE engine might be something some people are interested in, i dont plan to use it much myself though because im not a good enough programmer to start changing things around.


That great to hear - I noticed you were getting a lot of interest, which is very good! Funny thing was, a few years back, you'd be lucky to get 7 readers over a few months *grin* It all seems to have been catching on quite a bit over the past year or two.

!c


Tue Dec 13, 2011 4:53 pm
Profile
User avatar

Joined: Wed Mar 16, 2011 2:58 pm
Posts: 1348
Location: Denver, Colorado
Post Re: Project Zeus
i think im going to go with my own interface rather than MiniE, ill be sure to experiment around with OMmotor as well, sounds like the best way to go.

my partner is always bitching about how long it takes to manufacturer one of the chronos control heads, i showed him a triple stack arduino setup and now he really wants to see me put it into action.

i think i started on these boards maybe less than a year ago when i build speedy 2.2, the traffic has even picked up since then. I think a lot of it has to do with how many people have been working on thier own solutions for motion control, and the general crap economy has some people trying to do things themselves rather than paying for turn key systems.

combine that with some of the awesome timelapse work that is out, you start getting a lot more attention.

I just hope i can contribute to this community as much as possible. I doubt ill ever have the time and ability to carve a name out for myself doing timelapse the way some of you have, but if i find that one of my tools was used in one of those projects, it will feel pretty good.

now if i could just win the lotto so i dont have to go work on VoIP networks all damn day and i can focus on this stuff, ill be in heaven.

lol

_________________
http://www.BioLapse.com
http://www.TheChronosProject.com


Tue Dec 13, 2011 5:33 pm
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 56 posts ]  Go to page Previous  1, 2


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © phpBB Group.
Designed by Vjacheslav Trushkin for Free Forums/DivisionCore. pozycjonowanie