Developing a new controller, Papywizard compatible

[fma38]

by fma38 » Wed Apr 21, 2010 6:14 pm

About multi-threading, why don't you use several µ-controllers, one for each axis?

[shutterdrone]

by shutterdrone » Wed Apr 21, 2010 6:50 pm

About multi-threading, why don't you use several µ-controllers, one for each axis?

Because at that cost, I might as well buy an ARM board.

A $30 uC can "truly" handle all the work required on a 3-4 (or even more) axis head in "something like real-time" when it is designed well. The problem arises when one tries to do too much at once, even when it really isn't needed "at once".

Obviously, if we're making our own circuit boards, we can probably get 2 arduino-like boards made as one-off's for about $10 or less each, if one forgoes anything fun like USB, bluetooth, etc. (And, by one-off, I mean making everything by-hand Same for PICs, they can be made cheaply too. But when you go to replicate it, you're going to look into higher production runs to keep that cost, or you're going to be soldering all day long (and probably wouldn't pay worth the time!).

But, if I'm buying 3 off-the-shelf uC boards, my cost might get near $100, not including stepper drivers, encoders, whathaveyou. At that price, I can go to friendlyARM and get a small board running a 400MHz chip, that runs linux and is easier to write code for *g*

You can do what you need, by taking a different approach (instead of thinking in 'threads' think in logical loops with interrupts) on a single uC board.

For example, if I switch quadrature encoders for pulse encoders, I don't need to "read" the encoders, instead, I can use pin change interrupts to update counters, and just check the value of the counters in my main loop, and then update a variable if I completed a motor move, but did not get the required count of pulses. For async stepper control, I use a timer-overflow based interrupt running on one of the hardware timers (ATMega168/328 has three of them), and velocity ramping for the motion can be handled through simple modulo operations (if( steps % ramp_interval ) { step_tm += ramp_lvl }
- rough example, btw!) or some other simple operation.

If we forgo the "easy" conventions provided by environments like Arduino (for example: favoring PORTx registers over digitalWrite()) we spend almost no time handling these myriad operations - and any I/O looks pretty normal. The goal, in my mind, is always to keep the cost down, as I want other people to be able to replicate my work without spending an arm and a leg If I can bust my hump a little bit, and get a single uC running four steppers, a camera, an LCD, and some buttons for a simple UI - I've succeeded. Then, the whole ordeal (including drivers) runs about $100-150 for the hobbyist DIY people. (Yes, that's my current plan for OM in the next release, including real-time positioning of motors by hand, and support for DC motors as well.)

But, for some, time is money - so they might prefer the easier path. It's all in how ya feel, and no way is right or wrong But, either way, to do async motor control on a single-threaded uC, you're going to need to use interrupts or slice your execution loop very lean and mean, otherwise you're going to block anything happening on that uC -- including asking it if it's done moving

!c

Last edited by shutterdrone on Wed Apr 21, 2010 6:51 pm, edited 1 time in total.

[panoguy]

by panoguy » Thu Apr 22, 2010 10:25 pm

Panoguy, did you ever figure out how to do the async motor control on the AVR? I couldn't tell from the posts. I wouldn't use something like that "pseudo-threading" library, as the overhead is unneeded for a fairly simple activity.
!c

Hi shutterdrone,
no I did not implement asynch motor control, even I use interrupts to trigger the motor and count the steps, I did not succeed to make it really asynchronous. After the ramps worked fine I did not spend too much time to investigate further. Also I'm still using Bascom AVR as programming language, which was fine for the beginning but also has limitations...
One one option would be to use intelligent stepper drivers which of course are more expensive.

[imme]

by imme » Fri Apr 30, 2010 8:17 am

Very informative and nice work by you people.

Frédéric I really appreciate your coding skills and writting software and plugins.

Panoguy your work is too good. But have you shared Circuit details and mechanical information anywhere on this forum? I am sorry I could only find ATMEL mc etc but no further details. Please Share your circuit and mechanical information. Frédéric has shared software details with us and it would be nice if you please share your work here.

Shutterdone I agree and appreciate your idea of cost effectiveness. I am hopeful it can be done with single u controller.

[Greg Nuspel]

by Greg Nuspel » Fri Apr 30, 2010 11:30 am

imme,

Some aspect of projects on here may not be open source. I know at one time Panoguy had some commercial products and maybe preparing to sell units again. Just like the telescope mounts these units are compatible with Papywizard offering people another option. I am guilty of the same aspirations with my hardware, but then I have to assemble fine tune and finance the purchase of parts.

[imme]

by imme » Sat May 01, 2010 7:57 am

Greg,

Its OK. Its your right to make and sell commercial units. But my point of view is that some if not complete part of project details must be open. I am not asking for complete details Just want to know some basic information about electronics and circuits. I hope you and panoguy will agree It will serve as guideline for using ucontroller based head with pappy.


-----------------------

immee

Last edited by imme on Sun May 02, 2010 8:12 am, edited 1 time in total.