Переход на Modbus

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

Ок... В такую "нетривиальную" сеть, получится воткнуть какое то серийное устройство ? (вопрос риторический).  А в модбас сеть, можно будет воткнуть ЛЮБОЕ устройство заявленное как модбас, гланое, что бы поддерживаемая скорость и формат данных совпадали. И таких устройст для домашней автоматизации море.... Даже панель управления можно легко прикрутить. Еще раз обращу внимание, тут вопрос не в том , что лучше. Тут вопрос что тут более применимо. Я не рискну просто так сравнивать кан и модбас, не хочу выглядеть дебилом. Мы сравниваем, что лучше для хомавтомэйшен. В машине, я бы был за кан. 

MaksVV
Онлайн
Зарегистрирован: 06.08.2015

brokly пишет:
Ок... В такую "нетривиальную" сеть, получится воткнуть какое то серийное устройство ? (вопрос риторический).  А в модбас сеть, можно будет воткнуть ЛЮБОЕ устройство заявленное как модбас, гланое, что бы поддерживаемая скорость и формат данных совпадали. И таких устройст для домашней автоматизации море.... Даже панель управления можно легко прикрутить.

с этим полностью согласен

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

sadman41 пишет:

заддосить))

С недавних пор это любимое слова наших СМИ :)

MaksVV
Онлайн
Зарегистрирован: 06.08.2015

sadman41 пишет:
Тут брукли прав - сеть можно заддосить))

дак сдуру можно и йух сломать

sadman41
Онлайн
Зарегистрирован: 19.10.2016

Кстати, спонсер вишенки на торте - National Marine Electronics Association со стандартом NMEA2000. Connects devices used CAN bus technology ;) 

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

Вообще не помню где прочитал, но кан действительно родил один из автоконцернов, при конструировании гоночного боллида, стоял вопрос об облегчении автомобиля. Этот протокол позволил облегчить машину на 50-100 кг. И действительно скорость это плюс кана, но дом никуда не летит со скоростью 300 - 3000 км... Если свет в комнате включится с задержкой в полсекунды, то никто и не заметит. 

А вообще можно вспоминть и DMX512, DALI... Я тут не упоминаю более сложные или проприетарные протоколы, ибо это еще более осложняет дело. Вот DALI например.... Он ИМХО тормознее модбаса, какой то неуклюжий, кастрат... Но ведь используется в промышленности для управления светом и , заметьте, никто про скорость даже не заикается. Скорость в домашней автоматизации вопрос далеко не первый... Самый первый, наверное цена вопроса. И если в этом аспекте сравнивать модбас с каном, то кан будет далеко не в выигрыше.

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

sadman41 пишет:

Кстати, спонсер вишенки на торте - National Marine Electronics Association со стандартом NMEA2000. Connects devices used CAN bus technology ;) 

Ну дык нормально... Море же, там нужно TV тарелку быстро позиционировать, иначе кино смотреть не получится.

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

дак сдуру можно и йух сломать

Ну не скажите, сам видел такие штуки на авто, при выходе модулей из строя. При этом дохла вся сеть. Хотя если замкнуть линию модбас, будет тот же эффект. Но для модбас сетей существуют репетиры, которые призваны фиксить эти косяки. А вот с каном, такой фокус, легкой ценой, не пройдет.

MaksVV
Онлайн
Зарегистрирован: 06.08.2015

бош вроде кан придумал. Если вопрос в разнице цены 90 руб за трансивер очень важен, то незнаю. По мне дак преимущества все же есть перед модбасом. И можно за них немного переплатить. Другое дело, что в конкретной ситуации можно и модбас применить. У ТС то точно. 

Но вот с выключателями света которые я приводил выше, добавьте в шину один узел, обмен данными с которым не 1 байт, как с выключателем, а например байт 20.  и тут уже получим проблемы, т.к. пока мастер общается с этим узлом, все остальное стоит.

Ну и если лёг мастер на модбасе то всё, песец. Если к кане один из узлов лёг, то остальные работают дальше, хотя бывает что и всю сеть закоротит, тогда и тут вата. 

