[tonyk_av 36]

28 minutes ago, jcxz said:

Для вас это будет выглядеть как Modbus-кадры в обрамлении некоего "мусора". Или куски таких кадров.

Сеть Модбас. Там нет других протоколов.

 

29 minutes ago, jcxz said:

Вы же сделали некое поделие, не обладающее кодонезависимостью.

Мы сделали то, что работает на уже существующем оборудовании. Не мы его проектировали. Оно уже было и не работало.

31 minutes ago, jcxz said:

заинтересованного доказать, что ваш девайс не работает (не соответствует спецификации).

Какой спецификации он не соответствует? Не учитывает тайминги? Ну и что, главное- правильно распознаёт кадры.

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

33 minutes ago, jcxz said:

Просто подумайте немного... А вам просто повезло.

Подумали, и не много, а много.

Есть понятие референсного дизайна. Следуя этому дизайну, вы всегда получите гарантированный создателем дизайна рабочий результат. А есть мёртвая система, сделанная без учёта стандартов, которая не способна работать в соответствии с референсным дизайном. Поэтому для таких случаев приходится искать не стандартный способ реализации, успех которого полностью зависит от того, кто его делает. Мы ведь не сдуру брались за такое, поэтому тут не везение, а результат применения имеющихся знаний и опыта.

[razrab83 21]

В 09.06.2024 в 22:08, tonyk_av сказал:

Соответствие спецификации означает, в первую очередь

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

В соответствии со спецификацией, если в пакете  между символами пауза  >1,5, то этот пакет считается битый и не обрабатывается. Вы своим "утром пол пакета, к обеду остальное" этому не сможете соответствовать.  

В 09.06.2024 в 22:08, tonyk_av сказал:

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

если в сети послать 2 пакета, без интервала между пакетами, то все девайсы в сети примут эти пакеты как 1 пакет и забракуют по CRC, а ваш девайс на ПК примет их оба и оба обработает. 

Изменено 13 июня пользователем razrab83

[tonyk_av 36]

1 hour ago, razrab83 said:

если в сети послать 2 пакета, без интервала между пакетами, то все девайсы в сети примут эти пакеты как 1 пакет и забракуют по CRC, а ваш девайс на ПК примет их оба и оба обработает. 

Теперь осталось придумать, кто пошлёт два слипшихся пакета при условии, что нестандартной обработкой фреймов занимается мастер. Два слипшихся фрейма приходить от слэйва не должны, а коли пришли, то будут отброшены. Мастер сети представляет собой шлюз, одним портом подключенный к сети со стандартной обработкой фреймов, а другим портом к сети, в которой происходит разрыв пакетов. Распознавание пакетов включает в себя сопоставление длины Модбас-запроса с длиной полученной порции данных, поэтому два слипшихся запроса будут отброшены.

Кстати, для ОРС-серверов протокола Modbus/TCP встречал настройку допустимости обработки нескольких Модбас-фреймов, отправляемых и,или пришедших в одном TCP-фрейме.

 

[razrab83 21]

3 минуты назад, tonyk_av сказал:

Теперь осталось придумать, кто пошлёт два слипшихся пакета при условии

придумывать ни чего не нужно. я писал 

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

в отдельно взятом случае

в вашем отдельно взятом случае вместо ножки стула стопка книг, прослужит 100 лет. Но это не значит, что ваша стопка книг соответствует мебельному стандарту будет работать вместо ножки при любом использовании стула по назначению. И на протяжении всего диалога вы слово "костыль" заменяете на "нестандартное решение". Появился на электрониксе новояз. Ну хорошо, видите в постах  jcxz слово "кривой костыль"? Читайте - "нестандартное решение". Сути не меняет.

 

12 минут назад, tonyk_av сказал:

Кстати, для ОРС-серверов протокола Modbus/TCP встречал настройку допустимости обработки нескольких Модбас-фреймов, отправляемых и,или пришедших в одном TCP-фрейме.

В TCP, в отличии от UDP, нет фреймов. В TCP есть сегменты, но в API, как правило, они скрыты за сокетом TCP. Сокет TCP выдаст доступное кол-во байтов, в котором может быть 1 пакет Modbus, может быть 2 пакета, может быть 7.3 пакета или полпакета.

