Совместная разработка системы ЧПУ.

Mach, популярные и не очень CAD, CAM. Обсуждение и разработка программ для управления станками.
sidor094
Мастер
Сообщения: 826
Зарегистрирован: 20 фев 2014, 09:13
Репутация: 81
Настоящее имя: Сергей
Откуда: Москва
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение sidor094 »

Если брать обмен между компом и контроллером движения(все равно внутренний это компонент или внешний),то можно, как наиболее критичный к скорости обмена,считать его внешним.
Если считать циклы равномерного движения по 10мс,то при скорости 115 килобит можем округлить возможность передачи до 115 байт.Это максимум.Надо бы сократиться.Например абсолютная позиция совершенно не интересна.относительную -же можно ограничить 2 байтами.Мало вероятно,что мы сможем выдавать более 3.2 мегагерцовые шаги.Далее ,зачем нужно передавать текущее состояние входов,оно наоборот должно возвращаться из контроллера в систему.Насчет номера строки так-же ,её можно ограничить двойным размером буфера команд,так как абсолютное значение не интересно,да и так то знать номер строки нужно только для того,чтобы компьютер мог точно знать ,какая именно строка буфера обрабатывается в данный момент.Это желательно знать "может быть"только при резких изменениях порядка выполнения программы.Зачем знать подачу,если она определена фиксированным временем цикла и количеством шагов за цикл так как ,я полагаю в данном случае интерполяция никакая не требуется(количество шагов по каждой координате задает комп).Еще вопрос, осями не переборщили?

Кстати и время паузы -зачем?

Кстати надо подумать над ответом от микроконтроллера.
alex_sar
Мастер
Сообщения: 1672
Зарегистрирован: 28 авг 2018, 17:13
Репутация: 278
Настоящее имя: Алексей
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение alex_sar »

MX_Master писал(а): 23 ноя 2022, 14:13 Много раз в теме звучал вопрос связи между компонентами. Компоненты могут работать рядом, а могут находится на удалённом устройстве. При пересылке данных в реальном времени между удалёнными компонентами, каждая микросекунда будет на счёту. Поэтому желательно придумать такой формат пакета данных, который бы содержал всю актуальную инфу, но при этом был бы компактным.
есть замечательная вещь - protobuf
советую глянуть, думаю здесь может пригодится
sidor094
Мастер
Сообщения: 826
Зарегистрирован: 20 фев 2014, 09:13
Репутация: 81
Настоящее имя: Сергей
Откуда: Москва
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение sidor094 »

Я бы убрал еще номер инструмента и метку времени.Алгоритм смены инструмента должен сидеть на компе.А контроллер только управлять выходами читать входа и передавать их значения компу.А что при этом происходит ему знать не обязательно.А меткой времени для компа будут служить циклы обмена с контроллером.И устройством определяющим скорость работы,или иначе говоря внутренние часы работы программы должен быть контроллер а не комп.Обороты шпинделя тоже можно сократить до 2байт.
sidor094
Мастер
Сообщения: 826
Зарегистрирован: 20 фев 2014, 09:13
Репутация: 81
Настоящее имя: Сергей
Откуда: Москва
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение sidor094 »

alex_sar писал(а): protobuf
Посмотрел,но что-то ничего не понял.
alex_sar
Мастер
Сообщения: 1672
Зарегистрирован: 28 авг 2018, 17:13
Репутация: 278
Настоящее имя: Алексей
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение alex_sar »

sidor094 писал(а): 23 ноя 2022, 15:25
alex_sar писал(а): protobuf
Посмотрел,но что-то ничего не понял.
вкратце. это универсальный бинарный протокол упаковки/распаковки (не передачи) данных.

описываете данные в формате .proto
компилируете свой .proto в нужный язык (для С тоже есть привязка)
получаете хидер и код чтобы распаковывать данные в ваши структуры и обратно.

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

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

как вы данные передаёте - ваше дело. это именно об упаковке.
AAN
Мастер
Сообщения: 284
Зарегистрирован: 14 апр 2015, 10:28
Репутация: 35
Настоящее имя: Антон
Откуда: Томск
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение AAN »

