Расчет CRC на FBD (теория, безумие?)

Итак появилась у меня нетривиальная задача контролировать состояние уставок в Прке. причем не самостоятельно, а квалифицированным персоналом, но не сведущему в контроллерах. ноутбука в руках у них нет и не будет.
мне надо контролировать изменение 32 BOOL, 12-16 INT, 4-8 Float.
по идее мне нужно рассчитать контрольную сумму для этого массива переменных, потом вывести ее в виде ЧИСЛА не более чем в 16 символов (или несколько контрольных сумм суммарной длиной в 16 символов) чтобы уместить в одной строке экрана ПРки.
предполагалось что это число выводится на экран Прки, а если произошло изменение уставок, то по отличию контрольной суммы выдавать предупреждение и требовать призвать наладчиков. (способ ввода исходной суммы и прочих мелочей обсуждать нет смысла).
еще было бы круто чтобы по определенной части контрольной рассчитанного числа можно было понять какой тип данных поврежден ( отдельно bool, int,float)
к сожалению я больше киповец чем программист, потому тут я уже стал в тупик и даже не знаю как подступиться к этой задаче, особенно на ФБД.
прошу тухлыми помидорами не пинать а обсудить возможность такого контроля.

Цитата:

---

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

Итак появилась у меня нетривиальная задача контролировать состояние уставок в Прке. причем не самостоятельно, а квалифицированным персоналом, но не сведущему в контроллерах. ноутбука в руках у них нет и не будет.
мне надо контролировать изменение 32 BOOL, 12-16 INT, 4-8 Float.
по идее мне нужно рассчитать контрольную сумму для этого массива переменных, потом вывести ее в виде ЧИСЛА не более чем в 16 символов (или несколько контрольных сумм суммарной длиной в 16 символов) чтобы уместить в одной строке экрана ПРки.
предполагалось что это число выводится на экран Прки, а если произошло изменение уставок, то по отличию контрольной суммы выдавать предупреждение и требовать призвать наладчиков. (способ ввода исходной суммы и прочих мелочей обсуждать нет смысла).
еще было бы круто чтобы по определенной части контрольной рассчитанного числа можно было понять какой тип данных поврежден ( отдельно bool, int,float)
к сожалению я больше киповец чем программист, потому тут я уже стал в тупик и даже не знаю как подступиться к этой задаче, особенно на ФБД.
прошу тухлыми помидорами не пинать а обсудить возможность такого контроля.

---

То есть уставки редактировать персоналом не предполагается? контроль только от теоретически "самопроизвольных " изменений (неужели так бывает?). Если так, то наверное можно все bool упаковать в int , сравнить с контрольным значением и по результату

Цитата:

---

выдавать предупреждение и требовать призвать наладчиков

---

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

Да, я сталкивался уже пару раз с обнулением энергонезависимых переменных.

Микро предыстория. мне заказчик иногда заказывает типовые шкафы где в ПО есть весь возможный функционал. я собираю и отправляю ему шкафы. прошиваю "рыбу" с условно универсальными настройками и проверяю на перед отправкой, но исходники ПО есть и у заказчика (вдруг я, гад такой, захочу обогатиться и не буду больше прошивать щиты)
просто записать в ПЗУ итоговые уставки на объекте (поправить данные в свойствах макроса) вообще некому. на объект со станком выезжает только технолог. он умеет только тыкать в экран и много уставок и настроек зависят уже от процесса пусконаладки конкретного станка. это мог бы делать я, но я понимаю, что заказчику это не выгодно — привязывать себя к моей персоне. они должны получить итоговое ПО, которое они могут прошить без моего участия (например щиты сами собирать научатся) да и я сам не хочу так действовать. потому и ищу пути решения проблемы за пределами корректировки программы. может, когда ПО будет полностью допилено вообще создать мастер тиражирования и им даже лоджик не будет нужен.

а контрольное число (переписать контрольную из текущей) может любой человек. то есть наладчики все сделали зашли и переписали текущую контрольную сумму в соответствующее поле ввода (это контрольное число) и включили защиту. далее происходит сбой или рассчитанной контрольной суммы или контрольного числа, выдается ошибка станка, пользователи в режиме просмотра видят контрольное число и контрольную сумму. фотографируют и отправляют на завод. те уже вполне могут идентифицировать или это сбой контрольного числа или сбой контрольной суммы, а дальше сами решают что делать или выезжать на объект или продиктовать исходные уставки.
вот и вся логика. если сбой произойдет более глобальный, то это будет «сбой программы лоджика» и по любому надо перепрошивать.

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

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