Отправляя по Modbus/TCP длинной в 200 байт, этот TCP пакет перемещаясь в инете, может быть фрагментирован и ваш ОРС может получить этот  Modbus/TCP-пакет тремя сегментами TCP: сначала 100 байт, потом 18 байт и потом оставшиеся 82 байта. 

[jcxz 209]

В 09.06.2024 в 20:08, tonyk_av сказал:

Какой спецификации он не соответствует? Не учитывает тайминги? Ну и что, главное- правильно распознаёт кадры.

Этот вам так кажется. Пока не пришёл умный человек, знающий что такое Modbus, и не завалил ваш девайс, посылкой ему корректных Modbus-кадров, которые ваш девайс не в состоянии правильно распознать. Или отправкой мусора, который ваш девайс распознает как корректные кадры.

И при желании такой человек всегда найдётся. Всё зависит от суммы гонорара.

Скажем придёт ко мне завтра заказчик, принесёт ваш прибор, и скажет: "Вот тебе 10тыс.евро, напиши такой код на любом устройстве, который будет посылать кадры, корректные с точки зрения Modbus-протокола, но которые этот прибор будет неверно распознавать". И я напишу.  Зная баги вашей реализации - запросто.

И где же ваш девайс "правильно распознаёт кадры", если сами же выше писали, что распознаёт неправильно:

В 07.06.2024 в 19:29, tonyk_av сказал:

Чё-как там было настроено- ХЗ, но пакеты прилетали рваные, причём одна половина могла прийти утром, а вторая ближе к обеду.

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

 

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

Кстати, для ОРС-серверов протокола Modbus/TCP встречал настройку допустимости обработки нескольких Модбас-фреймов, отправляемых и,или пришедших в одном TCP-фрейме.

В TCP нет фреймов. Советую почитать учебник "что такое TCP". TCP-это потоковый протокол (поток байт). Если кто-то пишет работы с TCP с опорой на некие "фреймы", то это уже изначально некорретная реализация. И чья-то кривая реализация - это не оправдание другим делать так же.

[tonyk_av 36]

53 minutes ago, razrab83 said:

придумывать ни чего не нужно. я писал

Откуда в сети Modbus/RTU, в которой все устройства работают строго по стандарту, возьмутся два слипшихся пакета?

56 minutes ago, razrab83 said:

в вашем отдельно взятом случае вместо ножки стула стопка книг, прослужит 100 лет

Ещё раз. Кривая сеть уже была создана, в неё включено стандартное оборудование, но стандарты в цепочке передачи данных между сетями оказались разные и не совместимые друг с другом, поэтому ничего стандартным образом в ней не могло работать изначально. По этой причине под стул с тремя ножками подложили стопку книг. С инженерной точки зрения реализовано нормальное решение, с точки зрения АСУ- это костыль.

Если вам на улице будут делать подсечку, то вы не будете рассуждать о законности этого деяния, а будете делать всё, чтобы остаться на ногах. Так и здесь есть утверждённый проект, установлена куча оборудования, которое не работает. Что делать?

[tonyk_av 36]

3 minutes ago, jcxz said:

Пока не пришёл умный человек, знающий что такое Modbus

Не нашлось такого, хотя многие пытались.

4 minutes ago, jcxz said:

и не завалил ваш девайс, посылкой ему корректных Modbus-кадров, которые ваш девайс не в состоянии правильно распознать. Или отправкой мусора, который ваш девайс распознает как корректные кадры.

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

6 minutes ago, jcxz said:

если сами же выше писали, что распознаёт неправильно:

Так работает внешняя сеть, из которой пакеты уходят в сеть оборудования.

7 minutes ago, jcxz said:

"Вот тебе 10тыс.евро, напиши такой код на любом устройстве, который будет посылать кадры, корректные с точки зрения Modbus-протокола, но которые этот прибор будет неверно распознавать". И я напишу.  

Не напишите. Всё ПО было уже куплено-написано. Все его тестировали у себя, исходя из требований стандарта, но не зная специфики передачи. Все же соблюдали стандарты.

10 minutes ago, jcxz said:

Зная баги вашей реализации - запросто.

Это не баг.

11 minutes ago, jcxz said:

Т.е. - по стандарту вы должны отбросить такое как мусор. Вы же воспринимаете это как корректный кадр.