sadman41
Онлайн
Зарегистрирован: 19.10.2016

brokly пишет:

sadman41 пишет:

Кстати, спонсер вишенки на торте - National Marine Electronics Association со стандартом NMEA2000. Connects devices used CAN bus technology ;) 

Ну дык нормально... Море же, там нужно TV тарелку быстро позиционировать, иначе кино смотреть не получится.

Я к тому, что NMEA - текстовый протокол. Во всяком случае NMEA1083 - точно. Про 2000-й не копал, но если всё так же, то поверх кана гоняют ASCII ))

MaksVV
Онлайн
Зарегистрирован: 06.08.2015

brokly пишет:
сам видел такие штуки на авто, при выходе модулей из строя. При этом дохла вся сеть. Хотя если замкнуть линию модбас, будет тот же эффект. Но для модбас сетей существуют репетиры, которые призваны фиксить эти косяки. А вот с каном, такой фокус, легкой ценой, не пройдет.

чаще всего это шаловливые ручки или дешевые трансиверы TJA 1050. Они часто дохнут, решается установкой нормальных

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

sadman41 пишет:

Я к тому, что NMEA - текстовый протокол. Во всяком случае NMEA1083 - точно. Про 2000-й не копал, но если всё так же, то поверх кана гоняют ASCII ))

Это от безысходности. Как правило это пакет внутри этих 8 байт данных. А первый байт из этих восьми - номер фрейма.  Там ничего волшебного не придумаешь. Однако при таком подходе скорость падает до нельзя, а если при передаче строки еще и пакет побъется, то ваще беда...

MaksVV
Онлайн
Зарегистрирован: 06.08.2015

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

Это также одно из преимуществ кана (с контроллером), т.к. схема арбитража на шине аппаратная и самое главное, она отлажена. Не тратим на это время. 

MaksVV
Онлайн
Зарегистрирован: 06.08.2015

на автомобилях целые прошивки по кану в блоки льются и ведь быстро. Значит мультифреймы не проблема, я так понимаю. Врядли бы автопроизводители стали так широко этот протокол применять, если бы негатив, описанный brokly, присутствовал в таком явном виде. 

Logik
Онлайн
Зарегистрирован: 05.08.2014

weary пишет:

А что еще из готовых решений можете посоветовать? MQTT и ESP по воздуху, как то мне не нравится, да и железо моё рабоатет хорошо, вопрос именно в передаче данных.

Немного вник в MQTT  и стало ясно, что не что не мешает цеплять MQTT ethernet arduino.

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

 

Если понимать "готовые решения" как стандарты, то сразу вопрос, а нафига оно вам? если хотите зацепить какой девайс с уже стандартным протоколом - так и переходите на этот протокол, не мучайте форум. А если просто руки чешутся или траблы присутствуют, ну я бы делал так, учитывая что "железо моё рабоатет хорошо, вопрос именно в передаче данных". Набрал бы ESP по числу узлов сети, подключил бы их к существующему железу (т.е. вместо того канала связи что есть ставится ESP а старый контроллер даже не подозревает о этом) и связал бы через Wi-Fi по TCP/UDP. На что конкретно - мало инфы от Вас. Если еще и на ПК нужно заводить - вебсокет рулит. MQTT трогать не стал бы. Потом посмотрел бы где оправдано 2 контролера, а где и одного хватит, например для просто выключателя, и доработал.

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

на автомобилях целые прошивки по кану в блоки льются и ведь быстро. Значит мультифреймы не проблема, я так понимаю. Врядли бы автопроизводители стали так широко этот протокол применять, если бы негатив, описанный brokly, присутствовал в таком явном виде. 

Где и кто написал, что быстро !? Вы когда нибудь пытались залить новую прошивку в какой либо блок авто по кану ? Странный переход со спора с использованием цифр на субъективные доводы. Цифры не прокатили, будем говорить используя термины быстро-медленно ?