Цитата:

---

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

Да, я сталкивался уже пару раз с обнулением энергонезависимых переменных.

---

А на каких именно ПР у Вас слетали переменные? У меня к счастью такого на пр200/24в не случалось, но их в эксплуатации всего 2.

Цитата:

---

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

---

Ну так в чем Вы видите сложность этого контроля? BOOL упаковали сравнили один выход, по интам и по флоат еще по сигнальной переменной. Будет всего три BOOL переменных видно будет по каким из них ошибка.

дважды на пр200-220 и один раз (последний) ПР200-24 из общей массы установленных мной Прок это конечно очень маленькое количество сбоев, но факт остается фактом и исключать это нельзя. обе Прки относительно свежие (не старше 2 лет)

да с битовыми переменными тут все просто (вроде бы), а что делать с остальными инт и флоат?
но и даже с битовыми 5 символов для контрольной суммы это перебор. ну максимум 3 желательно

Цитата:

---

а что делать с остальными инт и флоат?

---

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

Откровенно безумие... В ПР данная программа будет выполняться ВСЕГДА, отнимая ресурсы.
Если предположить, что по всем типам переменных никогда нет нуля в нормальном режиме работы, то просто складывать все и если больше 0 то все ок, если ноль, значит стоп программа и вызывай наладчика - переменные слетели. Городить огород с КС будет накладно для цикла ПР.

Цитата:

---

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

Откровенно безумие... В ПР данная программа будет выполняться ВСЕГДА, отнимая ресурсы.
Если предположить, что по всем типам переменных никогда нет нуля в нормальном режиме работы, то просто складывать все и если больше 0 то все ок, если ноль, значит стоп программа и вызывай наладчика - переменные слетели. Городить огород с КС будет накладно для цикла ПР.

---

Так дурной пример заразителен, помните свою программу с подвывертом, надеюсь с ней покончено?!

Сергей0308 вы про журнал аварий? так там только сборка моя, а программа по сути ваша :)

Цитата:

---

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

Сергей0308 вы про журнал аварий? так там только сборка моя, а программа по сути ваша :)

---

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

Цитата:

---

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

Откровенно безумие... В ПР данная программа будет выполняться ВСЕГДА, отнимая ресурсы.
Если предположить, что по всем типам переменных никогда нет нуля в нормальном режиме работы, то просто складывать все и если больше 0 то все ок, если ноль, значит стоп программа и вызывай наладчика - переменные слетели. Городить огород с КС будет накладно для цикла ПР.

---

А с чего Вы взяли что в случае сбоя будут нули, и по всем переменным?

Цитата:

---

складывать все и если больше 0 то все ок

---

Чем это кардинально будет отличаться от сравнения с каким-то значением?
Все таки нужно к примеру INT-ы сложить ,затем по окончании настройки записать это значение(из меню настройки например "запись КС" ) и сравнивать с ним текущие значения, здесь важна не сама цифирь, а ее изменение.
По поводу ресурсов , не думаю что их у ТС не хватает ,к тому-же много эта часть программы точно не отнимет. А нужен подобный контроль, или нет ТС принимает.

Сергей0308 там нет лабуды, потому что есть еще дизельный котел а ТН не рассчитан на мощность, когда мороз может быть больше и всегда должен запускаться первым ТН во всех вариантах. З.Ы. пока у меня с этим глухо, денег нет на второй теплообменник. :)

Sergej_ можно и так, отдельно сложить bool, отдельно int и отдельно float, переведенный в int.
Сложение всегда будет быстрее, чем реальный расчет контрольной суммы, вот я о чем. Потому что расчет любой КС предполагает массив данных, чего в ОЛ просто нет, а городить огород с ПЗУ, выполнять сдвиги и т.д. просто нет смысла, ну не рассчитан на такое ОЛ.

Цитата:

---

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

Сергей0308 там нет лабуды, потому что есть еще дизельный котел а ТН не рассчитан на мощность, когда мороз может быть больше и всегда должен запускаться первым ТН во всех вариантах. З.Ы. пока у меня с этим глухо, денег нет на второй теплообменник. :)

