Помогите с упорядочиванием опроса по RS-485

[ailcat]

Сообщение от Arsie

<...>

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

Хотя где-то (был уверен, что здесь - но, видимо, ошибаюсь) уже отвечено, что гораздо правильнее будет сделать направление W(out), нежели предложенный мной вариант
(Но его вы - ни в коем случае делать не будете, потому что даже если W(out) нигде в АВОК/ИТП не использовать - совместимость контроллеров зараз пропадет )

[Arsie]

Сообщение от ailcat

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

Хотя где-то (был уверен, что здесь - но, видимо, ошибаюсь) уже отвечено, что гораздо правильнее будет сделать направление W(out), нежели предложенный мной вариант
(Но его вы - ни в коем случае делать не будете, потому что даже если W(out) нигде в АВОК/ИТП не использовать - совместимость контроллеров зараз пропадет )

Во дворе стоит забор, на заборе мочало - начинаем сначала (с)

Я же вроде разжевал вам всё. Но сейчас у меня полное ощущение, что все мои объяснения ушли просто вникуда. Во вселенскую пустоту.

Поэтому на этот раз я отвечу просто и без объяснений: вы не правы в своих размышлениях. Почему? Вспоминайте, это было всего лишь вчера.

[ailcat]

Сообщение от Arsie

Я же вроде разжевал вам всё. Но сейчас у меня полное ощущение, что все мои объяснения ушли просто вникуда. Во вселенскую пустоту. <...> вы не правы в своих размышлениях. Почему? Вспоминайте, это было всего лишь вчера.

Окей, поехали:
1) я предожил вариант (обманка через "отрицательные значения", чтобы не вычитывать свежезаписанный регистр слейва) - но согласился с вашими аргументами: грубо и некрасиво. Засим - "вычеркиваем" обманку.
2) вами было упомянуто, что уже давно думали о направлении "W(out)" (установка coil без последующего вычитывания их состояния), но это нельзя реализовать на пикселях и 2010.
3) я предложил реализовать W(out) только для 2G и 2Gi
4) вы заявили о том, что тогда пропадет совместимость.
5) я предположил, что обратная совместимость (2G/2Gi --> 2010/Pixel) врядли будет кем-то востребована.
6) вы аргументировали тем, что в создаваемых "конструкторами" программах - вариант "запись без чтения" не используется, т.к. в штатных ситуациях всё равно надо сразу проверять, "прошла" ли запись (а еще нашелся человек, который совместимостью пользуется). Хорошо, я услышал этот аргумент.
7) далее я предложил напрпавление W(out) всё-таки реализовать для 2G/2Gi, но не использовать в генерируемых Конструкторами программах, чтоб не страдала совместимость.
8) Вдруг я благополучно узнал, что я не прав априори, ибо не услышал объяснений выше и вообще исхожу из неправильных размышлений.
Вопрос: где я начал "начинать сначала", неправильно мыслить, или что там еще неправильного делать?

[Arsie]

Сообщение от ailcat

2) вами было упомянуто, что уже давно думали о направлении "W(out)" (установка coil без последующего вычитывания их состояния), но это нельзя реализовать на пикселях и 2010.
3) я предложил реализовать W(out) только для 2G и 2Gi
4) вы заявили о том, что тогда пропадет совместимость.
7) далее я предложил напрпавление W(out) всё-таки реализовать для 2G/2Gi

И какой вывод из этого всего?

[ailcat]

Варианты, оставленные вами открытыми:
1) вы реализуете эту возможность в следующей версии ядра 2G/2Gi, но не используете W(out) в выдаче конструкторов, чтобы "сохранилась совместимость"...
2) вы не напрягаетесь - и оставляете это ограничение "как есть", ибо из тех, кто мог бы использовать эту "опцию" - шум поднимаю только я...
Пока однозначного ответа не было, хотя вы явно симпатизируете второму варианту...

[Arsie]

Сообщение от ailcat

Варианты, оставленные вами открытыми:
1) вы реализуете эту возможность в следующей версии ядра 2G/2Gi, но не используете W(out) в выдаче конструкторов, чтобы "сохранилась совместимость"...
2) вы не напрягаетесь - и оставляете это ограничение "как есть", ибо из тех, кто мог бы использовать эту "опцию" - шум поднимаю только я...
Пока однозначного ответа не было, хотя вы явно симпатизируете второму варианту...

Душой я уже лет семь-восемь как за первый вариант.

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

[ailcat]

Вопрос:
А что будет при попытке сделать запись по широковещательному адресу?
Ведь при попытке потом вычитать по этому адресу - получится коллизия на шине (или широковещательные запросы блокируются напрочь?)

