Hi,
Forgive me if I ramble in responce to Ray.
It is my understanding that the EMC project was orgiinally intended for
advanced machine control not just CNCs.
This would include robotics, process control, and CNCs. It is my belief
that if the system is designed correctly it could be used
for controlling a CNC mill or an atonomous robot. Current high end mills
and lathes use distributed processing with higher level oversite.
I don't expect to loose any of the current abilities by distributing the
processing as long as the comunication paths and rates are met.
The software should still run on a P.C. with a parilell port as well as run
standard motor controllers with a SSCNET I/II/III protocol.
The performance will scale depending on the hardware avalible.
As desribed by Ray you could run an entire factory or a 20 degree of freedom
arm and hand to pitch a baseball or include force control and catch and egg
without breaking it.
I like to work from the out side, in, on a project. At the bottom is the
hardware at the top is the system. Then we work our way to the middle.
For expample
Hardware control
1. Stepper motors,
a. Step and direction
b. Quad phase
c. PWM current control micro step
2. D.C. servos
a. Servo controllers digital control
b. D.A.C. control
c. PWM H bridge control
3. A.C. servos
4. Linear servos
5. Brushless D.C. motors
6. Numatic cyclinders
a. Moog valve control
b. PWM valve control
7. Hydralic
a. Moog valve control
b. PWM valve control
8. Fuel injectors
9. Pin drive
a. TTL
b. relay
c. current loop
d. voltage
Hardware sense
1. Pin sense
a. TTL
b. relay
c. Current loop
d. voltage
2. Encoder linear
a. absolute
b. incremetal
3. Encoder rotation
a. absolute
b. incremetal
Interfaces
1. paralell printer port
2. Rs232
3. RS488
4. Ethernet
a. 10 baseT
b. 100 baseT
c. 1000baseT
5. SSCNET
6.CAN buss
7. I2C
8 SPI
9 USB
a. USB 1
b. USB 2
10 Firewire
Then system types
1. CNC Mill
2. CNC lathe
3. Laser cutters
4. Robots
.a arms
b. welders
c. cutters
d. rumbi ( vacume )
5. Segways
6. Generators
a. diesel
b. turbin steam
c. turbin water
7. Ovens
a. electric
b. Gas
8. Cooling systems
etc This is where I need input.
This will give a scope of what the software will have to handle. We can
then define the numbering systems 8bits, 16 bits, 32,64 do we need floating
point or
is decimal points o.k. ? I have never known a CNC machine that fewer
significant digits then dynamic range. ( no need for floating point ). Mask
plotters
for I.C.s and electron microscopes this is not the case. The have large
dynamic range with few significant digits.
If you can forgive my spelling and me being a little slow at times. ( I do
have to make a living ) I would like to see what we can do.
Daniel
----- Original Message -----
From: "Ray Henry" <[email protected]>
To: "EMC developers" <[email protected]>
Sent: Sunday, March 08, 2009 10:07 AM
Subject: Re: [Emc-developers] EMC3 definition
>
> Hi Daniel
> Sounds like you have a pretty good handle on the essence of a CNCcontrol
> system. I'm an old timer in the EMC business and have spentquite a few
> years thinking about distributed processing in relation toit. This post
> will appear to ramble a bit but hang in there and I thinkyou'll see the
> points that I'm trying to address.
> As the system is now, we have a real advantage. We can view, track,
> andmodify the workings of our motion planner/executor. And we
> cantrigger/compare our views of these events based on any signal we
> wish.This is a serious thing to give up in order to connect to
> externalhardware using a serial comm port with latencies way to big to
> allow thekind of communication we have now.
> But at the same time, the original NIST models for our system made
> someprovision for distributed processing. While they were not easy to
> setup, it was possible to simulate an entire manufacturing floor
> thatconsisted of many individual EMC controlled machines linked to
> workcells and those cells linked to tool hives, stock material supplies,
> andcompleted part assembly and storage. In fact a professor I visited
> withwas doing exactly that, only not just simulated, he asked his
> studentsto program and air cut parts in a 12 station mini lab/factory. A
> secondfellow, at one of the early "Fests" described to me a system where
> anEMC controlled "factory" could reproduce itself to scale.Nano-technology
> using EMC.
> Now I hear and understand all the groaning from folk who want to run amini
> mill or lathe and worry that things are way to complex now. "Don'tscrew
> it up by building in more ability, rather rip out all the stuffnot needed
> for that task!" I understand this need and yes we mustcontinue to push the
> software in the direction of ease of use.
> At the same time, careful design of the system as we move forward
> shouldallow us to keep the NIST distributed processing vision alive.
> "Critics of RCS have objected to its rigidity, claiming “it
> forces a system to be built in a certain structure, even if it can
> be built more effectively in a different architecture.” This,
> however, misses the point of a reference model architecture. A
> reference model architecture is a canonical form, not a system
> design specification. Reference models can be implemented in a
> variety of ways. For example, RCS could be implemented with neural
> nets (at least in principle). "Many of the lower level features can
> be implemented by finite-state-machines and motion controllers.
> Higher level functions can be implemented by expert systems, Lisp
> machines, transputers, connection machines, or special purpose
> processing engines. The RCS reference model architecture combines
> real-time motion planning and control with high level task
> planning, problem solving, world modeling, recursive state
> estimation, tactile and visual image processing, and acoustic
> signature analysis. In fact, the evolution of the RCS concept has
> been driven by an effort to include the best properties and
> capabilities of most, if not all, the intelligent control systems
> currently known in the literature, from subsumption to SOAR [19],
> from blackboards [20] to object-oriented programming [21]. The
> modes in the RCS hierarchy are effectively autonomous agents,
> operating concurrently and independently in response to commands,
> status, and information messages." Found at
> www.isd.mel.nist.gov/documents/albus/Ref_Model_Arch345.pdf
> Let me repeat that conclusion.
> "The modes in the RCS hierarchy are effectively autonomous
> agents, operating concurrently and independently in response to
> commands, status, and information messages."
> The essential notion here is summed up in the three by three matrixdrawn
> on the NIST-ISD coffee cup. The columns are represented as Sense,Model,
> Act and rows represent Local, Regional, and Global levels ofcontrol. The
> communication links between each of the nine cells arewhere the really
> interesting discussions are located.
> (This ascii art is best viewed with a monospaced font)
> __________ __________ __________Global | | |
> | | | |__________| |__________| |__________|
> __________ __________ __________Regional | | |
> | | | |__________| |__________| |__________|
> __________ __________ __________Local | | |
> | | | |__________| |__________| |__________|
> Sense Model Act
> What you are working on is what Albus would refer to as a local
> motionplanner. It might "sense" position through an encoder or an
> internalpulse counter, "model" where position ought to be next by getting
> aposition command from the regional planner at the level above and "act"to
> drive the axis to that position.
> That seems a simple enough thing to do with a microprocessor but it
> getscomplicated a bit by including things like limit switches and
> feedrateoverride. Some of us insist that the motion planner honor all
> statevariables like contour and cornering and tool definitions while it
> worksin response to it's regional or global supervisor.
> Some among us insist that we also ought to be able to see how well
> thatdistant device is doing with its motion control. I'm not one to
> requirethat that view of performance must be real time. I do insist that
> afine grained view of the operation of a distant device must be
> availableto the top level processor if I ask for it. Ideally I'd be able
> to loadthat data into an instance of halscope along with a similar
> recordedinstance of supervisory stuff.
> The example of the need for these abilities that I've used here beforeis
> the Lunar Rover. All was well as it landed, deployed and began totravel
> but it went belly up as soon as it tried to analyze a sample ofrock it dug
> up. The time allowed for one of the analytic processeswas not enough to
> complete the process and a real-time "priorityinversion" brought the whole
> rover to near death. Fortunately thesoftware designers allowed for
> inter-process communication and someglobal variables that permitted reset
> and recalibration on the fly. IMOwe also need these abilities in our EMC2
> systems.
> Hope this helps.
> Rayh
>
> On Sat, 2009-03-07 at 15:33 -0700, Daniel Lee 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:
> SFADhttp://p.sf.net/sfu/XcvMzF8H_______________________________________________Emc-developers
>
> mailing
> [email protected]https://lists.sourceforge.net/lists/listinfo/emc-developers
>
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