MX_Master писал(а): Много раз в теме звучал вопрос связи между компонентами. Компоненты могут работать рядом, а могут находится на удалённом устройстве. При пересылке данных в реальном времени между удалёнными компонентами, каждая микросекунда будет на счёту. Поэтому желательно придумать такой формат пакета данных, который бы содержал всю актуальную инфу, но при этом был бы компактным. Стессна, формат данных должен быть бинарным, слать текст очень дорого по времени. Числа можно паковать по 4 байта (32 бита, float или int), флаги 0/1 можно сложить в группы по 32 бита, состояние пинов общего назначения можно тоже сгруппировать по 32 бита.
Может сделать как на больших ЧПУ - аппаратная параллельная шина. Всё-таки может широкий шлейф в итоге и быстрее и дешевле, чем проталкивать состояние множества ног через последовательный интерфейс с потерями на кодирование-декодирование?
sidor094
Мастер
Сообщения: 826
Зарегистрирован: 20 фев 2014, 09:13
Репутация: 81
Настоящее имя: Сергей
Откуда: Москва
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение sidor094 »

AAN писал(а): Может сделать как на больших ЧПУ - аппаратная параллельная шина.
А где её взять на пк? ИСА сейчас не используется,а остальные требуют как минимум плис для реализации.Кроме того ,если использовать не ибм пс компьютер,так там вообще непонятно что будет.
Аватара пользователя
Mamont
Мастер
Сообщения: 1953
Зарегистрирован: 10 дек 2015, 12:21
Репутация: 382
Настоящее имя: Виталий
Откуда: РБ Минск
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение Mamont »

в протоколе обмена g code вообще нет смысла упоминать.
Я бы предлжил и́спользовать разные пакеты в зависимости от команды
1 запросить состояние : текущие машинные координаты, порты ввода, таймер задержки, движимся? частота ф.
2 записать параметры : кол координат, ускорения, максимальные скорости подачи, шимы (шпинделя и др) . Биты в порты вывада.
3 двигаться в абсолютные координаты с точным остановом по координатам n1 n2 n3 ...ni (4 байта на координату)с подачей ф.
4 двигаться в относительных координатах (2байта на координату). Ускорения разгон ложаться на ножки мку.
5 двигаться в относителтных координатах до тех пор пока не сработает сигнал ввода вывода.
6 двигаться в относительных координатах за интервал времени срабатывания входного импульса (нарезание резьб и тому подобное)
7 мягкий стоп
8 жеский стоп аларм.

Наиболее часто используемые пакеты надо чтоб были покороче
sidor094
Мастер
Сообщения: 826
Зарегистрирован: 20 фев 2014, 09:13
Репутация: 81
Настоящее имя: Сергей
Откуда: Москва
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение sidor094 »

Мне кажется такой протокол интересен для системы,у которой система чпу организована достаточно автономно.Если использовать планировщик,то многие Ваши пункты меню не нужны.
1)Зачем запрашивать состояние,таймер задержки и т.д.Изо всего этого нужны только состояния портов ввода.Все остальное отсылает ПК.Контроллер лишь выполняет.
2)кол координат не важно.Планировщик и так знает какими координатами он управляет.Ускорения тоже реализует планировщик.Наверно только Шимы и порты вывода.
\3б4)С этим и так понятно .не нужно.
5)И чего делать когда сработает сигнал ввода.Ведь движением и разгоном-торможением управляет планировщик.Тогда,наверно пусвть он и реагирует на сигнал.
6)Вопрос.Пока не понятно.
7.Мягкий стоп осуществляет планировщик.Так как торможением управляет тоже он.
8.А тут все ясно - отключаем питание драйверов.Все это делается на аппаратном уровне.


Я не уиверждаю категорически,Но если Вы не согласны ,Давайте думать.
Аватара пользователя
Mamont
Мастер
Сообщения: 1953
Зарегистрирован: 10 дек 2015, 12:21
Репутация: 382
Настоящее имя: Виталий
Откуда: РБ Минск
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение Mamont »

