Hi Daniel
Sounds like you have a pretty good handle on the essence of a CNC
control system. I'm an old timer in the EMC business and have spent
quite a few years thinking about distributed processing in relation to
it. This post will appear to ramble a bit but hang in there and I think
you'll see the points that I'm trying to address.
As the system is now, we have a real advantage. We can view, track, and
modify the workings of our motion planner/executor. And we can
trigger/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 external
hardware using a serial comm port with latencies way to big to allow the
kind of communication we have now.
But at the same time, the original NIST models for our system made some
provision for distributed processing. While they were not easy to set
up, it was possible to simulate an entire manufacturing floor that
consisted of many individual EMC controlled machines linked to work
cells and those cells linked to tool hives, stock material supplies, and
completed part assembly and storage. In fact a professor I visited with
was doing exactly that, only not just simulated, he asked his students
to program and air cut parts in a 12 station mini lab/factory. A second
fellow, at one of the early "Fests" described to me a system where an
EMC 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 a
mini mill or lathe and worry that things are way to complex now. "Don't
screw it up by building in more ability, rather rip out all the stuff
not needed for that task!" I understand this need and yes we must
continue to push the software in the direction of ease of use.
At the same time, careful design of the system as we move forward should
allow 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 matrix
drawn on the NIST-ISD coffee cup. The columns are represented as Sense,
Model, Act and rows represent Local, Regional, and Global levels of
control. The communication links between each of the nine cells are
where 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 motion
planner. It might "sense" position through an encoder or an internal
pulse counter, "model" where position ought to be next by getting a
position 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 gets
complicated a bit by including things like limit switches and feedrate
override. Some of us insist that the motion planner honor all state
variables like contour and cornering and tool definitions while it works
in response to it's regional or global supervisor.
Some among us insist that we also ought to be able to see how well that
distant device is doing with its motion control. I'm not one to require
that that view of performance must be real time. I do insist that a
fine grained view of the operation of a distant device must be available
to the top level processor if I ask for it. Ideally I'd be able to load
that data into an instance of halscope along with a similar recorded
instance of supervisory stuff.
The example of the need for these abilities that I've used here before
is the Lunar Rover. All was well as it landed, deployed and began to
travel but it went belly up as soon as it tried to analyze a sample of
rock it dug up. The time allowed for one of the analytic processes
was not enough to complete the process and a real-time "priority
inversion" brought the whole rover to near death. Fortunately the
software designers allowed for inter-process communication and some
global variables that permitted reset and recalibration on the fly. IMO
we 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: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