По стандарту- да. Ещё раз повторяю, что стандартные Модбас-фреймы между сетями не проходили, поэтому и стандартным образом обрабатывать их было беЗполезно. Нужно было или создавать новые сети, или менять оборудование. И мусор как кадр не воспринимался. Образно говоря, делалась попытка из обрывков собрать целое. Если получалось собрать воедино то, что полностью соответствовало Модбас-фрейму, то он шёл дальше. Если не получалось, то тогда отбрасывалось.

[jcxz 209]

2 минуты назад, tonyk_av сказал:

Откуда в сети Modbus/RTU, в которой все устройства работают строго по стандарту, возьмутся два слипшихся пакета?

Исходная постановка вопроса неверная. Исходно вы почему-то полагаете, что в среде передачи всё идеально. А там может быть не так. В этой среде передачи (например - RS-485) могут присутствовать устройства, работающие криво. Например - выдающие иногда (очень редко и при определённых условиях) какой-то мусор в канал. Например - обрывки Modbus-кадров. Эти баги разработчики устройств не заметили. Да и фиг с ними. Ведь если в этой среде передачи все приёмники имеют корректные парсеры входящих кадров, то они отбросят такое как мусор. Теперь в этот RS-485 втыкают ваше устройство. И оно начинает иногда глючить. Ведь воспринимает тот мусор как корректные кадры.

Дальше начинается разборка - кто виноват? Кому выписывать пи^&*лей?  В этот RS-485 втыкают некий сторонний логгер ModbusRTU кадров, пишущий все кадры в течение нескольких суток непрерывно. Логгер - серьёзный, сертифицирован как "ModbusRTU-compliancy". Потом лог просматривают и... не обнаруживают в нём кадров, адресованных вашему устройству. В то время как ваш девайс действовал, как будто видел такие кадры (так как клеил их из какого-то мусора). Делается вывод о несоответствии вашего девайса ModbusRTU. Занавес. 

А ведь ваши манагеры уже заключили договор на продажу этому заказчику 1 миллиона штук ваших девайсов.   Под это дело вы уже закупили вагон комплектации (в кредит). Но договор расторгается. Так как ваши девайсы "не соответствуют спецификации Modbus-RTU". А ваша контора влетает на бабки.

13 минут назад, tonyk_av сказал:

По стандарту- да. Ещё раз повторяю, что стандартные Модбас-фреймы между сетями не проходили, поэтому и стандартным образом обрабатывать их было беЗполезно. Нужно было или создавать новые сети, или менять оборудование.

Так никто же не против того, чтобы вы реализовали частное решение для данного частного случая, назвав это своим "vendor specific" протоколом. Почему так не сделать??? Но вы же называете его "ModbusRTU", которое им по факту не является.

Назовите его своим проприетарным протоколом, в какой-то мере похожем на ModbusRTU. Никто и слова не скажет. Но вы же вместо этого зовёте его ModbusRTU, вводя всех в заблуждение. Намеренно или по глупости.

[razrab83 21]

33 минуты назад, tonyk_av сказал:

Откуда в сети Modbus/RTU, в которой все устройства работают строго по стандарту, возьмутся два слипшихся пакета?

не в вашей сети, а вообще - в сети Modbus - от куда угодно. ошибкаСлейва/внешняя помеха/слейвДолгоОтвечает/(другой вариант ______) (нужное подчеркнуть)

36 минут назад, tonyk_av сказал:

По этой причине под стул с тремя ножками подложили стопку книг. С инженерной точки зрения реализовано нормальное решение, с точки зрения АСУ- это костыль.

я про тоже самое. "Хьстон, у нас проблемы!...... Как круглый фильтр засунуть в квадратный корпус?.... Скотчем примотать". Гениальное решение, в сложившейся ситуации, спасшее астронавтов. Но это не значит, что надо скотчем всё делать из картониума. Вы под 3-хногую табуретку подложили книги -костыль, возможно ОТЛИЧНОЕ и единственно правильное решение. Но, вы это решение теперь выдаете за "так надо делать. любой модбас в любой системе стерпит, т.к. это соответствует спецификации". Я просто возразил, что это не соответствует спецификации и если в вашем случае это помогло, то в другом может не помочь и даже усугубить. Если делать с чистого листа - то делать нужно по спецификации, а не "книжки подкладывать".  

 

