Проблема платы управления MKS DLC32 V2.1

Просматривает ж-коды вперед на максимально возможное количество кадров и складывает эти данные в буфер инструкций ШД.
Синтаксис проверяется при этом? И если есть ошибки, то пользователь получает об этом инфу? Если буфер ушёл на обработку, а новые кадры не пришли (задержались) или были пропущены часть кадров, то какова реакция на это GRBL, когда он пытается что-то просмотреть, чтобы отдать в буфер?
 
Валер, но это тогда булыжник в огород разработчиков.
Юр, все это очень непросто. Я пару недель занимаюсь отрисовкой данных, пришедщих в real-time по wi-fi. Там есть два ключевых момента: первое - жесткое распределение по ядрам: данные по wi-fi на одном ядре, отрисовка - на другом. Второе - да, имеют место быть помехи в управление экраном. У меня тестовая платка с проводами, провода длинноваты и пересекаются, поэтому помехи иногда проскакивают. И все это надо учитывать как в разводке ПП, так и в кодах. А как все это сделали китайцы - кто знает. Может ошиблись в разводке, может неправильно распределили работы по ядрам, а может и то, и другое.
 
Юр, все это очень непросто. Я пару недель занимаюсь отрисовкой данных, пришедщих в real-time по wi-fi. Там есть два ключевых момента: первое - жесткое распределение по ядрам: данные по wi-fi на одном ядре, отрисовка - на другом. Второе - да, имеют место быть помехи в управление экраном. У меня тестовая платка с проводами, провода длинноваты и пересекаются, поэтому помехи иногда проскакивают. И все это надо учитывать как в разводке ПП, так и в кодах. А как все это сделали китайцы - кто знает. Может ошиблись в разводке, может неправильно распределили работы по ядрам, а может и то, и другое.
Валер, вот умеешь ты убеждать. Согласен с тобой.
 
Синтаксис проверяется при этом? И если есть ошибки, то пользователь получает об этом инфу? Если буфер ушёл на обработку, а новые кадры не пришли (задержались) или были пропущены часть кадров, то какова реакция на это GRBL, когда он пытается что-то просмотреть, чтобы отдать в буфер?
Правильность ж-кодов проверяется. И есть там одна недоработка: не все типы комментариев ж-кодов учитываются, я для своих grbl-плат правил прошивку. Дальше не копал. Возможно, что Олег знает.
 
Правильность ж-кодов проверяется.
Тогда, получается, при помехах по Wi-Fi мы получаем банальные обрывы связи, как с USB, скорее всего. То есть тогда помехи точно программное обеспечение не пропускает без внимания и пользователь оповещён о них, чтобы копать где-то в другом месте.
 
Последнее редактирование:
Так можно делать только для тестов: работает, но помехи проскакивают. Не по wi-fi, в управлениии экрана. А для реальной работы ПП должна быть разведена аккуратно.
1784745163268.png
 
Тогда, получается, при помехах по Wi-Fi мы получаем банальные обрывы связи, как с USB, скорее всего. То есть тогда помехи точно программное обеспечение не пропускает без внимания и пользователь оповещён о них, чтобы копать где-то в другом месте.
Что по WIFI, что по USB, при нормально созданном канале связи ошибки при передаче-приеме должны быть исключены. Передается пакет данных со своей контрольной суммой. Если она не совпадает, то ожидается повтор приема этого же пакета, пока не придет правильный. При исчерпании либо количества неправильных пакетов, либо времени, работа должна прерываться с сообщением об ошибке.
GRBL имеет буфер и если он заполнен (не обработан), прием следующих данных прекращается. Передатчик должен ожидать готовности буфера к приему данных и только потом передавать. Каждый принятый и обработанный кадр подтверждается.
UDP используется для широковещательной передачи данных, не требуя подтверждения, и не используется для связи с устройством. В основном используется для поиска устройств, передачи видео/аудио данных и других. Например, передали точное время, кто принял, тот принял.
 
Синтаксис проверяется при этом?
Да. При этом, достаточно хорошо, для того, чтобы не пропускать команды, которые не могут быть корректно обработаны.
имеют место быть помехи в управление экраном
Сигнальный канал дисплея не передает пакеты с контрольными суммами, поэтому помехи в сигнальных линиях могут вызывать искажения картинки. В отличие от того же wifi или usb, где на каждом уровне абстракции осуществляется контроль целостности переданного.
 
