Interprocess Communication (IPC)
Communication between tasks is an important element of the
Mach philosophy. Mach supports a client/server system structure
in which tasks (clients) access services by making requests of other
tasks (servers) via messages sent over a communication channel.
The endpoints of these communication channels in Mach are
called ports, while port rights denote permission to use the channel.
The forms of IPC provided by Mach include
remote procedure calls (RPCs)
The type of IPC object denoted by the port determines the
operations permissible on that port, and how (and whether) data
There are two fundamentally different Mach APIs for raw manipulation
of ports—the family
and the family.
Within reason, both families may be used with any IPC object; however,
the calls are
preferred in new code. The calls maintain
state information where appropriate in order to support the notion
of a transaction. The calls
are supported for legacy code but deprecated; they are stateless.
[править] Настройка датчиков.
На вкладке Input Signals меню Config->Ports and Pins следует указать на какие контакты каких портов подключены Ваши датчики. По аналогии с предыдущей настройкой, Enable разрешает программе использовать данный датчик, Port# и Pin Number задают номер порта и его контакт соответственно, а Active Low указывает, будет ли вход срабатывать при появлении на контакте низкого уровня (галочка) или высокого (крестик).
Аварийные датчики крайних положений осей прописываются в строки <ОСЬ>++ и <ОСЬ>—. Датчик нуля — <ОСЬ> Home. Вход Probe используется для датчика определения высоты инструмента и габаритов заготовки,
EStop — кнопка аварийной остановки.
На вкладке Output Signals меню Config->Ports and Pins настраиваются управляющие сигналы. Из них следует отметить группу Enable — разрешение включения драйвера соответствующей оси. Заметим, что если Вы хотите использовать только один выход для включения всех драйверов, например, через плату коммутации, достаточно настроить только выход Enable1.
В некоторых платах коммутации(например PLC330b) вместо сигнала Enable для включения драйверов можно использовать Charge Pump.
Mach Kernel Abstractions
Mach provides a small set of abstractions that have been designed
to be both simple and powerful. These are the main kernel abstractions:
units of resource ownership; each task consists of a virtual address
space, a port
right namespace, and one or more threads.
(Similar to a process.)
Threads. The units of CPU execution within
space. In conjunction with memory managers, Mach implements
the notion of a sparse virtual address space and shared memory.
objects. The internal units of memory management. Memory
objects include named entries and regions; they are representations
of potentially persistent data that may be mapped into address spaces.
Secure, simplex communication channels, accessible only via send
and receive capabilities (known as port rights).
Message queues, remote procedure calls, notifications, semaphores,
and lock sets.
Clocks, timers, and waiting.
Ports, Port Rights, Port Sets, and Port Namespaces
With the exception of the task’s virtual address space,
all other Mach resources are accessed through a level of indirection
known as a port.
A port is an endpoint of a unidirectional communication channel
between a client who requests a service and a server who provides
the service. If a reply is to be provided to such a service request,
a second port must be used. This is comparable to a (unidirectional)
pipe in UNIX parlance.
In most cases, the resource that is accessed by the port (that
is, named by it) is referred to as an object. Most objects named
by a port have a single receiver and (potentially) multiple senders.
That is, there is exactly one receive port, and at least one sending
port, for a typical object such as a message queue.
The service to be provided by an object is determined by the
manager that receives the request sent to the object. It follows
that the kernel is the receiver for ports associated with kernel-provided
objects and that the receiver for ports associated with task-provided objects
is the task providing those objects.
For ports that name task-provided objects, it is possible
to change the receiver of requests for that port to a different
task, for example by passing the port to that task in a message. A
single task may have multiple ports that refer to resources it supports.
For that matter, any given entity can have multiple ports that represent
it, each implying different sets of permissible operations. For
example, many objects have a name port and
port (sometimes called the privileged port).
Access to the control port allows the object to be manipulated;
access to the name port simply names the object so that you can
obtain information about it or perform other non-privileged operations
Tasks have permissions to access ports in certain ways (send,
receive, send-once); these are called port rights.
A port can be accessed only via a right. Ports are often used
to grant clients access to objects within Mach. Having the right
to send to the object’s IPC port denotes the right to manipulate
the object in prescribed ways. As such, port right ownership is
the fundamental security mechanism
within Mach. Having a right to an object is to have a capability
to access or manipulate that object.
Port rights can be copied and moved between tasks via IPC. Doing so,
in effect, passes capabilities to some object or server.
One type of object referred to by a port is a port set.
As the name suggests, a port set is a set of port rights that can
be treated as a single unit when receiving a message or event from
any of the members of the set. Port sets permit one thread to wait
on a number of message and event sources, for example in work loops.
Traditionally in Mach, the communication channel denoted by
a port was always a queue of messages.
However, OS X supports additional types of communication channels, and
these new types of IPC object are also represented by ports and
port rights. See the section ,
for more details about messages and other IPC types.
Ports and port rights do not have systemwide names that allow
arbitrary ports or rights to be manipulated directly. Ports can
be manipulated by a task only if the task has a port right in its
port namespace. A port right is specified by a port name, an integer
index into a 32-bit port
namespace. Each task has associated with it a single port namespace.
As with most modern operating systems, Mach provides addressing
to large, sparse, virtual address spaces. Runtime access is made
via virtual addresses that may not correspond to locations in physical
memory at the initial time of the attempted access. Mach is responsible
for taking a requested virtual address and assigning it a corresponding
location in physical memory. It does so through demand paging.
A range of a virtual address space is populated with data
when a memory object is mapped into that range. All data in an address
space is ultimately provided through memory objects. Mach asks the
owner of a memory object (a pager)
for the contents of a page when establishing it in physical memory
and returns the possibly modified data to the pager before reclaiming
the page. OS X includes two built-in pagers—the default
pager and the vnode pager.
The default pager handles nonpersistent memory, known as anonymous
memory. Anonymous memory is zero-initialized, and it exists
only during the life of a task. The vnode pager maps files into
memory objects. Mach exports an interface to memory objects to allow
their contents to be contributed by user-mode tasks. This interface
is known as the External Memory Management Interface, or EMMI.
The memory management subsystem exports virtual memory handles
known as named entries or named
memory entries. Like most kernel resources, these are
denoted by ports. Having a named memory entry handle allows the
owner to map the underlying virtual memory object or to pass the
right to map the underlying object to others. Mapping a named entry
in two different tasks results in a shared memory window between
the two tasks, thus providing a flexible method for establishing
Beginning in OS X v10.1, the EMMI system
was enhanced to support “portless” EMMI. In traditional EMMI,
two Mach ports were created for each memory region, and likewise two
ports for each cached vnode. Portless EMMI, in its initial implementation,
replaces this with direct memory references (basically pointers).
In a future release, ports will be used for communication with pagers
outside the kernel, while using direct references for communication
with pagers that reside in kernel space. The net result of these
changes is that early versions of portless EMMI do not support pagers
running outside of kernel space. This support is expected to be
reinstated in a future release.
Address ranges of virtual memory space may also be populated
through direct allocation (using ).
The underlying virtual memory object is anonymous and backed by the
default pager. Shared ranges of an address space may also be set
up via inheritance. When new tasks are created, they are cloned
from a parent. This cloning pertains to the underlying memory address
space as well. Mapped portions of objects may be inherited as a
copy, or as shared, or not at all, based on attributes associated
with the mappings. Mach practices a form of delayed copy known as copy-on-write to
optimize the performance of inherited copies on task creation.
Rather than directly copying the range, a copy-on-write optimization is accomplished
by protected sharing. The two tasks share the memory to be copied,
but with read-only access. When either task attempts to modify a
portion of the range, that portion is copied at that time. This
lazy evaluation of memory copies is an important optimization that
permits simplifications in several areas, notably the messaging APIs.
Tasks and Threads
OS X processes and POSIX
are implemented on top of Mach tasks and threads, respectively.
A thread is a point of control flow in a task. A task exists to provide
resources for the threads it contains. This split is made to provide
for parallelism and resource sharing.
is a point
of control flow in a task.
has access to all of the elements of the containing task.
executes (potentially) in parallel with other threads, even
threads within the same task.
has minimal state information for low overhead.
is a collection
of system resources. These resources, with the exception of the
address space, are referenced by ports. These resources may be shared
with other tasks if rights to the ports are so distributed.
provides a large, potentially sparse address space, referenced
by virtual address. Portions of this space may be shared through
inheritance or external memory management.
contains some number of threads.
Note that a task has no life of its own—only threads execute
instructions. When it is said that “task Y does X,” what is
really meant is that “a thread contained within task Y does X.”
A task is a fairly expensive entity. It exists to be a collection
of resources. All of the threads in a task share everything. Two
tasks share nothing without an explicit action (although the action
is often simple) and some resources (such as port receive rights) cannot
be shared between two tasks at all.
A thread is a fairly lightweight entity. It is fairly cheap
to create and has low overhead to operate. This is true because
a thread has little state information (mostly its register state). Its
owning task bears the burden
of resource management. On a multiprocessor computer, it is possible
for multiple threads in a task to execute in parallel. Even when
parallelism is not the goal, multiple threads have an advantage
in that each thread
can use a synchronous programming style, instead of attempting asynchronous
programming with a single thread attempting to provide multiple
is the basic computational entity. A thread belongs to one and only
one task that defines its virtual address space. To affect the structure
of the address space or to reference any resource other than the
address space, the thread must execute a special trap instruction
that causes the kernel to perform operations on behalf of the thread
or to send a message to some agent on behalf of the thread. In general,
these traps manipulate resources associated with the task containing
the thread. Requests can be made of the kernel to manipulate these
entities: to create them, delete them, and affect their state.
Mach provides a flexible framework for thread–scheduling
policies. Early versions of OS X support both time-sharing and fixed-priority policies.
A time-sharing thread’s priority is raised and lowered to balance
its resource consumption against other time-sharing threads.
Fixed-priority threads execute for a certain quantum of time, and then are
put at the end of the queue of threads of equal priority. Setting
a fixed priority thread’s quantum level to infinity allows the
thread to run until it blocks, or until it is preempted by a thread
of higher priority. High priority real-time threads are usually
OS X also provides time constraint scheduling for real-time
performance. This scheduling allows you to specify that your thread
must get a certain time quantum within a certain period of time.
The traditional abstraction of time in Mach is the clock, which provides a set
of asynchronous alarm services based on .
There are one or more clock objects, each defining a monotonically
increasing time value expressed in nanoseconds. The real-time clock
is built in, and is the most important, but there may be other clocks
for other notions of time in the system. Clocks support operations
to get the current time, sleep for a given period, set an alarm
(a notification that is sent at a given time), and so forth.
The API is deprecated
in OS X. The newer and preferred API is based on timer objects
that in turn use as
the basic data type. is
a machine-dependent type, typically based on the platform-native
time base. Routines are provided to convert values
to and from other data types, such as nanoseconds. Timer objects
support asynchronous, drift-free notification, cancellation, and
premature alarms. They are more efficient and permit higher resolution
[править] Настройка параметров осей
Настройки скорости и ускорения
Окно Config->Motor tuning предназначено для настройки параметров перемещений осей станка.
Параметр Steps per задает количество импульсов STEP, которые необходимо сформировать для перемещения инструмента на 1мм. Он зависит не только от механики, но и от выставленного на драйвере режима деления шага. Velocity задает предельно допустимую скорость перемещения по оси, выраженную в мм/мин. Acceleration — задает максимальное ускорение по оси в мм/с^2. Пример расчета параметра Steps per для конкретной передачи: предположим что имеем винт ШВП с шагом 5мм/об, шаговый двигатель 200 шагов/об работающий в режиме микрошага 1/16. Получим
Steps per = (200 * 16) / 5 = 640 шагов/мм.
Таким образом дискрет перемещения на 1 шаг — 1 / 640 = 0.0015625мм.
Если Вы используете LPT порт компьютера, не забудьте установить значения 5us в полях Step Pulse и Dir Pulse (подробнее об этих настройках).
Зайдите в меню Config->Homing/Limits. Установите галочку в поле Reversed если вам необходимо изменить направление соответствующей оси. Эта настройка является аналогом смены полярности сигнала DIR в настройках Config->Ports and Pins->Motor Outputs.
Поиск нуля на оси
В том же окне Homing/Limits Вы можете настроить поиск нуля: поле Home Neg отвечает за направление движения при поиске нуля, а Home off задает координату, которую необходимо присвоить данной оси при нахождении датчика. Speed % — скорость (в % от максимальной) на которой «голова» будет двигаться к датчику.
=== Ограничение перемещения по оси
Программное ограничение перемещений (‘Soft Limits) настраивается там же, в Homing/Limits. Для этого в полях Soft Max и Soft Min необходимо задать предельно допустимые координаты по осям. С помощью кнопки Soft Limits в главном окне программы можно включать и отключать режим Soft Limits.