Sergej_ можно и так, отдельно сложить bool, отдельно int и отдельно float, переведенный в int.
Сложение всегда будет быстрее, чем реальный расчет контрольной суммы, вот я о чем. Потому что расчет любой КС предполагает массив данных, чего в ОЛ просто нет, а городить огород с ПЗУ, выполнять сдвиги и т.д. просто нет смысла, ну не рассчитан на такое ОЛ.

---

Мелкий, так в чём проблема, запускайте его первым?!
Я, например, неоднократно выкладывал проект ПР200 для водозаборного узла, там подобная приоритетность, имеется основной и дополнительный насос, если один(основной) не справляется включается на подмогу второй(дополнительный), кроме того раз в неделю основной насос меняется по кругу(1-2-3-1 и т. д.), следующий за основным является дополнительным, если происходит авария любого из насосов, его заменяет насос находящийся в резерве(следующий за дополнительным), всего три насоса. Это ещё не вся программа, короче, мне кажется Вам хватит этого с избытком(придётся урезать раз в 10), а какое название регулируемого параметра - дело второе, что там блуждать в трёх соснах?
Вот этот проект: Вложение 56965

Цитата:

---

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

Сергей0308
Sergej_ можно и так, отдельно сложить bool, отдельно int и отдельно float, переведенный в int.
Сложение всегда будет быстрее, чем реальный расчет контрольной суммы, вот я о чем. Потому что расчет любой КС предполагает массив данных, чего в ОЛ просто нет, а городить огород с ПЗУ, выполнять сдвиги и т.д. просто нет смысла, ну не рассчитан на такое ОЛ.

---

Примерно так я и предлагал, разве что bool просто упаковать в int и получить КС. Массивом он назвал наверное имея ввиду не настоящий массив, а группы переменных различного типа, это-ж понятно. А расчет CRC по всем правилам в данном случае не нужен, как и ПЗУ.

Сергей0308 проблема не в запуске первым, а в определении справляется или нет. То есть достаточно будет его мощности нагреть систему с комнатной Т воды для поддержания температуры в доме за N времени или будет недостаточно и надо отработать либо ровное количество времени и запустить в догрев дизель или он справится сам за N+1 времени.
Пока выбрал вариант сделать таблицу уличных температур и разбивку на время работы до запуска дизеля. Думаю это оптимальный вариант, чем вычислять справится или не справится.
Там же еще и ГВС блин есть, с которым аналогично надо поступать... В общем время придет, займусь...

Цитата:

---

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

Сергей0308 проблема не в запуске первым, а в определении справляется или нет. То есть достаточно будет его мощности нагреть систему с комнатной Т воды для поддержания температуры в доме за N времени или будет недостаточно и надо отработать либо ровное количество времени и запустить в догрев дизель или он справится сам за N+1 времени.
Пока выбрал вариант сделать таблицу уличных температур и разбивку на время работы до запуска дизеля. Думаю это оптимальный вариант, чем вычислять справится или не справится.
Там же еще и ГВС блин есть, с которым аналогично надо поступать... В общем время придет, займусь...

---

Не запустив ТН, трудно понять(как я понимаю нагрузка может меняться) справится он или нет, поэтому запускаете его первым и смотрите по температуре в помещении(насколько понял, что регулируется) как за последние полчаса-час меняется температура, если рассогласование с уставкой уменьшается - значит справляется, если увеличивается - не справляется Конечно лучше переключать с задержкой, можно даже сравнивать среднюю температуру за час и за полчаса методом скользящего окна! Короче, глаза разбегаются от количества возможных вариантов, можно из трёх-пяти вариантов выбрать лучший, какой Вам понравится, всё!

Цитата:

---

Сообщение от Сергей0308

Не запустив ТН, трудно понять(как я понимаю нагрузка может меняться) справится он или нет, поэтому запускаете его первым и смотрите по температуре в помещении(насколько понял, что регулируется) как за последние полчаса-час меняется температура, если рассогласование с уставкой уменьшается - значит справляется, если увеличивается - не справляется Конечно лучше переключать с задержкой, можно даже сравнивать среднюю температуру за час и за полчаса методом скользящего окна! Короче, глаза разбегаются от количества возможных вариантов, можно из трёх-пяти вариантов выбрать лучший, какой Вам понравится, всё!

