Вход

Просмотр полной версии : сброс данных



Safron
05.11.2010, 10:37
возникла неожиданная проблема . есть задача считать суммарный расход пара котлов (счётчик). попытался реализовать это на плк63. считает. и всё вроде бы ничего вот только сбрасывает показания (обнуляется). причём когда захочет.
с чем это может быть связано?

Николаев Андрей
05.11.2010, 23:07
что значит сбратывается?
как делаете???

Safron
08.11.2010, 10:49
да ни чего не делаем. пришла женщина, открыла шкаф, переписала показания. и так несколько дней подряд. в какой-то момент она обнаруживает, что отсчёт начался заново. и опять день-два нормально -по нарастающей, а потом опять по новой. переполнение на мой взгляд не может быть... хотя я могу и ошибаться...вот собственно и всё.

Safron
18.11.2010, 13:25
Господа разработчики ОВЕН. Посоветуйте что-нибудь. Если надо выбросить ПЛК63 на помойку я его выброшу. 2 года назад мы стали использовать для исзмерения расхода и суммарного учёта расходомер РМ1.
И где бы мы его не устанавливали, везде происходило одно и то же, а именно, сам по себе происходил сброс суммарного учёта. Сначала я грешил, что может быть это партия такая бракованная. Заказал ещё 4 штуки и всё равно тоже самое. Это какая-то болезнь у них.
В общем, я решил от них полностью отказаться и попробовать , в порядке эксперимента, реализовать этот учёт на контроллере ПЛК 63.
Та же самая история. В какой-то момент берёт и сбрасывает сохраняемые данные. Причём пробовал по разному сохранять. И виде ретайн (SUM_3) и в submenu plc configuration (SUM_Q_3). См. прилагаемый файл. Иерархию ФБ я намеренно сохранил, так как у меня в проекте...

У меня есть подозрения, что это Ваша недоработка как в одном так и в друго случае. 8 шт. РМ1 2шт. ПЛК 63 страдают этим недостатком, и это при том, что влияние сетевых помех я уже исключаю.

ПОСОВЕТУЙТЕ ЧТО_НИБУДЬ ДЕЛЬНОЕ...

Филоненко Владислав
18.11.2010, 16:08
Ну, 2 разных прибора, с абсолютно отличающимся железом, совсем разной программой (ни байта разделяемого кода) и демонстрируют постоянство... повод задуматься почему.

По программе ПЛК63:

Что за строчка ST_3:STATISTICS_REAL; STATISTICS_REAL - это что?
И основное. При записи данных в Retain/параметры надо контролировать правильность записываемого.
Например на равенство нулю (интеграл нулю не равен по определению).
И при записи параметров проверять что запись прошла успешно, пользуясь кодами ошибок и последующим чтением.

pt200
18.11.2010, 16:34
....При записи данных в Retain/параметры надо контролировать правильность записываемого....

:eek:
Всю жизь думал что за этим сам плк следит. И если чего не так генерит стоп эксепшн/сбрасывет данные на значения по умолчанию и ставит флаг например.

Safron
19.11.2010, 03:36
насчёт применения кодов ошибок и последующим их чтением...если можно, с этого места по подробнее...библиотека какая-то специальная существует ?

Safron
19.11.2010, 08:11
плк выдаёт ошибку 3. дело в программе...пробую устранить..

Филоненко Владислав
19.11.2010, 11:07
представим, что вы банк. и у вас есть кредитор, которому вы выдаете кредиты.
каждый раз при оплате долга/получения кредита вы, как банк и кредитор заключаете новое соглашение на остаток долга.

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

будете ли вы проверять это утверждение по истории и платёжкам или примете на веру?

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

Safron
22.11.2010, 08:00
владислав. замечание верное. проблема в том , что я пока ума не приложу каким путём осуществлять проверку. просто что ли сравнивать предыдущее значение с последующим и, если оно меньше, дать добро на запись нового значения? или есть ещё какие-то приёмы...

Дмитрий Артюховский
22.11.2010, 12:06
записывайте данные сами в файл, туда же штамп времени... после записи файла делаем паузу и пытаемся его считать ... (не менее 10 мс на реальную запись флеша!!! ) не получилось - записываем файлик с маркером утери данных и пытаемся еще раз записать значения, получилось - стираем маркер.... и молимся чтобы хватило времени аккумулятора.... да, запись выполняем либо регулярно, либо по флагу пропадания питания.....

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

Safron
22.11.2010, 13:56
предлагаю вашему вниманию последнию версию програмки которую, сейчас обкатываю...
Хорошо, что предупредили про Eeprom.
Получается, что если отказаться от записи в эн. незавимую память, то данные будут потеряны при выключении питания?

Филоненко Владислав
22.11.2010, 15:24
Вот для этого и сделан Retain. Но контролировать что в переменной лежит то, что требуется всё еще надо :)

Safron
23.11.2010, 05:32
Про генератор думал тоже, что надо бы по хорошему разместить в каждом агрегате. Теперь переделаю однозначно.
сброс накопленной величины и аварию тоже планирую (после того как решу вышеназванную проблему)
Retain как-то пробовал воспользоваться. Сохраняются величины только если retain объявлены были в PLC_PRG. Почему не знаю...
А отсутствие ClearScreen 2/ClearScreen3 и integral это издержки бесконечных попыток переделывания программы... Так. что не обессудьте. Обязательно устраню косяки свои..
Спасибо за конструктивные замечания!!!

Дмитрий Артюховский
24.11.2010, 22:09
смело надеееться на retain может только человек регулярно меняющий аккумуляторы в ПЛК и всячески следящий за их состоянием.... увы, я уже не надеюсь.... данные не сохранились из-за разряженного (деградировавшего) аккумулятора, а крайним будет программер ))) лучше самому записать... и уж точно при включении проверять кооректность данных, иначе алгоритм может пойти налево лесом!

Safron
25.11.2010, 13:50
да похоже Retain это Not Retain... ни в самих фб, ни в глобальных они не сохраняются. вот мне , ну никак не надо их объявлять в Plc_prg..., а похоже придётся...

Safron
26.11.2010, 12:08
модераторам. можете закрывать тему...