[Arsie]

Сообщение от ailcat

Вопрос:
А что будет при попытке сделать запись по широковещательному адресу?
Ведь при попытке потом вычитать по этому адресу - получится коллизия на шине (или широковещательные запросы блокируются напрочь?)

Этот вопрос вы задаёте по отношению к чему?

Если к нашим контроллерам, то они не делают разницы между нулевым адресом и остальными.

[ailcat]

Сообщение от Arsie

Этот вопрос вы задаёте по отношению к чему?
Если к нашим контроллерам, то они не делают разницы между нулевым адресом и остальными.

Именно к ним.
Суть в чем: в этом году ОВЕН снимает с производства МДВВ - предлагая заменой габаритные блоки, которые не встают под пластрон щита. Найденная альтернатива (практически единственная) имеет одно нехорошее свойство: она отвечает на широковещательный запрос чтения.
Ранее уже было установлено, что после записи ваш контроллер вычитывает записанные регистры. Соответственно, после записи coil'ов (широковещательным запросом) вычитывание сразу от дюжины "аналогов МДВВ" - явно приведет к коллизии на шине RS485...
Вот и встает вопрос: как эту коллизию воспримут SMH2Gi и Pixel-25??? (да и с железякой непонятно из описания, что будет - но это уже не ваша проблема)

[ATS]

Сообщение от ailcat

Ранее уже было установлено, что после записи ваш контроллер вычитывает записанные регистры. Соответственно, после записи coil'ов (широковещательным запросом) вычитывание сразу от дюжины "аналогов МДВВ" - явно приведет к коллизии на шине RS485...

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

Вот только на кой Вам запись широковещательным запросом?

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

Вот и встает вопрос: как эту коллизию воспримут SMH2Gi и Pixel-25??? (да и с железякой непонятно из описания, что будет - но это уже не ваша проблема)

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

[tvf]

Сообщение от ailcat

Ранее уже было установлено, что после записи ваш контроллер вычитывает записанные регистры. Соответственно, после записи coil'ов (широковещательным запросом) вычитывание сразу от дюжины "аналогов МДВВ" - явно приведет к коллизии на шине RS485...

Вы сами планируете сеть на шине RS485. Не используйте нулевой адрес и ни каких коллизий не будет.
Но можно посмотреть на этот вопрос и с другой стороны. Пусть все слейвы отвечают и их ответы не перекрываются. Ну такие дисциплинированные и сознательные слейвы.
Первый ответит - 5
Второй ответит - 6
Третий ответит - 7
Но согласно стандарту ModBus адрес в ответе слейва должен совпадать с адресом в запросе. И все трое ответят с адресом 0. Пусть и мастер у нас будет умным и понимать, что может быть несколько ответов на запрос. Сначала он запишет в нужный регистр 5, потом 6, потом 7. А если глупый, и действует строго в соответствии с уставом ModBus, то запишет в нужный регистр 5 и на этом остановится. То есть отцом ребенка будет или первый или последний пользовавший женщину. Остальные отцы останутся неизвестными. Так что широковещательные запросы это не к ModBus.

[ailcat]

Сообщение от ATS

Вот только на кой Вам запись широковещательным запросом?

Исключительно для экономии времени.
У меня матричный опрос датчиков (а это - уже экономия проводов и средств). Поочередно включаю выходы и считываю состояние входов.
Если устанавливать выходы поочередно для всех МДВВ - цикл почти 5 секунд (скорость сильно зажата из-за помех на почти 600-метровой линии "кривым зигзагом"). Устанавливая выходы широковещательной командой, а потом вычитывая входы поочередно со всех - с небольшим запасом укладываюсь в нормативные 2 секунды.

Сообщение от tvf

Вы сами планируете сеть на шине RS485. Не используйте нулевой адрес и ни каких коллизий не будет.

Ну, не планирую, а повторяю на другом объекте. Но вынужденно с другим модулем удаленного ввода-вывода (который не умеет молчать в ответ на запрос с адресом 0, хотя и понимает, что команда "для всех").
И мне абсолютно по барабану, что там вычитает пиксель в ответ на широковещательную команду записи выходов ("в дело" я использую последующие индивидуальные команды чтения входов), но и отключить эту ненужную операцию Сегнетикс не позволяет.
Мне важно, чтобы при этом Пиксель и 2Gi не ушли в аварию или подобный "прикол", прекратив опрос или выполнение программы.

[ATS]

Сообщение от ailcat

Исключительно для экономии времени.
У меня матричный опрос датчиков (а это - уже экономия проводов и средств). Поочередно включаю выходы и считываю состояние входов.

