Это надо, что-бы у каждего привода выхода датчиков положения соединялись как с ЧПУ так и между собой, и ЧПУ распределяет кто
ведущий кто ведомый. Например при нарезки резьбы, ведущий привод шпинделя, поэтому привод допустим Z считывает импульсы датчика "S " и синхронизуется с масштабом которая ЧПУ прописала (что будет соответсвовать какому-то шагу), также и допустим
линейная интерполяция ведущий допустим "Z" , а ведомый "X" (здесь ведущий будет тот, у кого по расчетам будет наибольшая скорость).

Mach, конечно, хорошо. Но в дефолтовом виде таки плохо. Windows и realtime - слишком противоположные слова. Еще раз - нужен свой плагин, который и (по)мог бы победить болезни windows. В других вариантах я бы и не рассматривал Mach, как программу для управления станком или ботом.



А это откуда ? Еще есть ? На первый взгляд вроде бы логично. Наверно можно детализировать.

Что-то это меня настораживает:

Взято отсюда.
Получается, что Mach3 софтварно реализует ЧПУ на базе компьютера? С учетом требований к реалтайтму, возникает вопрос, а на сколько все это надежно?
Да и системные требования впечателяют, хотя и не сверхбольшие. Или это нормально и я отстал (не догнал) от жизни?
Просто в моем представлении ЧПУ это специализированная платформа (ну пусть IBM PC) с соответствующей ОС. А компьютер, пусть даже и под виндой, выполняет только функцию терминала - удобного рабочего места для оператора, наладчика. Но не как не выполняет функции непосредственного управления оборудованием.

Есть за что: явный перекос потока данных. От сервака с АВР в реалтайме да еще и режиме мониторинга требовать обрабатывать поставляемые данные - это что-то особеннаго Надо додумать. Оправдывает только то, что написано буквально "на кончиках пальцев" - что вижу, то и пою.

Это по-большей части головная боль контроллера верхнего уровня, надо только гарантировать доставку лога от сервака.


+1 И еще синхронизацию как-то сделать бы. Синхропакетом, что ли? Пока непонятно.



У меня старый ноутбук, на который еле-еле влезла ХР, печатная машинка, короче. Думал: ага, пристрою вещицу. Пень 300 МГЦ/192 ОЗУ... Блин, как поставил Mach3 - компьютер чуть ли не вздулся от "реалтайма"


Из головы, дурное дело - нехитрое

Slp_system_synchronize


Лол...у меня пентиум 2GHz временами зависает. Не, если кроме Mach больше ничего не пущать, то оно работает. Так что выше не просто так про отдельную и оптимизированную ось написано.


Неплохо. Подумывал написать нечто такое, та все некогда.

Не, я начал вкуривать, но пока чего-то все кажется, что это избыточно. Надо еще время для осознания.

Это не трудно. Можно реализовать что-то аля NTP.

К сожалению, винда - это тоже не атомные часы. Миллисекундные тики - они хорошо если с дискретностью 10-20мс идут. При частом вызове вот такого (а часов с меньшей дискретой в винде я не знаю)

d будет иметь дискрету, названную выше.

Получил платы, Ё-МОЁ. Таки умудрился накосячить. Если бы у меня был начальнег, уволил бы меня нахрен. В общем, все блины - первые

Хорошо, что не смертельно, можно и так запустить.

По теме. Есть еще вариант задания траекторий/профилей тупо в виде арифметического выражения. Влезет в m168 ?
В общем, на ум приходят все более текстовые версии протокола. Бинарные - мимо кассы, раз тут математика пойдет. А это, в свою очередь, облегчает навороты с синхронизмом, адресацией, маршрутизацией и т.п.

Давайте все-же определимся, кто будет этому контроллеру команды давать? Нужен ли тому, кто будет давать эти команды такой способ их задания?



Калькулятор на +-*/() - это очень маленькая софтинка

Как говорится "все уже придумано до нас" Десятки приводов ,тысячи портов с управлением под "Окнами" c
жестким реальным временем до 30 микросекунд на цикл http://www.beckhoff.ru/english/pdf/EtherCA...AT_Overview.pdf

Не, с синусами, логарифмами, экспонентами и степенями... А может и не надо

+1.

Не, это еще малая толика. Но не избыточно и не сложно. Описание, конечно, нужно, с картинками, чтобы хоть чуть-чуть понятно было.



Какие синусы, таблично бы успеть...



Mach3 и побыстрее может. Ядро способно работать на 100kHz, при том, что реально прерывания вызваются еще в два раза чаще.
Однако все упирается в цену ошибки. Пока он грызет фанеру вопрос с зависаниями не актуален, если запущена обработка чегой-нибудь более ценного, чем фанера с пенопластом, то тут уж задумаешься.

Вам бы сначала определится что за сервоконтроллер изобретаете.
Какие функции у этого сервоконтроллера? Это что, гибрид сервоусилителя и motion controller?
Куда подключены датчики обратной связи?
Кто синхронизирует оси?
Кто интерпретирует G-код?
Какая программа будет им управлять?
Не напишите же вы софт для ЧПУ и роботов. От этого и надо плясать. А большинство любительских программ используют step-dir и не нужна там никакая система команд и протокол.



Есть ли в свободном доступе документация по логической части EtherCAT? Дастаточная чтобы его можно было использовать в своих контроллерах.

Объясняю более внятно.


1. Цель: получить "гибрид сервоусилителя и motion controller"

2. Заложены 6 свободно программируемых дискретных входов по IEC61131-2 http://www.prolog-plc.ru/beck/docum/AN_SC1X3_IO.pdf которые закороткой одного стабилитрона можно превратить обратно TTL  

Из этих входов  2/3 идут на квадратурный энкодер, Step, Dir, Limit_Switch

3. Аналоговый вход 4..20 мА

4. RS-485 с растяжками и джампером на RC-termination 

Протокол уже строю по принципу Hayes-модема: с одной стороны богатая текстовая командная строка, затем переход к варианту MODBUS-RTU или скорострельный поток данных  непосредственно для командных регистров положения/скорости/момента.

Теперь про бинарный поток данных

Избежать "экзотики", видимо, не получится. Замечу еще полезное свойство: командные регистры не могут  измениться мгновенно, поэтому для низкоуровневого потока данных достаточно передавать приращения с гарантией их доставки, например инвалидацией после приема блока данных (адресат отправляет обратно CRC блока), отправитель решает, повторять ли передачу. В пакет входит Timestamp с "зерном" в 100 мкс  разрядности 16 бит, потому что реально никто больше 1 секунды молчать не будет.