Подскажите, если кто знает, как сделать счётчик с нарастающим итогом? В программе есть контрольный блок связи, который выдаёт количество не отвеченных запросов по Modbus от конкретного устройства. После того как устройство хоть раз ответило, счётчик обнуляется, а надо чтоб не обнулялся. Блок называется Slave (Link), сам он так делать не умеет, а просто выдаёт количество зафиксированных подряд ошибок связи. Вот как их можно суммировать за всё время работы устройства с момента включения питания?

За 10лет или 100лет, или 1000.., или...? Глупости морозите..

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

if (cnt1_pre != cnt1)
{
if (cnt1_pre < cnt1)
cnt2 += cnt1 - cnt1_pre;
cnt1_pre = cnt1;
}

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




Если слейв единственный на шине, то можно использовать блок Device.link, там нарастающий итог.


Нажмите для просмотра прикрепленного файла

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

Ну вот Ashihara все сделал за Ефремова. Дословный перевод моего примера.

Ashihara, интересен ваш вариант кода на C)

Померяемся как-нибудь в другой раз

Проверил - не работает....

После того как связь восстанавливается всё обнуляется.

Порядок блоков очень важен. Какие левее, какие правее. Иначе да, работать не будет.

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

И ничего там после восстановления связи не обнуляется.

хз

Я проверил, прежде чем выложить. Так что соберите волю в кулак, распечатайте мою схему на листик, листик приложите к монитору и соберите свою схему один-в-один. Будет работать. Обещаю.

Нажмите для просмотра прикрепленного файла

Может что-то не так делаю?...

Естественно не так.

Нажмите для просмотра прикрепленного файла

Так работает.


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

Всё проще. В вашем варианте на входы А и В блока сравнения (СМР_long) приходят одинаковые значения, сравнивать по сути нечего. А у Ashihara на вход А значение в текущем цикле программы, на вход В значение в предыдущем цикле.

Нажмите для просмотра прикрепленного файла

Ещё проще вариант, совсем без компаратора.

Ashihara подсказал направление, спасибо ему огромное, а там уже само как-то получилось. Ну и действительно левее, правее имеет значение, в программе несколько счётчиков, логика по сути одинаковая, а расположение блоков на поле рандомное, работает по разному - одни обнуляются, другие нет. ))

Этот вариант неправильно ошибки считает. Он просто "что-то считает", но не более того.

Да вроде правильно... Прежде чем начинается сложение на вход С приходит 0 и на выходе Q фиксируется значение A+B, так как в самом начале это 0, то Q=0. Далее происходит сложение этого 0 и значения Errors и прежде чем сложение заканчивается на вход С приходит 1, блок пробрасывает значение D равное А+В на выход Q, которое в свою очередь отправляется на вход B, но так как к этому моменту уже Errors=0=A, то получается A+B=B. Далее цикл повторяется, только уже B не 0, а В=А+В в предыдущем цикле.

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

Коллеги, подскажите по случаю. Сколько терминаторов должно быть на линии RS485? В начале и в конце линии или только в конце?

Чем больше - тем лучше.
Если серьезно, читайте первоисточник.
Modbus_over_serial_line_V1_02

Ещё такой вопрос, с чем может быть связано, что без терминатора наблюдается перекос на линии, на А 1,9В, а на В 1,6В? С терминатором выравнивается до 1,8-1,7В...

Спасибо, полезный документ.

Трим5 генерирует в RS485 помеху с интервалом 18мкс и амплитудой 500мВ - с чем это интересно связано? Ну и соответственно если помеха попадает на фронт какого-нибудь бита, то посылка в некоторых случаях портится.

Даже 800 мВ! Ёшкин-матрёшкин.

Как проверяете?

Осцилографом. С подключенными и без устройств на линии результат одинаковый, кроме самих командных запросов каждые 18 мкс на линии образуется помеха амплитудой до 800 мВ. По идее 500 мВ - это уже уровень логической единицы.

Если trim 5 не использовать помехи нет?
Выложите картинку с осциллографа. Одновременно обе линии A и B и чтобы сетки и размерности напряжения видны были.

Я заморочился, интересно было. Всё ок вроде.

Линии А и В, красный - разностный.


Нажмите для просмотра прикрепленного файла

Прекрасные сигналы. Никаких помех не вижу.

Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Что-то у вас всплески на разных пределах разные. На шкале 1В всплеск примерно 0.5В и менее, а на шкале 0.5В всплески 0.8В.

Такого быть не должно. Осциллограф точно у вас в порядке?


PS. В питание контроллера воткнитесь, там всё чисто?

PPS. Между чем и чем вы меряете? Я смотрел относительно gnd порта. Щас глянул между каналами, тоже всё ок.

Нажмите для просмотра прикрепленного файла

Крайне маловероятно что такие помехи происходили по вине программы. Были бы лишние "0" или "1", но не такие всплески. Смотрите питание, осциллограф, что еще подключено к линии RS-485.

Как вариант - подгорел драйвер RS-485, что-то мне кажется уже видел подобные всплески из ниоткуда, замените его.

Это естественно не программные помехи и как они влияют или не влияют трудно сказать, но они никуда не деваются если даже отключить от контроллера всю линию и запитать его от АКБ.

Измеряем относительно GND.

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

А зачем Вам это?
Глупый вроде бы вопрос?
Но в нем есть ответ....

Если Вы делаете универсальное устройство то .....
Приемо/передатчики RS-485 они ведь разные бывают...
Half Duplex и Full Duplex
Если будут Half Duplex ....
смотрите время переключения Rx\TX
и там совсем не наносекунды..

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

время молчания между запросами 3.5 байта минимум на этой скорости. Иначе конец посылки не определишь. До 1 байта допускаются перерывы в сообщении. Это тебе не хухры-мухры маде ин задрищенск, это модбус))).

Но некоторые мастера иногда грешат, не дожидаются паузы. Видать или CRC считают, или просто подглюкивают))).

Modbus_over_serial_line_V1_02.pdf
Стр.13. Все размусолено. Даже временные диаграммы нарисованы. Просто удивительно таки вопросы слышать.

Ништяк, спасибо.

Попросили протестировать устройство, на скорости 115200 1000мс/100мс на 35000 запросов 35 ошибок, на осцилографе видно, что запрос и ответ практически единое целое, различить можно только по высоте формируемого фронта. Я говорю, что типа так наверное не должно быть, а мне типа всё в порядке, вот я и засумневался.

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