NVEM Протокол. Реверс инжениринг.
-
AIG.Livny
- Новичок
- Сообщения: 3
- Зарегистрирован: 10 дек 2018, 13:15
- Репутация: 6
- Настоящее имя: Агибалов Иван
- Контактная информация:
NVEM Протокол. Реверс инжениринг.
Здравствуйте! Купил контроллер NVEM Mach3 и хотел бы использовать его без привязки к Mach, например от своей программы или от LinuxCNC. Решил посмотреть как общаются Mach и NVEM. В общем кое что-то удалось выяснить но еще многое не понятно. Чувствую, один я не справлюсь и прошу вас помочь. Высказывайте любые идеи, неизвестно что окажется верным, будем пробовать. Может быть вы знаете что-то. Причем тут скорее поможет математик чем программист. В общем вот что сделано и удалось узнать.
Подлючение
Mach3 с плагином NVEM запущен на ноуте с IP адресом 192.168.31.2. "Эмулятор" NVEM на стационарном компе с адресом 192.168.31.100.
Сначала я запустил Wireshark сниффер и посмотрел процедуру связи с настоящим NVEM. Файл прилагаю.
В начале все понятно. NVEM подключенный в сеть посылает раз в секунду пакеты UDP на широковещание 192.168.31.255 по порту 888 такого содержания "6162000000000001FCCF" назовем его NOL-сообщение (NVEM On Line) . Между посылками NVEM слушает пакеты UDP на порту 890 с содержанием "6162020000000001" назовем его MOL (Mach On Line).
Mach при включении слушает пакеты NOL, узнает IP NVEM'a и высылает пакет MOL. NVEM принимает MOL, узнает IP адрес Mach'a и иницирует соединение TCP c сервером Mach на порту 1888 (Mach-сервер, NVEM - клиент)
Работа.
Первым пакетом по TCP приходит от Mach настройки. Выяснил я это изменяя параметры в Mach и подключая заново. Пакет выглядит так: Выяснил что байты "00ссXX" - (где XX число) - это регистры для настроек. Например регистр "00cc01" хранит параметры инвертирования осей, полный запрос выглядит так: "00cc01 01cc050001060100" - где 01 (первый байт после адреса регистра) это флаги инвертирования остальные байт не изменяются.
Т.е. Сначала идут 2 байта "00cc" - флаг начала регистра, потом один байт - адрес регистра, потом идут данные разных длин.
Причем, регистры 05 и 06 могут быть длиннее или короче на один байт. Потому разбивка пакета усложняется.
Таким образом я создал список возможным регистров и длины данных для них:
Далее, выяснил что последовательность ee:dd:aa:bb - это разделитель, назовем EOL (End Of Line), обычно он приходит в конце сообщения но не всегда! т.е. В конце любого сообщения от Mach находится EOL. В сообщениях от NVEM никогда. EOL также встречается в пакетах движения как разделитель.
Бывает, что в пакете содержится: "00сс0a 00cc05000000" - т.е. Идут адрес регистра но без данных, затем идут уже другой регистр или конец строки. Предполагаю, что это означает "обнулить регистр".
Также, можно заметить в файле NVEM starting, что NVEM отправляет пакеты следующего содержания: 61:62:03:01:cc:08:ff:1f:00: - не меняется, затем идут значения регистров, думаю это координаты и что-то еще, например состояния входов.
В эмуляторе я отправляю такое сообщение через раз, так как не знаю когда его нужно отправлять.
Пакеты движения. Вот тут я пока ничего не понимаю. И хочу показать здесь, может у кого будут идеи. Я не совсем понимаю как вообще устроена совместная работа Mach и NVEM.
Я писал команды на движения в Mach, например G1 X10 и получал такие пакеты.
Осторожно! Под спойлером длинные пакеты. Там где написаны G- коды это просто комментарий, этого в пакете не было! Я разбил пакеты на строки по не нулевому разделителю просто так. Я не знаю как именно разделять эти пакеты.
Вот что я думаю, но это только предположение! : сначала идет байт 01 означающий команду на движение
затем я заметил, что следующая единица смещается в зависимости от оси по которой я двигал.
Таким образом, можно предположить что пакет имеет такую структуру: 01 XX XX YY YY ZZ ZZ AA AA BB BB CC CC Но что будут означать числа на этих местах мне не ясно.
Есть идея, что сообщение это кадр в котором записаны значения вектора в пространстве для всех шести осей... Дальше пока не знаю.
Прилагаю скриптик на Python'e для эмуляции NVEM. Правда при подключении Mach почему-то не пишет "NVEM connected" однако, соединение есть.
Если кому-то интересно, вы могли бы помочь выяснить какой регистр за какую настройку отвечает. Просто меняя настройку в Mach и смотря какой регистр изменится.
Подлючение
Mach3 с плагином NVEM запущен на ноуте с IP адресом 192.168.31.2. "Эмулятор" NVEM на стационарном компе с адресом 192.168.31.100.
Сначала я запустил Wireshark сниффер и посмотрел процедуру связи с настоящим NVEM. Файл прилагаю.
В начале все понятно. NVEM подключенный в сеть посылает раз в секунду пакеты UDP на широковещание 192.168.31.255 по порту 888 такого содержания "6162000000000001FCCF" назовем его NOL-сообщение (NVEM On Line) . Между посылками NVEM слушает пакеты UDP на порту 890 с содержанием "6162020000000001" назовем его MOL (Mach On Line).
Mach при включении слушает пакеты NOL, узнает IP NVEM'a и высылает пакет MOL. NVEM принимает MOL, узнает IP адрес Mach'a и иницирует соединение TCP c сервером Mach на порту 1888 (Mach-сервер, NVEM - клиент)
Работа.
Первым пакетом по TCP приходит от Mach настройки. Выяснил я это изменяя параметры в Mach и подключая заново. Пакет выглядит так: Выяснил что байты "00ссXX" - (где XX число) - это регистры для настроек. Например регистр "00cc01" хранит параметры инвертирования осей, полный запрос выглядит так: "00cc01 01cc050001060100" - где 01 (первый байт после адреса регистра) это флаги инвертирования остальные байт не изменяются.
Т.е. Сначала идут 2 байта "00cc" - флаг начала регистра, потом один байт - адрес регистра, потом идут данные разных длин.
Причем, регистры 05 и 06 могут быть длиннее или короче на один байт. Потому разбивка пакета усложняется.
Таким образом я создал список возможным регистров и длины данных для них:
Далее, выяснил что последовательность ee:dd:aa:bb - это разделитель, назовем EOL (End Of Line), обычно он приходит в конце сообщения но не всегда! т.е. В конце любого сообщения от Mach находится EOL. В сообщениях от NVEM никогда. EOL также встречается в пакетах движения как разделитель.
Бывает, что в пакете содержится: "00сс0a 00cc05000000" - т.е. Идут адрес регистра но без данных, затем идут уже другой регистр или конец строки. Предполагаю, что это означает "обнулить регистр".
Также, можно заметить в файле NVEM starting, что NVEM отправляет пакеты следующего содержания: 61:62:03:01:cc:08:ff:1f:00: - не меняется, затем идут значения регистров, думаю это координаты и что-то еще, например состояния входов.
В эмуляторе я отправляю такое сообщение через раз, так как не знаю когда его нужно отправлять.
Пакеты движения. Вот тут я пока ничего не понимаю. И хочу показать здесь, может у кого будут идеи. Я не совсем понимаю как вообще устроена совместная работа Mach и NVEM.
Я писал команды на движения в Mach, например G1 X10 и получал такие пакеты.
Осторожно! Под спойлером длинные пакеты. Там где написаны G- коды это просто комментарий, этого в пакете не было! Я разбил пакеты на строки по не нулевому разделителю просто так. Я не знаю как именно разделять эти пакеты.
Вот что я думаю, но это только предположение! : сначала идет байт 01 означающий команду на движение
затем я заметил, что следующая единица смещается в зависимости от оси по которой я двигал.
Таким образом, можно предположить что пакет имеет такую структуру: 01 XX XX YY YY ZZ ZZ AA AA BB BB CC CC Но что будут означать числа на этих местах мне не ясно.
Есть идея, что сообщение это кадр в котором записаны значения вектора в пространстве для всех шести осей... Дальше пока не знаю.
Прилагаю скриптик на Python'e для эмуляции NVEM. Правда при подключении Mach почему-то не пишет "NVEM connected" однако, соединение есть.
Если кому-то интересно, вы могли бы помочь выяснить какой регистр за какую настройку отвечает. Просто меняя настройку в Mach и смотря какой регистр изменится.
- Вложения
-
- NVEM wireshark.zip
- (29.51 КБ) 291 скачивание
- MX_Master
- Мастер
- Сообщения: 7489
- Зарегистрирован: 27 июн 2015, 19:45
- Репутация: 3113
- Настоящее имя: Михаил
- Откуда: Алматы
- Контактная информация:
Re: NVEM Протокол. Реверс инжениринг.
Иван, я ценю ваше время, потраченное на эту работу. Но в данном случае, накатать новую прошивку будет в несколько раз быстрее, чем разобрать весь протокол передачи и затем с костылями его применить. К тому же, если в оригинальной прошивки уже заложены какие-то лимиты, то одним протоколом передачи их не обойти. Я, кстати, разбирался в распайке и подключении микроконтроллера, и скажу прямо - китайцы на этой плате не используют аппаратные возможности МК для вывода сигналов. Отсюда и заявленные 200 КГц шагов вместо мегагерцев.
- Serg
- Мастер
- Сообщения: 21923
- Зарегистрирован: 17 апр 2012, 14:58
- Репутация: 5183
- Заслуга: c781c134843e0c1a3de9
- Настоящее имя: Сергей
- Откуда: Москва
- Контактная информация:
Re: NVEM Протокол. Реверс инжениринг.
IMHO проще и продуктивнее будет подружить Mach и Mesa - всё документировано, бери и делай.
А с NVEM (и прочими реверсинжениригами) запросто может получится так, что выйдет новая версия с несовместимым протоколом и начинай по новой...
А с NVEM (и прочими реверсинжениригами) запросто может получится так, что выйдет новая версия с несовместимым протоколом и начинай по новой...
Я не Христос, рыбу не раздаю, но могу научить, как сделать удочку...
- MX_Master
- Мастер
- Сообщения: 7489
- Зарегистрирован: 27 июн 2015, 19:45
- Репутация: 3113
- Настоящее имя: Михаил
- Откуда: Алматы
- Контактная информация:
Re: NVEM Протокол. Реверс инжениринг.
Кстати, интересно, почему месовцы сами не запилили плагины для Mach3 и 4? Количество проданных платок увеличилось бы в несколько раз.UAVpilot писал(а):IMHO проще и продуктивнее будет подружить Mach и Mesa - всё документировано, бери и делай.
- Serg
- Мастер
- Сообщения: 21923
- Зарегистрирован: 17 апр 2012, 14:58
- Репутация: 5183
- Заслуга: c781c134843e0c1a3de9
- Настоящее имя: Сергей
- Откуда: Москва
- Контактная информация:
Re: NVEM Протокол. Реверс инжениринг.
А они не пользуются Mach.
А продажи в области "ЧПУ на основе компа" у них далеко не основные.
Я тут где-то рассказывал про чувака, который начал делать плагин для Mach3 под 7i43 - там даже уже что-то "шевелилось", но всё кончилось тем, что он перешёл на LinuxCNC.
Я тут где-то рассказывал про чувака, который начал делать плагин для Mach3 под 7i43 - там даже уже что-то "шевелилось", но всё кончилось тем, что он перешёл на LinuxCNC.
Я не Христос, рыбу не раздаю, но могу научить, как сделать удочку...
-
AIG.Livny
- Новичок
- Сообщения: 3
- Зарегистрирован: 10 дек 2018, 13:15
- Репутация: 6
- Настоящее имя: Агибалов Иван
- Контактная информация:
Re: NVEM Протокол. Реверс инжениринг.
Вы правы. Я и сам думал о прошивке, но насчет скорости разработки сомневаюсь. А как на ваш взгляд должен работать контроллер? Он должен обрабатывать G-коды или управляться каким-то софтом с компьютера? Я в этой теме не разбираюсь, не знаю что лучше. Если с обработкой кодов, тогда можно подумать над адаптированием прошивок с ардуин. Кажется я где-то встречал порт grbl на stm32.
Михаил, вы говорите, что разбирались со схемой, а нет ли у вас этой схемы? Просто NVEM в шкафу прикручен, лень снимать.
Хочу убедиться. В принципе, даже если импульсные выходы не на таймерных ножках висят, то не особо страшно. Неудобно, но все-же сделать можно.
Изучу эту тему, плата неплоха, не хочу выбрасывать. Правда если с нуля программу разрабатывать, то не возьмусь.
По поводу mesa. Я просто поспешил
Купил NVEM, не изучив тему. Потом то я уже узнал что мне нужна была mesa.
Т.е. даже перепрошивка NVEM не лучший вариант. Это жаль, а то ведь и плата уже готовая...MX_Master писал(а):китайцы на этой плате не используют аппаратные возможности МК для вывода сигналов.
Михаил, вы говорите, что разбирались со схемой, а нет ли у вас этой схемы? Просто NVEM в шкафу прикручен, лень снимать.
Хочу убедиться. В принципе, даже если импульсные выходы не на таймерных ножках висят, то не особо страшно. Неудобно, но все-же сделать можно.
Изучу эту тему, плата неплоха, не хочу выбрасывать. Правда если с нуля программу разрабатывать, то не возьмусь.
По поводу mesa. Я просто поспешил
- selenur
- Почётный участник

