[ViKo 1]

1 час назад, Arlleex сказал:

Ага, пришло с интервалом 2t или 2.5t - к кому относить?

Выкидывать. Пока 3.5t не придёт.

 

1 час назад, Arlleex сказал:

в четверти из них они за символ принимают 4-битную тетраду, получая 6 и 14 бит для 1.5t и 3.5t

О, я среди них был. Но расчет времени по приведённому выше абзацу меня переубедил. На данном этапе.   

[haker_fox 60]

2 hours ago, ViKo said:

сколько битов пауза равна в Modbus TCP? 

А если вопрос поставить по-другому: не менее скольки бит должна быть пауза, чтобы приёмник сбросил свой буфер и принял решение, что это была поемеха вместо данных? Не помню откуда картинка. Но Вам не нужно точно отсчитывать 3.5 символа. Вам надо не менее, чтобы считать, что это пауза, и данные больше не придут.

 

[ViKo 1]

6 минут назад, haker_fox сказал:

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

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

Я предпочел бы сделать по стандарту. Но он плохо описан. 

[KnightIgor 2]

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 131]

1 час назад, KnightIgor сказал:

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

Отсюда и далее у меня уже были потуги не то что соблюсти тайминги (этой задачи не стояло как таковой), а принять все что отправил с платы.
Винды и другие не ОСРВ-оси как бы особо не причем, а вот к производителям мостов USB-UART, в силу ограниченного объема буфера, вопросики.

[jcxz 184]

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]

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]

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 131]

10 минут назад, Седой сказал:

Пишите, отвечу на вопросы.

А можно я спрошу?
Почему вот этот адаптер самопроизвольно отваливается от CAN-hacker-а? При этом наши переходники - не отваливаются...
Почему не предусмотрен TX-FIFO сообщений? Отправляю 3-5 посылок друг за другом без интервала - на CAN-е вижу только одну (первую)...
На сайте никаких новых прошивок нету - по крайней мере, я не нашел.

[Седой 0]

7 minutes ago, Arlleex said:

А можно я спрошу?
Почему вот этот адаптер самопроизвольно отваливается от CAN-hacker-а? При этом наши переходники - не отваливаются...
Почему не предусмотрен TX-FIFO сообщений? Отправляю 3-5 посылок друг за другом без интервала - на CAN-е вижу только одну (первую)...
На сайте никаких новых прошивок нету - по крайней мере, я не нашел.

Напишите серийный номер устройства. Посмотрю. Делали и делаем различные версии. Возможно недочет в ПО.

Если честно,режим ASCII ( который понимает CAN hacker) считали дополнительным, и при смене версий могли не все проверить. Пишите в поддержку, Разберемся.

[Arlleex 131]

Только что, Седой сказал:

Напишите серийный номер устройства. Посмотрю.

Скажу сразу - я не покупал его лично, на этой работе он достался мне по наследству. На задней крышке надпись SL-USB-30.122 #3.

[Седой 0]

19 minutes ago, Arlleex said:

Скажу сразу - я не покупал его лично, на этой работе он достался мне по наследству. На задней крышке надпись SL-USB-30.122 #3.

Данное изделие выпускается в двух версиях. Посмотрите серийный номер в программе SlCanView. Но лучше  перейти на общение по эл.почте.

Здесь это не по теме. Жду письмо на [email protected]

 

[jcxz 184]

07.10.2021 в 13:13, KnightIgor сказал:

Узнаваемый стиль @jcxz: в ответе надо сначало обос...ать спрашивающего, а потом можно и по существу.

Может не будем переходить на личности, а?  Лучше подумайте о своём стиле: если что-то не устраивает во мнении оппонента - сразу переходите на личности.

Я вроде про вас лично ничего не говорил. Я говорил о распространённом стиле работы многих: Вместо чтения документации, изучения и использования решений, специально заточенных под данную задачу (потому что лень), начинать быдлокодить сразу. Будь то работа с чем-то в винде, без изучения WinAPI; или ногодрыг в МК, без изучения периферии.

И могу ещё раз повторить своё мнение об этом.

07.10.2021 в 13:13, KnightIgor сказал:

Я пишу под lazarus и пользую LazSerial компоненту, которая и обращается к WinAPI и ставит все эти SetCommTimeouts() и подобное. Ожидание событий там происходит в отдельном thread с синхронизацией к основному потоку.

Написать свою работу. На WinAPI. Без сторонних прослоек, в которых вполне возможны баги. В том числе и с обработкой таймаутов. Пока этого не будет сделано, однозначно утверждть что "это невозможно реализовать в принципе из-за ограничений оборудования" - нельзя, так как вполне возможно что кривая работа - следствие багов в прослойке.

И конечно (если нужно точное соблюдение времянок) очень желательно не использовать USB-CDC.

[KnightIgor 2]

22 hours ago, jcxz said:

Может не будем переходить на личности, а?  Лучше подумайте о своём стиле: если что-то не устраивает во мнении оппонента - сразу переходите на личности.

Я вроде про вас лично ничего не говорил.

Цитирую Ваше высказывание, которое Вы как-бы забыли "Возможности WinAPI изучили? Про SetCommTimeouts() читали? Раз пишете, о каких-то миллисекундах, отслеживаемых на уровне приложения, значит делаем вывод, что не читали. "

Вы обращаетесь лично ко мне.

Мы тут все понимаем между строк, и кому все иголки адресованы, и попытка пройти под радаром очевидна.

Изменено 9 октября, 2021 пользователем KnightIgor

[KnightIgor 2]

On 10/8/2021 at 11:16 AM, Седой said:

Делаем такие.  Есть версии с прошивкой, поддерживающей modbus аппаратно, с настройкой параметров, в том числе и временных. Пишите, отвечу на вопросы.

http://labsk.ru/products/interfaces/rs485/default.aspx

Написал в личку, но ответов пока нет. Пробую здесь напомнить. Мои извинения другим читающим.