MaksVV
Онлайн
Зарегистрирован: 06.08.2015

А какие цифры не прокатили? 

MaksVV
Онлайн
Зарегистрирован: 06.08.2015

Прошивка 4 мб в моторник льётся минуты 2...3

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

А какие цифры не прокатили? 

Конкретные, см. выше, при одинаковой канальной скорости отношение полезной к служебной. 

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

Прошивка 4 мб в моторник льётся минуты 2...3

Супер, и о чем это говорит ? Это как быстро или медленно? По моему - очень медленно. Прошивка в ESP такого же размера льется 8 (ВОСЕМЬ !!!!!!) СЕКУНД !!!!!!!

sadman41
Онлайн
Зарегистрирован: 19.10.2016

Ну и за сколько потом твоя ESP-шка с места до сотни рвет? А скоко человек к ней в салон влазит? Вот то-то же... 

weary
Offline
Зарегистрирован: 19.01.2018

Для домашней автоматизации, скорость это не первое, что имеет значение. А вот возможность дополнить самодельную систему из ардуин заводским модулем это серьезное приемущество. Например сейчас решил поменять свои деревянные измерители PZEM004T на нормальный трех фазный счетчик в поддержкой RTU. Добавляю в мастер описание одного нового пакета  и готово, он забирает данные со счетчика. Вот это реальное приемущество

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

sadman41 пишет:

Ну и за сколько потом твоя ESP-шка с места до сотни рвет? А скоко человек к ней в салон влазит? Вот то-то же... 

А как у него потом мотроник на MQTT сервер по секъюрным каналам данные вываливает и считывает ? Не виснет ? Вот то-то же... !

weary
Offline
Зарегистрирован: 19.01.2018

Спрошу здесь глупый вопрос. Чем отличается 1 от 2 функции и 3 от 4 в Modbus. Что значит? что значение может быть входом и выходом? Какая разница мастеру, что читать? 

MaksVV
Онлайн
Зарегистрирован: 06.08.2015

brokly пишет:

MaksVV пишет:

А какие цифры не прокатили? 

Конкретные, см. выше, при одинаковой канальной скорости отношение полезной к служебной. 


Ну это компенсируется тем, что не требуется ждать своей очереди.

brokly пишет:

Супер, и о чем это говорит ? Это как быстро или медленно? По моему - очень медленно. Прошивка в ESP такого же размера льется 8 (ВОСЕМЬ !!!!!!) СЕКУНД !!!!!!!


А причем тут есп? Вроде с модбасом сравниваем. Ты же не по модбасу есп прошиваешь и делаешь это не в составе сети других МК. Так можно и гигабит езернет вспомнить или вообще FSB. Там еще более другой уровень слова быстро.

sadman41
Онлайн
Зарегистрирован: 19.10.2016

Function Code 2 и Function Code 3 предписывают слейву вернуть данные из разных областей памяти (различные смещения регистров). Так же и с остальными FC

nik182
Offline
Зарегистрирован: 04.05.2015

weary пишет:

Спрошу здесь глупый вопрос. Чем отличается 1 от 2 функции и 3 от 4 в Modbus. Что значит? что значение может быть входом и выходом? Какая разница мастеру, что читать? 

Для вас прочитить мануал на модбас и изложить своими словами? Сколько денег вы готовы выложить за эту работу? Неужели настолько сложно прочитать кучу разьяснений, даже по русски, в гугле по запросу modbus? Например первая ссылка https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.cta.ru/cms/f/385030.pdf&ved=2ahUKEwjU_bfF-pzjAhVnAxAIHTmhB7YQFjAAegQIAhAB&usg=AOvVaw0pSgGseqAE2hVgk6Z5wi7E&cshid=1562302228985

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

А причем тут есп? Вроде с модбасом сравниваем. Ты же не по модбасу есп прошиваешь и делаешь это не в составе сети других МК. Так можно и гигабит езернет вспомнить или вообще FSB. Там еще более другой уровень слова быстро.

