Я говорю это из лично практики. я же выше писал, что в 3 случаях было одно и то же - в переменной оказывались нули. больше никогда никаких других сбоев не ловил.
Я говорю это из лично практики. я же выше писал, что в 3 случаях было одно и то же - в переменной оказывались нули. больше никогда никаких других сбоев не ловил.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Э неее.. сбрасываются не все переменные. У меня только одна сбрасывалась. Причем в одном проекте порядка 40 энергонезависимых, а в последнем меньше -5,6 все остальные целехоньки. Я реально до последнего случая думал, что это Клауд глючил и самопроизвольно в одну переменную отправлял ноль.
Из этого следует что просто сравнивать с нулем не вариант, нужно сравнивать с записанной КС , но в этом случае записанная КС храниться тоже в энергонезависимой переменной и она тоже может слететь, в сл-е если все переменные слетят в 0, то сигнала о аварии не увидим.
Поэтому нужно записанную КС тоже дополнительно сравнивать с 0 . Тогда все должно быть окейно при любом раскладе.
Энергонезависимые переменные у нас используются для хранения настроек(уставок и т. д.), то есть их можно менять, у Вас получится их нельзя менять, иначе они перестанут совпадать с контрольным словом, короче, получается просто так мы их изменить не сможем, тогда зачем они нужны в принципе, сразу надо писать в ПЗУ и перезаливать программу ПР, тогда и проблема исчезнет сама собой, так зачем создавать проблему, чтобы её потом решать? Не помню кто сказал: цель - ничто, движение - всё!
И, странно, что только у Вас такая проблема встречается, у меня такого нет и от других подобного не слышал, что бы одна переменная сбрасывалась(боюсь что-то в программе не так сделано)! Если произойдёт сбой памяти, что у многих встречалось, когда программу нужно будет перезаливать, значит они могут залить программу, а в этом случае не могут залить программу, Вы же можете сами изменить значение уставок в ПЗУ и выслать им программу с новыми уставками, какие они захотят!
Последний раз редактировалось Сергей0308; 14.09.2021 в 12:22.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
в программе нЕчего испортить одна точка чтения из энергонезависимой переменной. до этого я писал что думал о многом. но тут никаких ухищрений. но и у меня это всего 3 случая на 50 реле за 4 года. но факт остается фактом.
Я еще раз объясняю! некому при ПНР заполнять константы в программе! было бы это возможно так бы и делали! и я бы не заморачивался.
о чем только в теме не поговорили, но об реализации даже не обмолвились. Чтоб рассчитать контрольную сумму необходим проход в цикле побитно по каждой переменной, в ОЛ же нет циклов. Даже простой XOR целочисленных, как самая простая контрольная сумма, это приличный набор элементов, помимо самих исключающих ИЛИ еще и преобразования всех параметров в целочисленные, и не факт что КС не будут совпадать при различных значениях параметров
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Ещё раз повторю: кто будет перезаливать программу если произойдёт сбой памяти и без перезаливки программы никак не обойтись(такое бывало у многих)?
IMG_20170314_141356[1].jpg
Последний раз редактировалось Сергей0308; 14.09.2021 в 14:35.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Сергей0308 у меня слетали все переменные в ноль. Якобы вылечилось обновлением ОЛ, но так как ОЛ то чинят, то ломают, то уже ничему не удивляюсь.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.