Не могу представить Вашу матрицу. Широковещательным можно записать только одинаковую информацию во все слейвы.

вынужденно с другим модулем удаленного ввода-вывода (который не умеет молчать в ответ на запрос с адресом 0, хотя и понимает, что команда "для всех").

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

[ailcat]

Сообщение от ATS

Не могу представить Вашу матрицу. Широковещательным можно записать только одинаковую информацию во все слейвы.

А именно это и требуется.
Сперва во все слейвы пишется %000001. И вычитываются входы с каждого УСО отдельно.
Потом во все слейвы пишется %000010. И вычитываются входы с каждого УСО отдельно.
Затем во все слейвы пишется %000100. И вычитываются входы с каждого УСО отдельно.
И таким образом опрашиваются все 42 сухих контакта (в матрице 6х8).
(УСО разнесены территориально. Каждое УСО - отдельная "установка", сами "установки" подобны).

Просто разница в цене клемм с диодами и без - на порядок меньше разницы в цене между МДВВ (8 выходов и 12 входов, считываемых как регистр) и УСО на 42+ входов. Буджет-то традиционно в 5 раз меньше, чем нужен...

UPD: впрочем, под новый проект можно попробовать продавить и 3 модуля ввода на 16 входов (любопытно, есть ли такие, чтоб все входы можно было вычитать как битовую маску, т.е. в стиле МДВВ? А то M7054 так не умеют, каждый вход отдельной командой читать надо - в нормируемое время опроса не уложусь)...

[Arsie]

Сообщение от ailcat

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

У меня из ваших постов постоянно складывается ощущение, что мы не промконтроллеры производим, а "спектрумы" паяем на коленке и программируем их на бейсике. Я вот даже не вижу никакого смысла отвечать на настолько дикий вопрос. "Мне важно, чтобы купленный у вас камень был каменным"

Теперь о модбасе.

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

В модбасе нет требования поддерживать широковещательные запросы - это отдано на усмотрение производителя.

В модбасе чётко описано, что на один запрос должен следовать один ответ.

Понятное дело, что хотелок много. Те же модули MR работают ровно так, как вы хотите сделать и именно по тем же причинам)) Но к модбасу это имеет ровно такое же отношение, как и мухи к котлетам.

[Gromov]

Сообщение от ailcat

Просто разница в цене клемм с диодами и без - на порядок меньше разницы в цене между МДВВ (8 выходов и 12 входов, считываемых как регистр) и УСО на 42+ входов. Буджет-то традиционно в 5 раз меньше, чем нужен...

UPD: впрочем, под новый проект можно попробовать продавить и 3 модуля ввода на 16 входов (любопытно, есть ли такие, чтоб все входы можно было вычитать как битовую маску, т.е. в стиле МДВВ? А то M7054 так не умеют, каждый вход отдельной командой читать надо - в нормируемое время опроса не уложусь)...

Насколько я понял вашу ситуацию - сейчас вы пытаетесь навести справки, как и что. На деле - вам лучше всего провести чистый эксперимент с требуемым оборудованием. Поскольку, снова догадка, аналог мдвв - noname китай (видел такие), там вообще может быть что угодно в интерфейсе.

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

Я бы использовал "маленький" контроллер на каждой установке, например, пиксель с необходимым числом МРов. Он бы сам занимался вычитыванием своей "матрицы", а в сеть отдавал уже вычисленные и приведённые значения состояния матрицы. Кроме того, такая схема позволит заложить алгоритм потери связи и придать некую автономность. По деньгам тут, вероятно, будет некоторый проигрыш. Но я старался бы убедить заказчика в более высокой надёжности данного решения.

[ailcat]

Сообщение от Arsie

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

Увы, но ваша реализация записи coils по модбасу ДЕЛАЕТ это, хотя мне это даром не упало. Потому что у вас изначально заложена принудительная вычитка того, что записано.
P.S. Что широковещательные запросы - не есть обязательная часть стандарта Modbus RTU - я в курсе. Но если с МДВВ "оно работает", то что будет с этим китайцем - история умалчивает...

А нестандартное использование стандартного оборудования - увы, лепилово из продуктов жизнедеятельности "конфетки" - сродни кроилову. Но кроилово-то "сверху", а попадалово - "снизу"...

[Arsie]

Сообщение от ailcat

Увы, но ваша реализация записи coils по модбасу ДЕЛАЕТ это, хотя мне это даром не упало.

У нас нет поддержки широковещательных запросов. Это пункт номер два из написанных мною.

[ailcat]

Сообщение от Gromov

На деле - вам лучше всего провести чистый эксперимент с требуемым оборудованием. Поскольку, снова догадка, аналог мдвв - noname китай (видел такие), там вообще может быть что угодно в интерфейсе.