А причем тут какой то блок мозгов мотора ? Раз перешли на бла-бла-бла давай уж все подряд сравнивать, да еще и с субъективными параметрами.

А вот про механизм "компенсации быстродействия" я бы с удовольствием понял, если конечно кто то расскажет :)

Есть логика. Представьте 10 человек хотят купить у одного продавца по банке газировки. Продавец может продать одновременно только одному покупатели. Как процесс отоваривания завершится быстрее с очередью или без ? :))) Уже и не знаю как объяснить, что существует логика, какая то систематизация.... Придите в магазин и попробуйте что то купить без очереди, а лучше с товарищем и ему поставьте такую же задачу.... :) Потом результат расскажите :)

Серьезно в кане у вас каждый узел будет пытаться передать свои данные куда то, используя только ему(узлу) известное расписание, при этом он все равно будет ждать освобождение линии, какой механизм использует - не важно. Нужны эти данные получателю или нет, отправителю по барабану. 

Модбас. Получатель сам спросит у отправителя данные тогда, когда ему это нужно. И отправитель ему просто ответит, не ожидая какой то очереди, у него спросили, он ответил. Причем его ответ точно нужен получателю, иначе его не спросят.

Какой иэ этих методов быстрее ? Почему ? - два вопроса, на которые нужно дать ответ используя вышеописаные тезисы. Ну или если нет согласия с тезисами оспорить их и опять же объяснить - почему ?

 

weary
Offline
Зарегистрирован: 19.01.2018

nik182 пишет:

weary пишет:

Спрошу здесь глупый вопрос. Чем отличается 1 от 2 функции и 3 от 4 в Modbus. Что значит? что значение может быть входом и выходом? Какая разница мастеру, что читать? 

Для вас прочитить мануал на модбас и изложить своими словами? Сколько денег вы готовы выложить за эту работу? Неужели настолько сложно прочитать кучу разьяснений, даже по русски, в гугле по запросу modbus? Например первая ссылка https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.cta.ru/cms/f/385030.pdf&ved=2ahUKEwjU_bfF-pzjAhVnAxAIHTmhB7YQFjAAegQIAhAB&usg=AOvVaw0pSgGseqAE2hVgk6Z5wi7E&cshid=1562302228985

 

Спасибо за ссылку.

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

nik182
Offline
Зарегистрирован: 04.05.2015

Давным давно, когда PLM были молодыми и протокол разрабатывался под не сильно гибкую логику казалось что так будет хорошо. Сейчас, когда Вы можете запрограмировать как угодно, можно не придерживаться рекомендаций и использовать адреса и команды как Вам угодно. Только помните, что если подключите старое устройство, оно может выдать результат по адресам согласно рекомендаций изначального стандарта. 