1 запрос машинных координат нужен, потому что комп не знает где сейчас нахдятся координаты. Потому, что будет буферизированная очередь . Она может быть представлена длительными перегонами.
По этой же причине мягкий стоп тоже не должен делать планировщик. Тисканул паузу, а там комаеда выполняется перемещения на 1 метр с подачей 50мм мин. Нажал и пошел на обед. Пришел, остановилась.

Таймер паузы отдельной командой нужен чтоб очередь команд не терялась.

Количество координат нужно для сокращения длины пакета. У кого то 2, у когото 6.

Аварийный стоп нельзя делать выключением питания драйвером. Фреза может подорваться и полететь. Попутное силовое фрерование это может устроить

Разгон торможение можно делать и планировщиком. Но резона не будет: при смене направления он должен передать 2 лишних отрезка с параметрами начальная скорость конечная скорость. Математика разгрона ляжет все равно на мку. Кстати их можно просто прописать к константах флеш памяти. Достаем ничего не считая. Если разбить на множество отрезков со своей скоростью, забьем весь протокол ими.

Тоже так , не категорично, просто мысли вслух
sidor094
Мастер
Сообщения: 826
Зарегистрирован: 20 фев 2014, 09:13
Репутация: 81
Настоящее имя: Сергей
Откуда: Москва
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение sidor094 »

Давайте определимся с алгоритмом планировщик-контроллер движения.
1 Как это комп не знает?.Комп -это планировщик ,и он выдает задание контроллеру.Это контроллеру не нужно знать реальные координаты.\Ему поступило задание на выдачу определенного количества шагов.Их он и должекн выполнить.А реальную координату после выполнения шагов знает компютер.И контроллеру они не к чему.Более того если ему их задать ,он даже не будет знать,что с ними делать.\\\контроллер не понимает ускорений.Контроллер не понимает конечную точку.\контроллер знает только сколько надо сделать шагов за заданное время и пытается их сделать более - менее равномерно в заданном интервале.\\еще контроллер может выставлять порты вывода и считывать порты ввода.Вот и все умения контроллера.
Mamont писал(а): Но резона не будет: при смене направления он должен передать 2 лишний отрезка с параметрами начальная скорость конечная скорость. Математика разгрона ляжет все навно на мку.
Так на хрена ,в таком случае,нужен планировщик?Он должен рассчитать все отрезки,лишние и нет.Иначе давайте делать умный контроллер.
Умному контроллеру не нужен планировщик.А планировщику не нужен умный контроллер.Должен остаться ОДИН!
sidor094
Мастер
Сообщения: 826
Зарегистрирован: 20 фев 2014, 09:13
Репутация: 81
Настоящее имя: Сергей
Откуда: Москва
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение sidor094 »

Либо контроллер просто более менее распределяет заказанные шаги ,за промежуток времени,либо он решает широкий круг задач без участия планировщика и в итоге планировщик не нужен.
Давайте решать как распределять мозги.Слишком много тоже вредно.
Аватара пользователя
Mamont
Мастер
Сообщения: 1953
Зарегистрирован: 10 дек 2015, 12:21
Репутация: 382
Настоящее имя: Виталий
Откуда: РБ Минск
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение Mamont »

Контроллер занимаясь ногодрыгом как раз и знает где точно находится координата. Комп не знает. Он дал задание сделать н шагов с периодом т. Потом он передал команду мягкого останова в случайный момент времени. Контроллер где то остановился.... Но где? По расчету времени ? Точность определения координинаты плюс минус трамвайная осьановка. Пользы от такого останово не будет.

А планировщик нужен для оптимизации траектории, скргления углов и снятия фасок
sidor094
Мастер
Сообщения: 826
Зарегистрирован: 20 фев 2014, 09:13
Репутация: 81
Настоящее имя: Сергей
Откуда: Москва
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение sidor094 »