Сигнальный канал дисплея не передает пакеты с контрольными суммами, поэтому помехи в сигнальных линиях могут вызывать искажения картинки. В отличие от того же wifi или usb, где на каждом уровне абстракции осуществляется контроль целостности переданного.
Именно такая система монтажа, ранее называвшаяся "путанка", и была наиболее помехозащищенной. Практикуемые сейчас параллельно идущие печатные линии связи и являются источником и приемником помех. Сделанный в конце 1970-х годов частотомер на 155 серии с помощью такого монтажа, был более помехозащищенный, чем на разведенной печатной плате. В середине 1980-х годов таким же способом сделанный компьютер Радио-86РК прекрасно работал. Наверное если сейчас включить, то тоже заработает.
Делал как то импульсный стабилизатор. Собранный навесным монтажом прекрасно работал, а перенес на печатную плату и получил кучу проблем для разбирательств.
 
Делал как то импульсный стабилизатор. Собранный навесным монтажом прекрасно работал, а перенес на печатную плату и получил кучу проблем для разбирательств.
потому что трассировка импульсников это не просто дорожками соединить.
 
В основном (UDP) используется для поиска устройств, передачи видео/аудио данных и других.

А ещё его любит SNMP, а это мониторинг, который по минимуму нагружает сеть.

оффтоп
 
Вы б для начала $$ запросили, мож там скорости/ускорения для космических челноков заданы.
 


Синтаксис проверяется при этом? И если есть ошибки, то пользователь получает об этом инфу?
По идее - да. На уровне парсера. И подавляющее большинство сообщений-ошибок "error<N>" как раз исходят от него, если что-то не так.
Если буфер ушёл на обработку, а новые кадры не пришли (задержались) или были пропущены часть кадров, то какова реакция на это GRBL, когда он пытается что-то просмотреть, чтобы отдать в буфер?
Применительно к Serial-порту и "классическому" варианту GRBL: в простейшем случае, сендер передаёт строку, парсер её получает, считая признаком целого кадра символ конца строки, "разбирает" и передаёт или на немедленное исполнение (реалтайм команды) или помещает в очередь планировщика, "ёмкость" которого для плат на Атмеге328 по-дефолту 16 команд линейного перемещения. Для плат на других МК (STM32, ESP32) длина приёмного буфера и очереди планировщика имеют бОльшие значения. Каждая принятая строка (кадр) после успешного парсинга и размещения в очередь планировщика сопровождается ответом "ок". Если очередь планировщика опустела, то ничего никуда не едет и ничего не происходит. Если в сериал-порт прилетела, по какой-то причине, неполная строка, и за какое-то время (таймаут) осталась таковой - будет выдана ошибка. Аналогично при ошибках разбора синтаксиса - вместо подтверждения "ок" прошивка выдаст какой-то "error". Такое может возникнуть при некорректном самописном G-коде, искажения информации из-за помехи или "косячных" CH340 (попадалось и такое).
При задержках пополнения или медленном пополнении входного буфера могут возникнуть "затыки" в работе станка, он будет работать рывками. Например, компьютер сильно загружен и сендер просто не успевает считывать и отправлять строки из файла, особенно, если это многочисленные короткие перещения.
Правильность ж-кодов проверяется. И есть там одна недоработка: не все типы комментариев ж-кодов учитываютс
Варианты с ";" и "(" в начале строки точно учитываются и такие строки игнорируются.
Если получено в виде <кадр><(комментарий)>, не уверен, надо попробовать. Думается, последний вариант может встретиться в самописных G-кодах или правленных пользователем, а не как результат работы постпроцессора. КМК, такое проще решать на уровне сендера, не отправляя такие строки или "отсекать" часть с комментами, дабы облегчить работу контроллера платы станка.

оффтоп
 
""ёмкость" которого для плат на Атмеге328 по-дефолту 16 команд линейного перемещения".
Скорее всего там ограничение в байтах. Команды могут иметь очень разношерстную длину.
 
Сверху Снизу