MaksVV
Онлайн
Зарегистрирован: 06.08.2015
brokly пишет:
А причем тут какой то блок мозгов мотора ? Раз перешли на бла-бла-бла давай уж все подряд сравнивать, да еще и с субъективными параметрами.
При том, что ЭБУ ДВС имеет непосредственное отношение к объектам обсуждения, в частности к CAN шине, т.к. все современные ЭБУ ДВС используют эту шину для обмена данными (требующих скорейшую актуальность) с другими блоками. Такими данными, например, являются положение педали газа, скорость автомобиля, обороты двигателя и т.д. Обновление этих параметров в шине происходит как правило с частотой раз в 10...20 мс. С такой частотой обновляются обычно  10...15 параметров на шине, чья скорость 500 кбит/с. 
brokly пишет:
Серьезно в кане у вас каждый узел будет пытаться передать свои данные куда то, используя только ему(узлу) известное расписание, при этом он все равно будет ждать освобождение линии, какой механизм использует - не важно. Нужны эти данные получателю или нет, отправителю по барабану.
Вы меня обвиняли в начале темы про нелепость спора. Ну ваши слова-то тоже уже смешны чес слово. Это не у меня, Брокли. Это в миллионах автомобилей!!! И заметьте, предмет повышенной опасности. Да они бьются, но уж точно не из-за того, что сообщения на шине теряются. Напротив, системы активной безопасности оперативно, да Карл!, оперативно реагируют на происходящее, предотвращая ДТП.  Подруливая , тормозя нужное колесо, сбрасывая газ, выправляют траекторию автобиля на необходимую. И ведь этим процессом рулит не один блок, а работают они сообща, обмениваясь данными по CAN шине. 
Собственно поэтому и появилась потребность в шине с такими характреистиками, потому как ни что существующее на тот момент не подходило. Уж точно не модбас. Поймите вы CAN он современнее. Да, лучшее враг хорошему. 
Неужели вы думаете, что инженеры и впрямь такие дереволазы и будут серить в шину инфой, которая никому из блоков не нужна? А если говорить про механизм ожидания освобождения шины, то что значит не важно какой ? Он един, это и есть фишка CAN шины. То бишь арбитраж на шине. Он хорошо продуман.
Это сделано для случаев вообще одновременного (что не так уж и часто при такой длине сообщений и скорости шины) появления сообшений в шине, но ведь кто запрещает построить схему, подобную запрос ответ? Клапа? Если вы внимательно читали стандарт CAN, там вообщето для этого придуман специальный тип сообщений RTR = запрос. У меня лично развод сообщений по времени сделан по проще. один узел шлёт всем текущее время. Эту инфу все используют как синхру, и с разной задержкой (а величина задержки уже зависит от их адреса) относительно синхры шлют в шину данные. В кане всё в ваших руках, как сделаете так и будет работать. Тут творческий подход, и тут прощаются ошибки разработчика. Защита от сбоев построена серьёзно.   
 
brokly пишет:
В системах автоматизации обязан быть мозг, центр. Распределенная сеть плохо подходит для управления светом, в этом случае свет будет включаться слишком долго. Подходите к вопросу с точки зрения целессообразности. Если ваша цель построить надежную и не дорогую домашнюю автоматизацию, анализируйте каждое слово в целеуказании. Если вам принципиально кан, это ваш выбор, он идет вразрез со здравым смыслом - дорогие транссиверы, лишняя служебная информация, ненужная "мифическая" скорость передачи. "В чем сила брат ?".
Вот, вот. Уже сам говоришь что будет работать долго. Я поэтому и применил CAN. Свет включается мгновенно, и сеть не чисто сделана только на свет, есть и много других функций.  CAN более универсальный. Он потянет всё, что потянет модбас. А модбас, вероятно,  потянет не всё, что потянет CAN. 
Мне не принципиален CAN, но там  где модбас не справляется, CAN вывозит. И это с учётом удорожания 80...90 руб. (по сравнению с RS485 модбас) за модуль связи по шине. 
Конечно, если вы собрались использовать какието там стандартные готовые устройства, то тут к бабке не ходи, только модбас. Только цена этих устройств обычно высока, и каков процент людей кто использует эти устроства в самопальной домашней автоматизации ? я думаю очень мал. Да и CAN стандартные устройства тоже бывают. 
brokly пишет:
А вот про механизм "компенсации быстродействия" я бы с удовольствием понял, если конечно кто то расскажет :) Есть логика. Представьте 10 человек хотят купить у одного продавца по банке газировки. Продавец может продать одновременно только одному покупатели. Как процесс отоваривания завершится быстрее с очередью или без ? :))) Уже и не знаю как объяснить, что существует логика, какая то систематизация.... Придите в магазин и попробуйте что то купить без очереди, а лучше с товарищем и ему поставьте такую же задачу.... :) Потом результат расскажите :) Модбас. Получатель сам спросит у отправителя данные тогда, когда ему это нужно. И отправитель ему просто ответит, не ожидая какой то очереди, у него спросили, он ответил. Причем его ответ точно нужен получателю, иначе его не спросят. Какой иэ этих методов быстрее ? Почему ? - два вопроса, на которые нужно дать ответ используя вышеописаные тезисы. Ну или если нет согласия с тезисами оспорить их и опять же объяснить - почему ?
Попробую объяснить, раз уж такие аналогии.  Модбас похож на электронную очередь или запись ко врачу по времени, если хотите. Вроде бы на первый взляд все граммотно и упорядочено. Но вот сколько отвести времени на каждого клиента, читай частоту сеансов связи со слейвами? Сделаем слишком мало времени, будет более быстрый поллинг, примем больше клиентов  (что гуд), но может нехватить этого времени, если пациент слишком долго жалуется (большой объём инфы). Сделаем слишком большое время на клиента, дак тогда мало за час клиентов примем (медленный поллинг). 
Да, мы можем не отводить определённое время на клиента. Но если один будет долго жаловаться, остальных подвигаем по времени и они ждут. 
Дак вот клиенты в таком случае (модбас) всегда ждут своего времени. И если вы пришли раньше или у вас внезапно резко заболел живот (не дай бог), вы придёте ко врачу, и даже если возле кабинета пусто, вам скажут - "Ожидайте своего времени!". 
И тут CAN выступает в роли скорой помощи. Готов помочь по мере необходимости -  сразу! когда это нужно. Это как в платной клинике (а модбас это как в государственной). CAN успевает прbнять как плановых больных так и экстренных, хотя у экстренным, конечно, быстрее пытаются помочь, у них более высокий приоритет (сообщения  с меньшим ID).
Вы приходите в CAN, да, возможно вам скажут, что сейчас занято, но как только освободится, мы сразу вас примем. Всё вежливо в общем, и так оно и происходит. Клиенты долго не ждут. Используется любое свободное пространоство в шине. Работа короткими манипуляциями, позволяющая, можно сказать, принимать нескольких клиентов сразу. Тут долго жаловаться одному клиенту не дают. Всех слушают одновременно (почти) по чуть чуть. 
А ваш пример похож на то, что газировку продают в данный момент , (а следующему клиенту только пиво, а следующему только сок).  И если хочешь глинтвейн, пропусти того, кому сейчас нужна газировка. Т.е вид товара, продающегося в данный момент времени, это номер узла. И глинтвейн, возможно, придётся ждать долго. (пока там всё пиво и газировку продадут). 
 