Ага, именно китайчатина (из плюсов - отличается только питанием, что не проблема; из минусов - отвечают на запросы по адресу "0", что может оказаться проблемой. Зато их можно использовать для замены сдыхающих МДВВ практически "один-в-один").
А проверить "на натуре" не выходит, т.к. бумаготворчество на закуп образца - проще повеситься.

Сообщение от Gromov

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

Да, вот сейчас наткнулся на WAD-DIO24-ECO-24DI (это "Акон" делает) - в новый проект, пожалуй, заложу прямой ввод с них, без "матрицы"), благо стоят умеренно и продавить начальство, скорее всего, получится.
Они, конечно, несовместимы - но переписать макросы выборки не шибко трудоемко, но они будут попроще и, скорее всего, пошустрее (запас РеалТика до нормируемых 2 сек увеличится, что только в плюс).

Сообщение от Gromov

Я бы использовал "маленький" контроллер на каждой установке, например, пиксель с необходимым числом МРов. <...> Кроме того, такая схема позволит заложить алгоритм потери связи и придать некую автономность. По деньгам тут, вероятно, будет некоторый проигрыш. Но я старался бы убедить заказчика в более высокой надёжности данного решения.

Контроллер там избыточен (это тупо "регистратор"), а вот контроль всех "установок" в единых координатах времени крайне желателен.
Так что для старой системы закупим МДВВ "в запас" (ага, и запакуем в азот ) - авось не погорят до реконструкции системы. А новую попробую изначально построить на Аконах с уходом от матричного опроса...
UPD: "заказчик" - это верхнее руководство ("кроилово" на эксплуатации есть норма), исполнители и эксплуатанты - мы (и "попадалова" совсем не хочется)

[ATS]

Сообщение от ailcat

А именно это и требуется.
Сперва во все слейвы пишется %000001. И вычитываются входы с каждого УСО отдельно.
Потом во все слейвы пишется %000010. И вычитываются входы с каждого УСО отдельно.

Теперь понял - это несколько матриц.

Увы, но ваша реализация записи coils по модбасу ДЕЛАЕТ это, хотя мне это даром не упало. Потому что у вас изначально заложена принудительная вычитка того, что записано.

Это где там широковещательный запрос? Все по адресу слейва.

[ailcat]

Сообщение от ATS

Это где там широковещательный запрос? Все по адресу слейва.

Запись идет по адресу "0". Который МДВВ воспринимает как широковещательный.
Но Segnetics сразу после записи делает запрос на чтение выходов - тоже по адресу "0".

[Arsie]

Сообщение от ailcat

Запись идет по адресу "0". Который МДВВ воспринимает как широковещательный.
Но Segnetics сразу после записи делает запрос на чтение выходов - тоже по адресу "0".

Ну так МДВВ должен его проигнорить и всё.

[ATS]

Сообщение от ailcat

Запись идет по адресу "0". Который МДВВ воспринимает как широковещательный.

Простите, но широковещательный адрес 0 это Ваша хотелка.

[ailcat]

Сообщение от Arsie

Ну так МДВВ должен его проигнорить и всё.

МДВВ и игнорил. Но его снимают с производства, а подобранная замена - игнорить, судя по описанию, не умеет.

[Gromov]

Я совсем запутался...
Вы хотите широковещательные запросы(к адресу 0), чтобы писать одинаковую маску выходов во все модули разом, но мдвв этого не умеет? Или же мдвв игнорировал такие запросы и надо было записывать каждому своё?

[ATS]

Сообщение от Arsie

Ну так МДВВ должен его проигнорить и всё.

Основная масса устройств не делает различий для адреса 0 и своего собственного.

[Arsie]

Сообщение от ATS

Основная масса устройств не делает различий для адреса 0 и своего собственного.

Это я исхожу из слов оппонента, что они поддерживают.

[ATS]

Сообщение от Arsie

Это я исхожу из слов оппонента, что они поддерживают.

Хотя по стандарту:
"No response is returned to broadcast requests sent by the master. The broadcast requests are necessarily writing commands. All
devices must accept the broadcast for writing function. "

[Arsie]

Сообщение от ATS

Хотя по стандарту:
"No response is returned to broadcast requests sent by the master. The broadcast requests are necessarily writing commands. All
devices must accept the broadcast for writing function. "

Написано "При использовании широковещательных запросов все устройства на линии должны их поддерживать".

Всё логично.

[ATS]

Сообщение от Arsie

Написано "При использовании широковещательных запросов все устройства на линии должны их поддерживать".

Всё логично.

Для фунции записи...