On Wed, 2008-08-06 at 01:46 -0400, Sergey Izvoztchikov wrote:
> Kirk,
> 
> I kind of understood some of it, but with your explanations it's more 
> clearer now. I think there should be formula or algorithm, which would
> allow based on RPMs of the motor or its voltage and amperage to 
> calculate optimal frequency of reading from encoders, and this in turn
> will allow to calculate how often software should sample encoders. Is 
> that right ? Looks like finishing this design would require quite a
> lot more things to be work out. Many more than we initially thought.

It really isn't all that critical. The problems occur at high axis
speeds and/or high resolutions. For a Sherline class machine you are not
going to see either of these problems. The only down side of running
into performance issues is that you may need to sacrifice some axis
speed from your rapids, which are not used for machining, to gain
resolution. But practically speaking, it's not worth worrying about if
what you are primarily interested in is making parts. Just copy a system
that is known to work for your application. If you are more interested
in making the machine than parts, then working out the details can be
done with simple math, the specifications for the various parts and a
little guessing. It would be good to have a spreadsheet on the wiki for
doing some of the common calculations.

> Jeff's explanation suggests there could be a limit related to computer
> OS and overhead of switching tasks in Intel's CPUs would be one of the
> limiting factors. So it's important to know if software will be able
> to keep up.

Again, there are plenty of people getting good results with mediocre
PC's and software encoders and PWM. Most of the time we, or at least I,
go into these details because it is interesting to explore how EMC2
works, and the knowledge may come in handy when a problem does come up.
Just because we talk about problems doesn't mean that there _will_ be
problems. In the interest of understanding, EMC2 operates in two arenas,
realtime, and user-space or non-realtime(?). Realtime is for tasks such
as axis motion control that need to run in a time critical fashion. You
allocate the amount of processing needed for this with the base, servo
and trajectory thread settings in the .ini configuration file.
User-space is the left-over processing time to do the less time critical
functions like setting I/O pins like Flood, or updating the AXIS screen,
or checking your e-mail will waiting for your part to finish. When EMC2
is properly set up, if you start to run out of processing resources, the
user-space processes slow down, but not the realtime processes because
processing for realtime is reserved.

> Jon, 
> 
> Are the signals from encoders routed "as is" to EMC2 to decode or 
> there is a "logic" in your hardware which does partial or full 
> decoding before handing signals back to EMC2 ?

Jon, of course is the expert here, but... I believe the Pico controller
processes the encoder inputs and feeds EMC2 the counter results. 

> In design we're discussing here assumption was made that EMC2 would be
> able to decode encoder's signals and keep up with hardware. Doesn't
> look like it is always the case. Is the speed of CPU context switches
> a limit here or actually speed of parallel ports or PCI controller
> cards, or both ?

Others would be better at this question.

-- 
Kirk Wallace (California, USA
http://www.wallacecompany.com/machine_shop/ 
Hardinge HNC/EMC CNC lathe,
Bridgeport mill conversion, doing XY now,
Zubal lathe conversion pending
Craftsman AA 109 restoration
Shizuoka ST-N/EMC CNC)


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to