MaksVV
Онлайн
Зарегистрирован: 06.08.2015

brokly пишет:
Модбас. Получатель сам спросит у отправителя данные тогда, когда ему это нужно. И отправитель ему просто ответит, не ожидая какой то очереди, у него спросили, он ответил.

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

nik182
Offline
Зарегистрирован: 04.05.2015

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

sadman41
Онлайн
Зарегистрирован: 19.10.2016

Так обе стороны понимают парадигмы Модбаса и Кана, насколько я вижу. Философский спор идёт только за их примененимость в домашней автоматизации. Честно говоря - на таких скоростях и объемах передаваемых данных вообще нет особой разницы что использовать для выключения света в нужнике. Если IBM для этого целый MQTT придумала с жутким оверхедом по всем ресурсам, то CAN тут не сильно проигрывает модбасу. Лично мне нравится, что CAN более универсален в своей сущности и мне не надо арбитраж-прием-отправку пакетов вешать на мощности МК. 

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

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

Я не готов читать опусы, тем более без доказатательных цифирик. И спор далее вести считаю нецелесообразным. Удаляй дальше гланды автогеном :)

MaksVV
Онлайн
Зарегистрирован: 06.08.2015

ок , заканчиваем. ТС просил  плюшек, по моему мнению в CANe их больше, поэтому и предложил. Люблю шагать в ногу со временем знаете ли. А так конечно, и модбаса ТС при его задаче скорее всего будет за глаза. 

uni
uni аватар
Offline
Зарегистрирован: 24.09.2015

Специалисты с обеих сторон, подкиньте бесплатные анализаторы сигналов (программы), которыми вы реально пользуетесь для анализа шины в поле. Имеются в виду преджде всего графические утилиты, которые могут построить график множества сигналов. Только не надо посылать в гугл. Пожалуйста, что сами реально используете.