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
