maximum step rate: count with analog-output microstepped drives that I
make, that is 4000 steps per revolution for example, but from those on
sale, there are 25600 steps per revolution at low cost.
How about 2000 steps per revolution and 2 meters per second maximum
positioning rate? (2 milion quadrature changes per second) (with 2G
acceleration). That is hardly anything new, Siemens automation systems
had 5G accel rate with some insane speeds with their laser tables.

On Sat, Mar 7, 2009 at 11:33 PM, Daniel Lee <[email protected]> wrote:
> Thank you for your feedback.  Because your desire is to keep the control
> loops in the PC
> I will proceeds on my own.
>
> I think what I will do is start with the EMC2 code base
> and put together some ideas.  If the only support I get is some
> peer review and specification feed back that is fine.
> When I am done if you are interested in merging the code that will be
> up to the EMC group.
>
> I think the steps I will proceed in is to
>
> 1. Put the rtos and some of the processes on an ARM7 platform
>    This will include the PID routines.
>    I will look at the verious ARM7s, some include USB and Ethernet, and
> find some off the shelf so that I
>   don't have to develope custom hardware.  At least untill I know the
> complete requirements.
>
> 2. Write a translating interface from the current rtos interface to a
> tcp/ip,serial, or usb interface to the new remote rtos.
>    This will allow your current User interfaces to think it is talking to
> your rtos on the pc.
>
> 3. Define a remote interface that can handle stepper and servo motor drivers
> as well as sensors ( encoders, swtichs etc ).
>    I own a Mazak SQT15MS with mitsubishi drivers and a mazatrol controller
> my goal is to design a comparable
>    control system where I can move a G code program from one machine to the
> other.
>
> My guess for the first stage hardware goal will be, unless you can give me
> some inputs.
>
> a. USB/serial interface
> b. 4 axis stepper controls Z,Y,X and tool changer as well as at least 16
> general purpos I/Os
> c. Max step rate (  I need some feed back here ) if we use 200 steps per rev
> and 10 revs per inch and 100inch/min will this be O.K. ?
> d. Spindle sync pulses for treading as well as spindle voltage speed
> control.
>
> olimex makes an ARM7 board for $62 I will start with this board for my
> tests.  It uses an Atmel AT91SAM7S256 processor.
>
> It also has an interface for a sdio flash card.  I will not be running linux
> this require much more memory and I don't need it to
> test the rtos and pid software.  I all ready have an rtos for ARM7s it would
> not make sense to run linux the put an rtos under
> linux if I can just run the rtos direct.
>
> Thank You.
>
> Daniel
>
>
> ----- Original Message -----
> From: "Jon Elson" <[email protected]>
> To: "EMC developers" <[email protected]>
> Sent: Friday, March 06, 2009 8:46 PM
> Subject: Re: [Emc-developers] EMC3 definition
>
>
>> Daniel Lee wrote:
>>>   If we allow for a hartbeat between external boards ( your servo time
>>> 1 ms ) we can
>>> expand the system to any size and mix servos,steppers and other types
>>> of hardware.  If we allow motion commands to be qued
>>> in advance by the pc EMC can operate in user space only.
>> But, that is the problem, the current scheme requires real-time
>> round-trip communication between EMC and the motion controller, and we
>> have strong reasons to want to keep it that way.  You can't have the PC
>> handling the servo PID loop if anything is queued or buffered.
>>>   We could move the stepping funtions into
>>> loadable drivers.  All trig funtions as well as kenetics would be
>>> handled in user space with simple intiger math used in the kernal
>>> space.  I have found that many floating point libarys are not
>>> completely reenterant and should never be used in interrupts.
>>> Also depending on the hardware platform the floating point libs
>>> contain differnet transidental funtions as well as some intel
>>> processors require software patches to work around bugs in the
>>> floating point processor.  All these issues make realtime
>>> floating point unrealiable or at least difficult to work with.  I
>>> would like to help devlope a system that is hardware independent.
>>> It could run on a MAC, ARM9, or other linux hardware.  In the near
>>> future there will not be printer ports on PCs.  It is hard to
>>> spend time on new software that can not be run on new PCs or
>>> notebooks.  I have a toughbook that can handle a coolant spill.
>>> It would be good to be able to run the code on that PC as well as a
>>> desktop.
>>>
>> Yes, and we could also convert EMC into Mach.  That's what Art Fenerty
>> did some years ago, we mostly wished him well, but we had specific and
>> we feel QUITE valid reasons for staying with the real-time servo model.
>>
>> We have a huge amount of floating point arithmetic in our various
>> drivers and other RT-mode modules, and have not found them to be
>> unreliable at all, at least for these desktop PC systems (that should
>> include x86, Mac and power PC).  Due to the dependence on a real time
>> environment, we are not free to move to any arbitrary embedded platform
>> that claims to support some Linux-derived kernel.  I know some people
>> have attempted a Mac port, I believe they did get something running, but
>> I don't know the details.  I don't recall what processor that system
>> had, but vaguely think it was PPC.
>>
>> The printer port is not as much of a limitation as it seems.  For a
>> number of reasons, laptops are not ideal for EMC, mostly having to do
>> with real time.  We need to work some more on PCI-e parallel ports to
>> make sure all our drivers work with them.  As long as desktop
>> motherboards have SOME kind of slots, this shouldn't be a problem.
>>
>> If you want to attempt to port EMC to an Arm9 or similar embedded CPU,
>> go ahead, but I think you will be in for a VERY long haul.
>> There are a large number of software dependencies that you will need to
>> solve.  Some may be fairly simple, I fear a few of them are going to be
>> major.
>>
>> I can't speak for the rest of the EMC community, but if you want to move
>> EMC2 to a totally non real-time environment, I don't think this is going
>> to get a lot of developer support!  (I can almsot hear the guffaws
>> now!)  Of course, there IS a way to run EMC entirely non-real time, that
>> is the "sim" environment.
>>
>>
>> Jon
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
>> CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>> Enterprise
>> -Strategies to boost innovation and cut costs with open source
>> participation
>> -Receive a $600 discount off the registration fee with the source code:
>> SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Emc-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Emc-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to