---

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

Sergej_ нет, с уличным не прокатило, пытался но только время зря потерял. Влажность убивает все, даже при + на улице. Делать самодельный ТН на обычных сплитах для режима воздух-вода не вариант вообще.

Цитата:

---

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

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

---

Если надо учитывать, то кто же мешает это сделать, можно учитывать любую тонкость, типа день-ночь или рабочие-выходные дни!
Разумеется, сначала надо узнать все особенности работы ТН, я с такой штукой впервые столкнулся, точнее даже не я, а Мелкий!

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

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

Цитата:

---

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

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

---

Во всех энергонезависимых переменных?
Если все в "0" сбрасываются, то создаёте энергонезависимую булеву переменную с "1" по умолчанию, при сбросе в "0" - вот Вам и весь механизм определения сбоя!

Цитата:

---

Сообщение от Сергей0308

Во всех энергонезависимых переменных?
Если все в "0" сбрасываются, то создаёте энергонезависимую булеву переменную с "1" по умолчанию, при сбросе в "0" - вот Вам и весь механизм определения сбоя!

---

Э неее.. сбрасываются не все переменные. У меня только одна сбрасывалась. Причем в одном проекте порядка 40 энергонезависимых, а в последнем меньше -5,6 все остальные целехоньки. Я реально до последнего случая думал, что это Клауд глючил и самопроизвольно в одну переменную отправлял ноль.

Цитата:

---

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

Э неее.. сбрасываются не все переменные. У меня только одна сбрасывалась. Причем в одном проекте порядка 40 энергонезависимых, а в последнем меньше -5,6 все остальные целехоньки. Я реально до последнего случая думал, что это Клауд глючил и самопроизвольно в одну переменную отправлял ноль.

---

Из этого следует что просто сравнивать с нулем не вариант, нужно сравнивать с записанной КС , но в этом случае записанная КС храниться тоже в энергонезависимой переменной и она тоже может слететь, в сл-е если все переменные слетят в 0, то сигнала о аварии не увидим.
Поэтому нужно записанную КС тоже дополнительно сравнивать с 0 . Тогда все должно быть окейно при любом раскладе.

Энергонезависимые переменные у нас используются для хранения настроек(уставок и т. д.), то есть их можно менять, у Вас получится их нельзя менять, иначе они перестанут совпадать с контрольным словом, короче, получается просто так мы их изменить не сможем, тогда зачем они нужны в принципе, сразу надо писать в ПЗУ и перезаливать программу ПР, тогда и проблема исчезнет сама собой, так зачем создавать проблему, чтобы её потом решать? Не помню кто сказал: цель - ничто, движение - всё!

И, странно, что только у Вас такая проблема встречается, у меня такого нет и от других подобного не слышал, что бы одна переменная сбрасывалась(боюсь что-то в программе не так сделано)! Если произойдёт сбой памяти, что у многих встречалось, когда программу нужно будет перезаливать, значит они могут залить программу, а в этом случае не могут залить программу, Вы же можете сами изменить значение уставок в ПЗУ и выслать им программу с новыми уставками, какие они захотят!

в программе нЕчего испортить одна точка чтения из энергонезависимой переменной. до этого я писал что думал о многом. но тут никаких ухищрений. но и у меня это всего 3 случая на 50 реле за 4 года. но факт остается фактом.
Я еще раз объясняю! некому при ПНР заполнять константы в программе! было бы это возможно так бы и делали! и я бы не заморачивался.

о чем только в теме не поговорили, но об реализации даже не обмолвились. Чтоб рассчитать контрольную сумму необходим проход в цикле побитно по каждой переменной, в ОЛ же нет циклов. Даже простой XOR целочисленных, как самая простая контрольная сумма, это приличный набор элементов, помимо самих исключающих ИЛИ еще и преобразования всех параметров в целочисленные, и не факт что КС не будут совпадать при различных значениях параметров

Цитата:

---

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

в программе нЕчего испортить одна точка чтения из энергонезависимой переменной. до этого я писал что думал о многом. но тут никаких ухищрений. но и у меня это всего 3 случая на 50 реле за 4 года. но факт остается фактом.
Я еще раз объясняю! некому при ПНР заполнять константы в программе! было бы это возможно так бы и делали! и я бы не заморачивался.

---