25 минут назад, tonyk_av сказал:

делалась попытка из обрывков собрать целое. Если получалось собрать воедино то, что полностью соответствовало Модбас-фрейму, то он шёл дальше.

вот тут мне не понятно. вернее понятно, но почему то вы тут не оговариваете, что "забили на спецификацию и сделали, как смогли". Т.е. допустим слейв отправил пакет в 10 байт. 4байта + 2тишины + 6байт. Этот пакет изначально битый, т.к. в нём есть пауза >1.5. Теперь через какие-то там ваши терни в ПК получили два куска обрывка. 4 и 6 байт. как из этих обрывков на ПК вы понимаете сколько времени было между 4 и 5-ым байтом при выходе пакета из слейва? Как вы его этот пакет сможете забраковать по тайменгам на ПК?

[jcxz 209]

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

Не нашлось такого, хотя многие пытались.

Видимо - мало денех предлагали. Только и всего.  

 

PS: Вот вам другой сценарий (очень даже жизненный):

Есть некий Производитель девайсов, работающих по ModbusRTU. Предположим это некие счётчики (э/энергии или воды или ещё чего). Допустим есть Заказчик, купивший и установивший на свои объекты кучу этих счётчиков. Счётчики имеют экран, на котором показывают накопленные показания. Но также имеют RS-485 для централизованного запроса данных. Изначально Заказчик (в целях экономии бюджета) решил не делать централизованный съём данных (так как надо прокладывать провода, покупать оборудования для опроса и т.п.). Решил, что ему дешевле нанять бабушек с блокнотиками для периодического обхода. И так работало несколько лет, без нареканий.

Но потом обстоятельства меняются - появляются доп.требования по оперативности контроля или просто бабушки начинают бастовать и требовать повышения ЗП. Заказчик вспоминает, что у купленных им счётчиков есть функция опроса через RS-485 по Modbus. И он, Заказчик, даже её оплатил (в расчёте на будущее). Заказчик подсчитывает экономический эффект и решает уволить всех бабушек, а проложить провода и купить оборудования для опроса по ModbusRTU. Далее - находит ваш девайс, который умеет опрашивать по ModbusRTU сторонние девайсы, и заказывает у вас кучу таких девайсов для опроса своих счётчиков. Монтирует на свои объекты. И... вроде можно пить боржоми и курить бамбук.   А вам - подсчитывать прибыли. Но вот беда - иногда счётчики по неизвестной причине начинают передавать неверные данные. Очень редко. Непредсказуемо. И без видимых причин. Заказчик вызывает Производителя счётчиков. Делает ему втык. Говорит - "или решай проблему или следующего крупного договоря на N лямов $$$ тебе не видать как своих ушей". Т.е. - мотивирует Производителя материально. А у того эти счётчики уже давно находятся в серийном производстве. И разработчики их уже сокращены или на пенсии. Т.е. - искать проблему в огромной куче быдлокода счётчиков - некому.  Да и лень. А договор горит! И Производитель счётчиков *опой чует, что дело в этом самом RS-485 (ведь до этого бабушки несколько лет исправно снимали показания и бед не знали). И возможно он даже знает что проблема в его собственном коде. Только никому не признаётся.

И тут этот Производитель счётчиков узнаёт, что Modbus-то ваш - вовсе и не Modbus!   Далее он просто пишет простейший код, который кроме нормальных кадров, иногда передаёт и такие разорванные кадры (которые ваш девайс воспринимает как нормальные). Этот тестовый девайс передаёт в нормальных кадрах правильные показания (соответствующие тестовым), а в разорванных - неправильные. Вешает на этот RS-485 сторонний сертифицированный логгер (или даже 2). И показывает этот тестовый стенд Заказчику, убеждая его, что проблема вовсе не в его счётчиках (где она реально и есть), а в ваших девайсах. Ведь сертифицированный логгер видит только кадры с правильными показаниями, а ваш девайс принимает иногда неправильные. Доказывает что ваш девайс видит то, чего нет.

Всё - ваш девайс дискредитирован. Договора о поставках с Заказчиком вы лишились. А если бы Modbus у вас был честный, то Производителю счётчиков пришлось бы оторвать пятую точку от стула и найти/исправить баг в своём коде. А не вешать всех собак на вас.

