ViKo 1 13 сентября, 2021 Опубликовано 13 сентября, 2021 · Жалоба 1 час назад, Arlleex сказал: Ага, пришло с интервалом 2t или 2.5t - к кому относить? Выкидывать. Пока 3.5t не придёт. 1 час назад, Arlleex сказал: в четверти из них они за символ принимают 4-битную тетраду, получая 6 и 14 бит для 1.5t и 3.5t О, я среди них был. Но расчет времени по приведённому выше абзацу меня переубедил. На данном этапе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 13 сентября, 2021 Опубликовано 13 сентября, 2021 · Жалоба 2 hours ago, ViKo said: сколько битов пауза равна в Modbus TCP? А если вопрос поставить по-другому: не менее скольки бит должна быть пауза, чтобы приёмник сбросил свой буфер и принял решение, что это была поемеха вместо данных? Не помню откуда картинка. Но Вам не нужно точно отсчитывать 3.5 символа. Вам надо не менее, чтобы считать, что это пауза, и данные больше не придут. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 13 сентября, 2021 Опубликовано 13 сентября, 2021 · Жалоба 6 минут назад, haker_fox сказал: не менее скольки бит должна быть пауза, чтобы приёмник сбросил свой буфер и принял решение, что это была помеха вместо данных Скорости будут низкие, обусловленные особенностями проводных соединений. А быстродействие микроконтроллера достаточно большое, STM32. Я предпочел бы сделать по стандарту. Но он плохо описан. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 5 октября, 2021 Опубликовано 5 октября, 2021 (изменено) · Жалоба On 9/13/2021 at 2:18 PM, Arlleex said: Ага, пришло с интервалом 2t или 2.5t - к кому относить? Выкидывать или ждать дальше? А с чего бы ждать, а с чего бы выкидывать? Здесь не все так тривиально, как может показаться. На этот счет не один десяток разработчиков переср*лся, и у каждого своя правда Я понимаю это так (с учетом картинки из поста @haker_fox): 1. идут байты с меньшими промежутками, чем 1.5t - принимаем байты в буфер; тут пошла пауза, она длится и длится; насчитали паузу >=3.5t - пакет полный, отдаем на обработку вышестоящему уровню. Все хорошо. 2. идут байты с меньшими промежутками, чем 1.5t, - принимаем байты в буфер; пошла пауза, уже >= 1.5t: ага, ждем, что будет дальше... Не прошло и 3.5t, как появляется байт: тогда игнорируем предыдущие байты, считаем этот байт первым в пакете, далее - пункт 1. Я вижу такое построение как возможность для slave типа во время передачи ответа сказать: "ой, не в тему отвечаю, погодь 1.5t, забей на предыдущий базар, шефу наверху пока ничего не сообщай, я быстренько тут перепакую... а, вот, понеслась по-новой". Эффект - вышестоящему уровню ничего не сообщается о сбоях. Всвязи с этой темой - мой вопрос. Для тестирования modbus RTU через PC предлагаются USB-RS485 адаптеры и всякие программы для PC. Есть "классические" адаптеры с FTDI|Silabs чипами, есть дешевые, узнаваемые по дизайну, с CH340. И те, и другие создают виртуальные COM-порты. Очевидно, что PC не является системой реального времени, плюс буферизированный и пакетированный прием по USB - в результате прием в приниципе таки будет работать, если делать паузы по приему на уровне программы на PC достаточно длиными. Это в идеальный условиях, особенно когда периодичность запросов не критична. В системе, которую я помогаю разрабатывать, хочется выжать максимум скорости при опросе датчика. Это означает, что хочется посылать следующий запрос, как только пришел ответ на предыдущий. То есть, на высоких скоростях на линии уже после 1.75мс считать принятый пакет полным, быстренько его куда скинуть и запросить следующий. Очевидно, что для PC эти 1.75мс весьма критичны и размыты. Я сделал программу, которая с помощью multithreading рубает так быстро, как это возможно (загрузка CPU до 40% из-за этого). Однако, как только паралелльно на PC начинает работать программа отображения видео с камеры наблюдения (так надо), начинаются ошибки приема пакетов, т.к. для программы приема возникают паузы более 1.75мс еще внутри пакетов. Это объяснимо и ожидаемо. Об этом в одном немецком форуме писали ( https://www.mikrocontroller.net/topic/181372 ), и там приведена цитата от FTDI: "The only mechanism we have for resolving data loss on a serial link is to use flow control.It is also worth noting that although we do not claim modbus support, it has been reported from other users that although modbus ascii mode works, modbus rtu will not. This is a consequence of RTU mode relying on specific inter byte gaps which USB cannot meet as it is a polled system sending data in packets as opposed to individual bytes." Очевидно, что решением может быть только специализированный USB-RS485 адаптер, который знает о modbus, принимает пакеты и отправляет по USB наверх только полные пакеты. Видел кто такое? Это своего рода gateway, однако я что-то не нашел в приемлемом ценовом классе. Всякие modbus RTU to Ethernet пока не рассматриваются. Что посоветуете? Изменено 5 октября, 2021 пользователем KnightIgor Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 190 5 октября, 2021 Опубликовано 5 октября, 2021 · Жалоба 1 час назад, KnightIgor сказал: Очевидно, что решением может быть только специализированный... Отсюда и далее у меня уже были потуги не то что соблюсти тайминги (этой задачи не стояло как таковой), а принять все что отправил с платы. Винды и другие не ОСРВ-оси как бы особо не причем, а вот к производителям мостов USB-UART, в силу ограниченного объема буфера, вопросики. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 5 октября, 2021 Опубликовано 5 октября, 2021 · Жалоба 55 минут назад, KnightIgor сказал: Очевидно, что PC не является системой реального времени, плюс буферизированный и пакетированный прием по USB - в результате прием в приниципе таки будет работать, если делать паузы по приему на уровне программы на PC достаточно длиными. Это в идеальный условиях, особенно когда периодичность запросов не критична. В системе, которую я помогаю разрабатывать, хочется выжать максимум скорости при опросе датчика. Это означает, что хочется посылать следующий запрос, как только пришел ответ на предыдущий. То есть, на высоких скоростях на линии уже после 1.75мс считать принятый пакет полным, быстренько его куда скинуть и запросить следующий. Очевидно, что для PC эти 1.75мс весьма критичны и размыты. Я сделал программу, которая с помощью multithreading рубает так быстро, как это возможно (загрузка CPU до 40% из-за этого). Однако, как только паралелльно на PC начинает работать программа отображения видео с камеры наблюдения (так надо), начинаются ошибки приема пакетов, т.к. для программы приема возникают паузы более 1.75мс еще внутри пакетов. Это объяснимо и ожидаемо. Это "объясняемо и ожидаемо" когда начинают быдлокодить сразу, не читая документации. Возможности WinAPI изучили? Про SetCommTimeouts() читали? Раз пишете, о каких-то миллисекундах, отслеживаемых на уровне приложения, значит делаем вывод, что не читали. Нормально написанное ПО должно эту работу отдавать системному драйверу, а не пытаться само. Ну или тогда уж - писать свой драйвер уровня ядра. Понятно, что если отслеживать интервалы на уровне приложения, то всё будет сильно зависеть от общей загрузки системы. Но системный сериальный драйвер должен работать на бОльшем приоритете и не зависеть от прикладной загрузки (на прикладном уровне). Хотя конечно разрешение (1мс) этих функций довольное грубое... Да и приоритет можно приподнять тому потоку ОС, который работает с COM-портом (соответствующими функциями WinAPI). И процессу - тоже. 55 минут назад, KnightIgor сказал: Очевидно, что решением может быть только специализированный USB-RS485 адаптер, который знает о modbus, принимает пакеты и отправляет по USB наверх только полные пакеты. Видел кто такое? Про USB не знаю. И сомневаюсь, что есть что-то достойное. Но вот у меня сейчас на компе стоит COM-мультипортовка (4 порта). Такая: https://www.photopoint.lv/datoru-komponentes/568769-i-tec-pci-e-pos-card-4x-serial-rs232-with-power-output-dc-5-12v#product-info_tab Как UART-ы работают отлично. В свойствах можно поставить режим RS-485. Но не пробовал - не нужно. Скрытый текст Думаю: с PCI-портами тайминги должны выдерживаться лучше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 7 октября, 2021 Опубликовано 7 октября, 2021 · Жалоба On 10/5/2021 at 2:14 PM, jcxz said: Это "объясняемо и ожидаемо" когда начинают быдлокодить сразу, не читая документации. Возможности WinAPI изучили? Про SetCommTimeouts() читали? Раз пишете, о каких-то миллисекундах, отслеживаемых на уровне приложения, значит делаем вывод, что не читали. Нормально написанное ПО должно эту работу отдавать системному драйверу, а не пытаться само. Ну или тогда уж - писать свой драйвер уровня ядра. Да и приоритет можно приподнять тому потоку ОС, который работает с COM-портом (соответствующими функциями WinAPI). И процессу - тоже. Узнаваемый стиль @jcxz: в ответе надо сначало обос...ать спрашивающего, а потом можно и по существу. Ладно. Я пишу под lazarus и пользую LazSerial компоненту, которая и обращается к WinAPI и ставит все эти SetCommTimeouts() и подобное. Ожидание событий там происходит в отдельном thread с синхронизацией к основному потоку. Я влез в код (он же открыт) и повысил приоритет потока ожидания, после чего заработало надежнее. Все же, как ни крути, режить задачу на пользовательском уровне (без специфического драйвера порта) окончательно будет невозможно, о чем FTDI в моей цитате и говорит. Поэтому мой вопрос и сконцентрировался на устройстве USB-RS485, которое могло бы поддержать modbus, а уж потом кинуть готовый пакет наверх по USB. Похоже, такого устройства нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 8 октября, 2021 Опубликовано 8 октября, 2021 · Жалоба On 10/5/2021 at 3:37 PM, KnightIgor said: Очевидно, что решением может быть только специализированный USB-RS485 адаптер, который знает о modbus, принимает пакеты и отправляет по USB наверх только полные пакеты. Видел кто такое? Это своего рода gateway, однако я что-то не нашел в приемлемом ценовом классе. Всякие modbus RTU to Ethernet пока не рассматриваются. Что посоветуете? Делаем такие. Есть версии с прошивкой, поддерживающей modbus аппаратно, с настройкой параметров, в том числе и временных. Пишите, отвечу на вопросы. http://labsk.ru/products/interfaces/rs485/default.aspx Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 190 8 октября, 2021 Опубликовано 8 октября, 2021 · Жалоба 10 минут назад, Седой сказал: Пишите, отвечу на вопросы. А можно я спрошу? Почему вот этот адаптер самопроизвольно отваливается от CAN-hacker-а? При этом наши переходники - не отваливаются... Почему не предусмотрен TX-FIFO сообщений? Отправляю 3-5 посылок друг за другом без интервала - на CAN-е вижу только одну (первую)... На сайте никаких новых прошивок нету - по крайней мере, я не нашел. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 8 октября, 2021 Опубликовано 8 октября, 2021 · Жалоба 7 minutes ago, Arlleex said: А можно я спрошу? Почему вот этот адаптер самопроизвольно отваливается от CAN-hacker-а? При этом наши переходники - не отваливаются... Почему не предусмотрен TX-FIFO сообщений? Отправляю 3-5 посылок друг за другом без интервала - на CAN-е вижу только одну (первую)... На сайте никаких новых прошивок нету - по крайней мере, я не нашел. Напишите серийный номер устройства. Посмотрю. Делали и делаем различные версии. Возможно недочет в ПО. Если честно,режим ASCII ( который понимает CAN hacker) считали дополнительным, и при смене версий могли не все проверить. Пишите в поддержку, Разберемся. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 190 8 октября, 2021 Опубликовано 8 октября, 2021 · Жалоба Только что, Седой сказал: Напишите серийный номер устройства. Посмотрю. Скажу сразу - я не покупал его лично, на этой работе он достался мне по наследству. На задней крышке надпись SL-USB-30.122 #3. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 8 октября, 2021 Опубликовано 8 октября, 2021 · Жалоба 19 minutes ago, Arlleex said: Скажу сразу - я не покупал его лично, на этой работе он достался мне по наследству. На задней крышке надпись SL-USB-30.122 #3. Данное изделие выпускается в двух версиях. Посмотрите серийный номер в программе SlCanView. Но лучше перейти на общение по эл.почте. Здесь это не по теме. Жду письмо на [email protected] Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 8 октября, 2021 Опубликовано 8 октября, 2021 · Жалоба 07.10.2021 в 13:13, KnightIgor сказал: Узнаваемый стиль @jcxz: в ответе надо сначало обос...ать спрашивающего, а потом можно и по существу. Может не будем переходить на личности, а? Лучше подумайте о своём стиле: если что-то не устраивает во мнении оппонента - сразу переходите на личности. Я вроде про вас лично ничего не говорил. Я говорил о распространённом стиле работы многих: Вместо чтения документации, изучения и использования решений, специально заточенных под данную задачу (потому что лень), начинать быдлокодить сразу. Будь то работа с чем-то в винде, без изучения WinAPI; или ногодрыг в МК, без изучения периферии. И могу ещё раз повторить своё мнение об этом. 07.10.2021 в 13:13, KnightIgor сказал: Я пишу под lazarus и пользую LazSerial компоненту, которая и обращается к WinAPI и ставит все эти SetCommTimeouts() и подобное. Ожидание событий там происходит в отдельном thread с синхронизацией к основному потоку. Написать свою работу. На WinAPI. Без сторонних прослоек, в которых вполне возможны баги. В том числе и с обработкой таймаутов. Пока этого не будет сделано, однозначно утверждть что "это невозможно реализовать в принципе из-за ограничений оборудования" - нельзя, так как вполне возможно что кривая работа - следствие багов в прослойке. И конечно (если нужно точное соблюдение времянок) очень желательно не использовать USB-CDC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 9 октября, 2021 Опубликовано 9 октября, 2021 (изменено) · Жалоба 22 hours ago, jcxz said: Может не будем переходить на личности, а? Лучше подумайте о своём стиле: если что-то не устраивает во мнении оппонента - сразу переходите на личности. Я вроде про вас лично ничего не говорил. Цитирую Ваше высказывание, которое Вы как-бы забыли "Возможности WinAPI изучили? Про SetCommTimeouts() читали? Раз пишете, о каких-то миллисекундах, отслеживаемых на уровне приложения, значит делаем вывод, что не читали. " Вы обращаетесь лично ко мне. Мы тут все понимаем между строк, и кому все иголки адресованы, и попытка пройти под радаром очевидна. Изменено 9 октября, 2021 пользователем KnightIgor Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 19 октября, 2021 Опубликовано 19 октября, 2021 · Жалоба On 10/8/2021 at 11:16 AM, Седой said: Делаем такие. Есть версии с прошивкой, поддерживающей modbus аппаратно, с настройкой параметров, в том числе и временных. Пишите, отвечу на вопросы. http://labsk.ru/products/interfaces/rs485/default.aspx Написал в личку, но ответов пока нет. Пробую здесь напомнить. Мои извинения другим читающим. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