Ещё раз повторю: кто будет перезаливать программу если произойдёт сбой памяти и без перезаливки программы никак не обойтись(такое бывало у многих)?

Вложение 56981

Сергей0308 у меня слетали все переменные в ноль. Якобы вылечилось обновлением ОЛ, но так как ОЛ то чинят, то ломают, то уже ничему не удивляюсь.

Цитата:

---

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

Сергей0308 у меня слетали все переменные в ноль. Якобы вылечилось обновлением ОЛ, но так как ОЛ то чинят, то ломают, то уже ничему не удивляюсь.

---

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

Цитата:

---

Сообщение от Сергей0308

Ещё раз повторю: кто будет перезаливать программу если произойдёт сбой памяти и без перезаливки программы никак не обойтись(такое бывало у многих)?
Вложение 56981

---

заводчане приедут на завод за деньги и перезальют мастером тиражирования и перенастроят.
Про все переменные я читал. но у меня несколько раз сбоила именно одиночная переменная! и я несколько раз об этом тоже писал. во всех моих случаях у меня обнулялась только одна единственная переменная.

Цитата:

---

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

заводчане приедут на завод за деньги и перезальют мастером тиражирования и перенастроят.
Про все переменные я читал. но у меня несколько раз сбоила именно одиночная переменная! и я несколько раз об этом тоже писал. во всех моих случаях у меня обнулялась только одна единственная переменная.

---

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

Сергей0308 ну я не проверял, насколько все, те, что увидел были в нулях, при чем насколько помню, я просто вводил их и перезапускал ПР и работало дальше.

Вполне оптимальное решение, ввод переменных через сервисный экран. И типа Акта значений после ПНР. Который еще разработчику направить и еще кому-то экземпляр. Ну и на дверь шкафа ПРИКЛЕИТЬ :)

Цитата:

---

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

Сергей0308 ну я не проверял, насколько все, те, что увидел были в нулях, при чем насколько помню, я просто вводил их и перезапускал ПР и работало дальше.

---

Это же хорошо, не надо программу перезаливать, просто присвоить значения переменным из ПЗУ, если это какие то уставки или настройки, как у нас в данной теме!

Цитата:

---

Сообщение от Сергей0308

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

---

я бы с радостью, но:
1. я не хочу, поскольку мне за это не плотють.
2. они не хотят, поскольку это привязывает их ко мне как к программисту
3. я просто рассматривал универсальное решение задачи.

Цитата:

---

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

я бы с радостью, но:
1. я не хочу, поскольку мне за это не плотють.
2. они не хотят, поскольку это привязывает их ко мне как к программисту
3. я просто рассматривал универсальное решение задачи.

---

Универсальное - тоже понятие растяжимое, я считаю более универсальное это когда используются значения из энергонезависимой памяти, их можно изменять и настраивать, но по сигналу сбой памяти(мы обсуждали как его лучше сформировать) или вручную переключаться на значения из ПЗУ!
В таком случае, можно не спешить перезаливать программу с обновлёнными данными в ПЗУ, важно успеть это сделать до сбоя памяти!

Цитата:

---

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

о чем только в теме не поговорили, но об реализации даже не обмолвились. Чтоб рассчитать контрольную сумму необходим проход в цикле побитно по каждой переменной, в ОЛ же нет циклов. Даже простой XOR целочисленных, как самая простая контрольная сумма, это приличный набор элементов, помимо самих исключающих ИЛИ еще и преобразования всех параметров в целочисленные, и не факт что КС не будут совпадать при различных значениях параметров

---

Здесь речь идет не о побитовой передачи данных и контроле их целостности при этом, поэтому нет никакого смысла рассчитывать ее как это принято в различных протоколах передачи данных. Достаточно отследить просто изменение арифметической суммы ( для интов например) .Для bool переменных Сравнить int полученный из упакованных bool переменных с записанным контрольным.

Цитата:

---

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

Достаточно отследить просто изменение арифметической суммы ( для интов например)

---

ну по элементам ни разу не меньше будет. А вот выйти за диапазон ИНТ-а можно легко, если параметров будет не один два, а XOR позволяет оставаться в одном типе данных

Цитата:

---

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

ну по элементам ни разу не меньше будет. А вот выйти за диапазон ИНТ-а можно легко, если параметров будет не один два, а XOR позволяет оставаться в одном типе данных

---

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