Есть один прикол, который разработчики объяснить не могут. По какой-то причине прикопировании и переименовании макроса, даже с изменением его имени и состава при его вставке в проект кричит что такой макрос уже есть. В итоге проще сделать 32 битный вариант и всюду его вставлять
bayk потому что макросы определяются по их ID а не ИМЕНИ. Создайте Новый макрос, сменится ID, скопируйте туда нужное, задав новое имя и так далее.
Вроде этот момент давно разработчики объяснили...
Я вообще к чему. Когда мы лепим 32-х битные макросы, но используем от них только половину или меньше, и когда в проекте таких вариантов много, мы просто засираем память ПР холостыми операциями и количеством FBD... просто не оптимальное решение...
Последний раз редактировалось melky; 02.02.2020 в 10:20.
Ну, Сергей в чем-то прав. Дату и время можно склеить в одну энергонезависимую переменную. Так памяти меньше израсходуется, наверно. Надо проверить. А как в скаду лучше передавать: одной большой переменной ( в скаде ее расшифровывать) или каждой параметр своей переменной?
Так, если Вы в скаду передаёте, тогда архив в ПР и не нужен, максимум буфер из не энергонезависимой памяти, мне так кажется!Сообщение от stanislau
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Не, я сейчас не планирую передавать. Это вообще, чтобы знать как лучше и правильней.
В общем, если склеивать дату и время в одну переменную, то без компромиссов не обойтись. Для нормальной читаемости на экране ПР все таки между гг мм дд чч мм сс должны быть пробелы, хоть между чем-нибудь. С пробелами в инт все не влазит. Придется урезать дату/время до дд мм чч сс. А так, да, меньше байт расходуется. Если все-таки будет скада только для чтения архива из ПР, то,все-таки, как лучше паковать данные? Хотелось бы и на ПР сохранить информативность, и со скадой уменьшить сетевой обмен (наверно чем меньше ПР будет по сети "нагружена", тем лучше?).
Вот прикинем: код аварии(до 64 аварий) - 6 бит, секунды(0-59) - 6 бит, минуты(0-59) - 6 бит, часы(0-23) - 5 бит, число(1-31) - 5 бит, месяц(1-12) - 4 бит, итого 32 бита, если хотя бы раз в год просматривать, то год и не потребуется писать. Если не каждый год просматривать, то можно вместо секунд - год писать, хватит на 64 года, короче, как-то примерно так я это вижу и хотел повторить, что у меня(ранее делал подобные проекты с использованием энергонезависимой памяти) энергонезависимой памяти хватало более чем на 160 аварий(переменных), надеюсь, понятно написал!
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
вам так жалко 3-х регистров на дату и Аварии ? ну вы бдин даете.... а ничего, что вам потом придется выделываться и со стороны Scada системы, преобразуя все обратно ?????? это и есть мне кажется извращение, создать себе дополнительных трудностей, чтобы потом их преодолевать....
и простите, как вы в 6 бит запихнете 16 аварий одновременно? ну если правильнее сказать несколько из 16 аварий в любой из комбинаций ?
Я же только пару часов назад написал, что считаю если в скаду передаётся, то в ПР архив и не нужен от слова совсем максимум буфер из не энергонезависимой памяти!
И если бы Вы удосужились посмотреть мой проект аварий хоть одним глазком, я кстати и писал об этом, там это всё разруливается макросом RAMP_BIT, короче, при возникновении на входе одновременно даже всех 32 аварий, на выходе будет менятся по одной каждый цикл программы, начиная со самого старшего бита и далее по мере уменьшения старшинства(весового коэффициента), процесс изменения займет столько циклов программы сколько бит изменилось, лучше посмотрите для наглядности, можно в симуляторе спокойно посмотреть, проект там присутствует, по ссылке: https://owen.ru/forum/showthread.php?t=31113&page=7
Регистрация аварий_15.owl
Последний раз редактировалось Сергей0308; 03.02.2020 в 00:17.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Сергей0308 RAMP_BIT некрасивое решение, если есть передача в Scada. Цикл ПР куда быстрее, чем опрос и тем более запись в БД Scada системы.
Он больше подходит для работы на экране без всяких Scada. Я же делал универсальное решение, ни вашим ни нашим... Хочешь используй Scada, хочешь не используй. Даже если опрос настроить раз в несколько минут, в регистрах будет зафиксирован последний код Аварии и ее время.
Разложить на биты в Scada не составляет труда, а вот все засунуть в один или два регистра и потом вытаскивать в Scada еще и время это лишний мартышкин труд.
Проще передать двумя регистрами время UTC и третьим регистром код Аварии. А вот для экрана надо будет добавить разложение по битам в самом ПР, если прямо нужна будет такая необходимость. При чем во время работы экрана в сеть так же передается только последняя Авария, чтобы в Scada не попадали данные предыдущих, если оператор смотрит ошибки непосредственно на экране.
Я исходил из того, что вероятность возникновения ДВУХ аварий в ОДНОМ цикле ПР крайне мала, и даже если она есть, Scada это увидит на следующем опросе. Ну а на экране будет код числа из двух битов, что не так уж и страшно....
Последний раз редактировалось melky; 03.02.2020 в 09:45.
Ваши права
Ответить с цитированием