Mamont писал(а): потому что комп не знает где сейчас нахдятся координаты. Потому, что будет буферизированная очередь .
10 мс - это тик времени.Грубо говоря- задержка реакции контроллера.Вы думаете ,реально это что-либо значит.Очередь все равно достаточно короткая по времени для изменения времени реакции оператора.Кроме того наличие планировщика подразумевает все основные изменения программы(типа нажатия стоп)должен решать планировщик.


Буфер нужен для двух причин
1. Для того.чтобы система не -реального времени(пк) могла нормально работать с системой реального времени -микроконтроллером.
2.Для того,чтобы система могла засинхронизироваться по готовности загрузки буфера микроконтроллера.Система должна синхронизироваться по микроконтроллеру ,а не наоборот .
sidor094
Мастер
Сообщения: 826
Зарегистрирован: 20 фев 2014, 09:13
Репутация: 81
Настоящее имя: Сергей
Откуда: Москва
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение sidor094 »

Mamont писал(а): Контроллер занимаясь ногодрыгом как раз и знает где точно находится координата. Комп не знает. Он дал задание сделать н шагов с периодом т.
Как это,комп дал задание и должен считать ,что контроллер выполнил задание правильно.То есть после выполнения заданного количества шагов координата переместилась в заданную точку.Иначе начинается проверки того -сего.Вы давая шаги на шаговый двигательЮсомневаетесь,что шаги сделаны?
Аватара пользователя
Mamont
Мастер
Сообщения: 1953
Зарегистрирован: 10 дек 2015, 12:21
Репутация: 382
Настоящее имя: Виталий
Откуда: РБ Минск
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение Mamont »

10 мс для оператора мелочь. Но координата двигаясь со скоростью 10м мин проедет 1.66мм . . Ну и задержки на педарачу по уарту. Контроллер остановился. Но ему надо сообщить на каком элементарном отрезке произошел останов.
Если отрезки достаточно короткие, то еще ладно. Но ведь все равно надо чтото передать в комп.. пусть будет вместо косвенных номеров пакета, которые необходимо раскурить , явное значение координат.
sidor094
Мастер
Сообщения: 826
Зарегистрирован: 20 фев 2014, 09:13
Репутация: 81
Настоящее имя: Сергей
Откуда: Москва
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение sidor094 »

Mamont писал(а): Потом он передал команду мягкого останова в случайный момент времени. Контроллер где то остановился.... Но где? По расчету времени ?
Не нужны такие команды.Они подразумевают,что контроллер может делать плавное торможение и т.д.Контроллер должен постоянно получать в буфер команды движения.Даже когда остановился.Просто изменение координат равно нулю.Тормозит,плавно останавливается-планировщик.Контроллер только выдает определенное количество шагов с заданноц частотой.Сколько выдать шагов с заданной частотой,решает планировщик.
Аватара пользователя
Mamont
Мастер
Сообщения: 1953
Зарегистрирован: 10 дек 2015, 12:21
Репутация: 382
Настоящее имя: Виталий
Откуда: РБ Минск
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение Mamont »

Большой буфер буфер окажет ощутимую задержку. Тактильно лаг в 0.3с уже ощущается
Аватара пользователя
Mamont
Мастер
Сообщения: 1953
Зарегистрирован: 10 дек 2015, 12:21
Репутация: 382
Настоящее имя: Виталий
Откуда: РБ Минск
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение Mamont »

Мягкий и жесткий стоп надо вынести из протокола. Слишком непредсказуемая реакция. Они пусть будут заведены на выделенные ножки контроллера.
Аватара пользователя
MX_Master
Мастер
Сообщения: 7465
Зарегистрирован: 27 июн 2015, 19:45
Репутация: 3088
Настоящее имя: Михаил
Откуда: Алматы
Контактная информация:

Re: Совместная разработка системы ЧПУ.

Сообщение MX_Master »

Каждый компонент может использовать только нужную ему часть общего пакета данных. Для GUI нужно одно, для вывода шагов - другое. Компоненты отправляют общий пакет данных другим компонентам. Получают пакет обратно. Если в пакете что-то поменялось, то начальный компонент что-то делает. Иначе - не делает.
Ответить

Вернуться в «Windows / Mach»