[tonyk_av 36]

4 hours ago, razrab83 said:

Но, вы это решение теперь выдаете за "так надо делать. любой модбас в любой системе стерпит, т.к. это соответствует спецификации"

Врёте. Я не говорил такого, тем более не говорил, что так _надо_ делать. Я говорил, что есть ещё третий способ, которым _можно_ обрабатывать Модбас-фреймы.

4 hours ago, razrab83 said:

Если делать с чистого листа - то делать нужно по спецификации

Это вы проектировщикам говорите, а не мне.

4 hours ago, razrab83 said:

вы тут не оговариваете, что "забили на спецификацию и сделали, как смогли"

Опять врёте. Я не забивал на спецификации, забили проектировщики, которые их, видимо, не знали. Или не знали про ведомственные сети.

Хватит выдумывать то, чего я не говорил.

Я говорил, что наш девайс одним портом подключен к стандартной сети Modbus/RTU, где находятся только слэйвы, поэтому в этом сегменте все Модбас-фреймы обрабатываются строго стандартным образом. Другим портом он подключен с ведомственной радиосети. С другой стороны этой (даже, этих, ибо их там несколько) сети стоит ещё один такой же девайс, который, опять же, одним портом подключен к стандартной сети, а другим к радиосети. И мастер, и слэйвы передают и получают стандартные пакеты со стандартными таймингами. Рваные пакеты циркулируют между этими двумя девайсами-шлюзами. Судя по тому, что разнообразное оборудование от разных производителей опрашивается и управляется как задумывалось, то этот подход приемлем.

razrab83, я рассказал об этом способе с целью показать, что в нестандартных ситуациях могут применяться нестандартные подходы, но я ни разу не_говорил, что для стандартных вещей нужно использовать нестандартные подходы из стремления vыебнуtься. Коли я с такими ситуациями сталкивался уже два раза, то, может, ещё кому-то "повезёт", поэтому такому "счастливчику" может оказаться полезным узнать, что в его случае можно попробовать нестандартный подход.

[Arlleex 153]

Пишу

template<int N>
void func(int (&arr)[N]) {
  ...
}

int main() {
  func({1, 2});
}

Ну, хотел, чтобы можно было вызвать func() с аргументом-списком, который в шаблоне развернулся бы в void func(int (&arr)[2]).

Компилятор пишет, что нет такой функции (не может найти соответствие).

Без std::initializer_list возможно ли такое провернуть?

[juvf 17]

вроде как в C++ нет прямого способа передать список инициализации {1, 2} в функцию,  без std::initializer_list (может ошыбаюсь). Можно использовать перегрузку шаблонной функции или макрос создающий массив

template<int N> 
  void f1(int (&arr)[N]) 
{ 
  for (int i = 0; i < N; ++i) 
  { 
    printf("%d ", arr[i]);
  } 
  std::cout << std::endl; 
} 
// Вспомогательная функция
template<int... Args> 
  void f2(Args... args) 
{  
  int arr[] = { args... }; 
  func(arr); 
} 

int main() 
{ 

  f2(1, 2);   // вызов f2 развернется в вызов f1 с массивом из двух элементов 
  f2(3, 4, 5); // вызов f2 развернется в вызов f1 с массивом из трех элементов 
  
  //можно без прокладки f2, но кто-то должен создать массив, например макрос
  #define F3(...) { int temp[] = { __VA_ARGS__ }; f1(temp); }
  
  F3(1, 2);
  F3(3, 4, 5);
  return 0; 
}

 

[EdgeAligned 73]

А может лучше

void func(int *arr)
{ 
}

  int list[] = {1, 2, 3};
  func(list);

 

[Arlleex 153]

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

вроде как в C++ нет прямого способа передать список инициализации {1, 2} в функцию,  без std::initializer_list (может ошыбаюсь). Можно использовать перегрузку шаблонной функции или макрос создающий массив

Понял, спасибо. Макросами у меня было представление как сделать, а вот на плюсах - не очень.
 

58 минут назад, EdgeAligned сказал:

А может лучше

void func(int *arr)
{ 
}

  int list[] = {1, 2, 3};
  func(list);

Это не то, что я хотел. Я не хочу создавать промежуточный int list[] = {...}.