- Сообщения: 4605
- Зарегистрирован: 21 авг 2013, 19:44
- Репутация: 1622
- Настоящее имя: Сергей
- Откуда: Новый Уренгой
- Контактная информация:
Re: NVEM Протокол. Реверс инжениринг.
http://robomechs.com/grbl-1-1-smt32f103c8t6/ - проверил, работает нормально.AIG.Livny писал(а):Кажется я где-то встречал порт grbl на stm32
Я реверсил в свое время протокол контроллера Planet-CNC, даже удалось написать свою программу для управления, но когда пользователи начали ей управлять своими контроллерами той-же самой модели выявились новые нюансы....
И реверсинг крайне трудоемкий процесс, который в большинстве случаев не стоит того, проще и быстрее подобрать другой контроллер, т.к. вместо того что-бы пользоваться станком, ты потратишь не один месяц на это занятие.
Мой сайт: http://selenur.ru
Исходники моих программ: https://github.com/selenur
Instagram https://www.instagram.com/zheigurov/
Исходники моих программ: https://github.com/selenur
Instagram https://www.instagram.com/zheigurov/
- Serg
- Мастер
- Сообщения: 21923
- Зарегистрирован: 17 апр 2012, 14:58
- Репутация: 5183
- Заслуга: c781c134843e0c1a3de9
- Настоящее имя: Сергей
- Откуда: Москва
- Контактная информация:
Re: NVEM Протокол. Реверс инжениринг.
"Чтобы продать что-нибудь ненужное, нужно сначала купить что-нибудь ненужное". Т.е. пол дела уже сделано.AIG.Livny писал(а):По поводу mesa. Я просто поспешилКупил NVEM, не изучив тему. Потом то я уже узнал что мне нужна была mesa.
Я не Христос, рыбу не раздаю, но могу научить, как сделать удочку...
- MX_Master
- Мастер
- Сообщения: 7489
- Зарегистрирован: 27 июн 2015, 19:45
- Репутация: 3113
- Настоящее имя: Михаил
- Откуда: Алматы
- Контактная информация:
Re: NVEM Протокол. Реверс инжениринг.
Планировщик с G кодами на ПК, генераторы импульсов отдельно. В данном случае мы имеем дело с отдельным софт генератором импульсов.AIG.Livny писал(а):А как на ваш взгляд должен работать контроллер? Он должен обрабатывать G-коды или управляться каким-то софтом с компьютера?
Я подключение смотрел по этим фоткам - http://www.cnc-club.ru/forum/viewtopic. ... 97#p441676AIG.Livny писал(а):Михаил, вы говорите, что разбирались со схемой, а нет ли у вас этой схемы?
Но у вас там может быть всё иначе. Так что придётся, всё-таки, сделать фотки крупным планом и разобраться.
-
AIG.Livny
- Новичок
- Сообщения: 3
- Зарегистрирован: 10 дек 2018, 13:15
- Репутация: 6
- Настоящее имя: Агибалов Иван
- Контактная информация:
Re: NVEM Протокол. Реверс инжениринг.
Во, набросал схемуТак что придётся, всё-таки, сделать фотки крупным планом и разобраться.
Все импульсные выходы на порту Е, а весь порт Е по даташиту имеет выходы от таймеров. Так что вполне есть смысл портировать сюда, например grbl.
Только надо дополнительно модуль связи по Ethernet писать, и загрузчик желательно.
- Вложения
-
- NVEM diptrace.zip
- (23.19 КБ) 232 скачивания
- MX_Master
- Мастер
- Сообщения: 7489
- Зарегистрирован: 27 июн 2015, 19:45
- Репутация: 3113
- Настоящее имя: Михаил
- Откуда: Алматы
- Контактная информация:
Re: NVEM Протокол. Реверс инжениринг.
Если внимательно перепроверить по пинам:AIG.Livny писал(а):Все импульсные выходы на порту Е, а весь порт Е по даташиту имеет выходы от таймеров.
- на PE7-PE15 выходят разные каналы первого таймера
- на PE4-PE6 выходят разные каналы девятого таймера
- на PA0 выходят первые каналы второго и пятого таймера
- на PC2,PC3 таймеры не выходят
Чтобы сделать из этого контроллера софт генератор (и частично аппаратный) для LinuxCNC, работы уйдёт не меньше чем на GRBL. При этом контроллер получится всё равно неполноценный, в отличии от платок MESA.
Я, кстати, не отговариваю. Если в арсенале есть достаточно свободного времени, то почему бы и да.