Почистил библиотеку в программе, попробуйте теперь в железе. Посмотрите как уменьшился объём программы.Цитата:
Сообщение от Satellite83
Вид для печати
Почистил библиотеку в программе, попробуйте теперь в железе. Посмотрите как уменьшился объём программы.Цитата:
Сообщение от Satellite83
Спасибо, попробую по результатам отпишусь обязательно.
Может надо не ИБП, а Сетевой Фильтр от импульсных помех?Цитата:
Сообщение от Satellite83
Установленны ИБП с фильтрами импульных помех, так как от этих вводов питаеться вся техника и сервер Сбербанка, которые сидят в этом здании
Вот устранил возможные проблемы при первом включении несколько изменив алгоритм работы:Цитата:
Сообщение от Василий Кашуба
Вложение 29455
Теперь всё отлично.Цитата:
Сообщение от Сергей0308
:D "интерсные личности" есть на всех производствах. Как вам сушка промасленной фуфайки в автоклаве с кислородным наддувом? - до такого даже Бен Ладен не додумается...Цитата:
Сообщение от Сергей0308
Нормально. Небольшая переработка макроса 8-DTRIG позволяет работать с 2мя датчиками верхнего и нижнего уровней на ёмкость.Цитата:
Сообщение от Сергей0308
Но: малейший джиттер любого входного датчика ложит систему наглухо. (это актуально в системе с одним датчиком уровня в ёмкости).
Вопрос к разработчикам PID регулятора:
В варианте нагревателя выходной сигнал меняется в диапазоне 0...1 , а в режиме холодильник 99...100. В чем смысл?
Ну и общее соображение: большинство разработчиков промышленных регуляторов используют не коэффициент усиления, а зону пропорциональности. В принципе это не проблема ЗПР=1/КУ, что я и сделал.
Вы хотя бы какие нибудь скрины или программу выложили бы, а то не понятно к чему ваши заявления, так как ПИД регуляторов в ОЛ уже много разных ходит.Цитата:
Сообщение от Власов
На самом деле стек для решения этой задачи не нужен. Вообще.Цитата:
Сообщение от Сергей0308
Проще не придумаешь.
Обход заданного количества клапанов с разрешением одновременной работы определённого количества.
Вложение 29474Вложение 29476Вложение 29477
Я не вникал в работу отдельных макросов, поэтому прошу прокомментировать этот скрин.Цитата:
Сообщение от Алексей Геннадьевич
Вложение 29475
Перед запуском на исполнение, я активировал четыре датчика, запустил симулятор и включил вход Wen.
1) Вы отключили 4 датчика. (нет жидкости- отключен, есть-включен) У первого макроса по 2 датчика на канал (верх/низ)Цитата:
Сообщение от Василий Кашуба
2) Установлена одновременная работа 3х клапанов. (настраивается из свойств макроса)
Пока вы не отключите хотя-бы один активный канал следующий не включится. Приоритет имеет датчик верхнего уровня.
Но у Вас же не запоминает очерёдность постановки в очередь, у Вас жёсткий приоритет включения, автор вопроса хотел чтобы выхода включались по очереди, в зависимости от очерёдности включения входов, т. е совсем другой алгоритм работы, не исключаю что в большинстве случает этого достаточно(вашего алгоритма работы)!Цитата:
Сообщение от Алексей Геннадьевич
Внимательно читаем уточнённый ТЗ.Цитата:
Сообщение от Сергей0308
http://www.owen.ru/forum/showthread....l=1#post236238
А "очерёдности" и "стек" мы с вами сами напридумывали для решения простой задачи. Соответственно навылезали всякие "ветряные мельницы", с которыми стали "бороться".
А здесь говорится про очередь. http://www.owen.ru/forum/showthread....l=1#post235996Цитата:
Сообщение от Алексей Геннадьевич
А то что вы выделили, это уточнение, почему нельзя открывать несколько клапанов.Цитата:
Сообщение от Алексей Геннадьевич
Таки да.Цитата:
Сообщение от Василий Кашуба
Только это не нужно. И если рассматривать и реализовывать полную группу событий, то алгоритм некислый получается...
Вообще-то все клапана.Цитата:
Сообщение от Василий Кашуба
Grampus явится, и решит что ему больше подойдёт.
Тогда, пока не поздно, новая версия очереди, повысил КПД стека в 6,4 раза, раньше на запоминание включения каждого входа уходил один SEL(32 бита), теперь 5 бит! Почти все элементы с возможностью расширения, стек сразу сделал до 32 клапанов(не включительно):Цитата:
Сообщение от Алексей Геннадьевич
Вложение 29488
Чего только не сделают, лишь бы не массивом.Цитата:
Сообщение от Сергей0308
Вы таки упёрлись в ограничение по ресурсам ПР200?Цитата:
Сообщение от Сергей0308
С интересом посмотрю, как вы с этим подходом будете 33 клапан подключать.:)Цитата:
Почти все элементы с возможностью расширения, стек сразу сделал до 32 клапанов(не включительно):
Обладатель чёрного пояса по вышке и программированию явился на нашу школьную олимпиаду.Цитата:
Сообщение от Владимир Ситников
Уважаемый, не мешайте людям развлекаться и кипятить свои мозги. ;)
Владимир Ситников вот одно из условий, выполнить некую процедуру не применяя массив.
Сейчас в стеке по сути 5 регистров сдвига 31 разрядного, 5 бит дают 32 состояния, ноль не используется, типа когда все входы выключены(состояние "0"), поэтому максимум 31 клапан! Если добавить ещё один такой регистр, по сути увеличить стек на 1/5, это уже 6 бит, 64 возможных состояния и 63 клапана максимум("0" также не используется) и т. д. Это если не увеличивать глубину очереди(пока 31), с входными-выходными элементами проблем не возникнет, практически ничего не стоит расширить например демультиплексор или дешифратор!Цитата:
Сообщение от Алексей Геннадьевич
Всё это конечно интересно, но любой "сбойный" ("моросящий" по вашему) датчик кладёт всю систему (прямо "родовое пятно" какое-то). От чего могут возникать некритичные сбои датчиков уровня, говорил выше. Алгоритм чётко встаёт на сбойном датчике (заполнение не отключается), и это хорошо для поиска причины.Цитата:
Сообщение от Сергей0308
Вложение 29528
У моего решения подобных недостатков нет.
1)Можно одновременно открывать несколько линий залива. (от превышения числа открытых линий при сбоях избавился)
2) использование 2х уровней. верх/низ (можно объединить в 1 датчик).
3) "моросящий" по зыби датчик, отправляется в конец очереди. (уровень жидкости упадёт, и он нормально отработает).
4) задержка включения следующего клапана - (это важно для катушек переменного тока при одновременной работе нескольких линий)
В исходном (после запуска симулятора) - все датчики показывают минимальный уровень.
Цитата:
Сообщение от Сергей0308
Цитата:
Сообщение от Сергей0308
Вроде всё уже писал, думаю повторять в каждом посте нет необходимости?! И что мешает это отдельно сделать по гистерезису или как Мелкий предлагал, по времени или и то и другое всё вместе! Мне кажется это правильней, чем городить супер макрос, лучше когда под рукой отдельные функции и лепишь из них что хочешь, это как буквы и иероглифы!Цитата:
Сообщение от Алексей Геннадьевич
Можно конечно сделать если вход выключился до включения соответствующего выхода чтобы этот клапан удалялся из очереди(если Гампус не успеет объявиться к этому времени), в следующей версии наверно так и сделаю!
И насчёт массивов, я наверно ещё не осознал их полезность, чем критиковать лучше конкретный пример привели бы, не очень заумный, чтобы понятно всем стало, это Ситникову!
У меня и сделано по гистерезису, при использовании 2х датчиков на канал. Необходимо и достаточно.Цитата:
Сообщение от Сергей0308
У каждого свой подход. Каждый пишет так, как ему удобнее.Цитата:
Мне кажется это правильней, чем городить супер макрос, лучше когда под рукой отдельные функции и лепишь из них что хочешь, это как буквы и иероглифы!
С использованием специализированных макросов проще масштабирование делать.
Если вы это будете делать со стеком - то ещё и ALU напишете.:cool:Цитата:
Можно конечно сделать если вход выключился до включения соответствующего выхода чтобы этот клапан удалялся из очереди(если Гампус не успеет объявиться к этому времени), в следующей версии наверно так и сделаю!
А моя программа ничего не напоминает? ни на какие мысли не наводит?Цитата:
И насчёт массивов, я наверно ещё не осознал их полезность, чем критиковать лучше конкретный пример привели бы, не очень заумный, чтобы понятно всем стало, это Ситникову!
Программа как программа, кстати тоже очень несовершенная, нажал на верхний уровень ёмкости работающего клапана, переключился на следующий, а по-моему неправильно, нижнего уровня нет, а верхний сработал, по-моему как минимум предупреждение о неисправности!Цитата:
Сообщение от Алексей Геннадьевич
Подобную защиту при необходимости удобнее "навесной" сделать, а не включать в состав основного модуля.Цитата:
Сообщение от Сергей0308
Конкретный пример: очередь. Т.е. с одной стороны записываем (например, номера опустевших баков), из другой читаем (первый опустел -- его перого и будем заполнять).Цитата:
Сообщение от Сергей0308
В варианте олимпиады под эгидой "нет массивам" это делается как кучка SEL'ов. Начинаются игры "как поддержать очередь на 33 бака и не сломать мозг об SEL".
Да, в качестве игры это, конечно, норм.
Но вот для надёжного решения (а в пром автоматике же нужны именно надёжные решения?) должно быть ясно и прозрачно что это не 100500 SEL'ов, а очередь.
Чтобы не требовалось день изучать схему для осознания того, что хотел сказать автор.
С массивом это было бы так:
1) Объявляем массив для хранения очереди. При объявлении указываем его размер. Нужна очередь на 8? Указываем 8 в объявлении. Нужна на 48? Указываем 48. При этом не приходится добавлять и проводить связи между этими 48 SEL'ами, а просто объявили, что нам нужен массив из этих самых 48 ячеек.
2) Для записи/чтения используем две переменные. Одна указывает на порядковый номер ячейки для записи, вторая -- порядковый номер ячейки тения.
3) Запись это просто взять номер ячейки для записи, записать туда значение, увеличить переменную-индекс записи (ну и обработать случаи очередь переполнена/индекс вышел за границы). Можно себе представлять это как блок-"запись в ФБ" с параметрами "имя массива", "порядковый номер ячейки" и "записываемое значение".
4) Чтения -- берём значение из массива по порядковому номеру. Можно себе представлять это как "read from FB" с параметрами "имя массива" и "порядковый номер ячейки", а на выходе -- "результат чтения".
Очередь, стек, линия задержки, всё это гораздо проще программировать и понимать именно с массивом, а не с месивом SEL/GT блоков.
В общем, сила массива в том, что "количество ячеек" можно указать одним числом, и это исключает ошибки copy&paste, которые могут возникнуть при ручном размножении SEL'ов.
Да и потребление ресурсов у массива должно быть меньше, чем у кучки SEL'ов.
Тут кто-нибудь может сказать: "но макрос STEK это же и есть простое и понятное решение с N входами и N выходами. По названию понятно, что стек. Зачем массивы-то нужны?"
Если возникла такая мысль, то человек ничего не понял.
Вдруг в этом самом макросе STEK какая-нибудь связь неправильно проложена? Как это проверить? Как вариант упражнения: давайте я удалю какую-нибудь связь (нарисую лишнюю) и посмотрим сколько времени уйдёт у "эксперта-электронщика" на поиск ошибки, когда он будет заранее знать, что ошибка есть?
А, если нужен стек не на 8 входов, а на 33? Придётся, ведь, макрос перекраивать. Это как раз прямая возможность накосячить. Как тестировать новосозданный макрос на 33 элемента?
Даже, если имеющийся "стек на 8 элементов" был полностью протестирован (как, кстати? ведь в ОЛ нет автотестов), то новый блок придётся тестировать заново.
Запустить в эксплуатацию и ждать когда взорвётся бак?
В случае массивов же, шансов на ошибку гораздо меньше, ведь для увеличения/уменьшения длины очереди достаточно будет лишь изменить размер массива.
Абстрактные хотелки все это для пр200 .Соединить последовательно макросы из 8(16,32) селов не представляет сложности .Если не будет связи ,то выход висящего макроса не будет активен ...О тех ошибках ,что вы говорите вообще ни кто не париться ...исправляются и находятся на раз ...Вроде умный человек ,а вьехать не можете ,что у схемотехников восприятие другое .Если на картине нарисованы 3 кита ,то он и видит три , и ему не надо читать книгу об этом ,где написано ТРИ, да еще на иностранном языке часто .
Полюбуйтесь на перечень доработок в ОЛ 1.9: http://www.owen.ru/forum/showthread.php?t=25870Цитата:
Сообщение от rovki
То, что я предлагаю идёт в работу. Можно сколько угодно с пеной у рта говорить, что "fSEL не нужно", и про "отличия прямых и обратных связей", но против факта не попрёшь. В ОЛ 1.9 добавили встроенный fSEL, и переименовали обратные связи в линии задержки.
Разумеется, массивы в ОЛ 1.9 не попадут, но это не значит, что они "никому не нужны".
С текущими темпами развития, массивы появятся в ОЛ 2.2 (года через 3).
Поймите же, наконец, отличие фраз "никому не нужно" и "не реализовано в ОЛ".
Детский сад какой-то. 3 блока AND это 3 блока AND.Цитата:
Сообщение от rovki
А вот очередь задержки на 400 элементов невозможно окинуть одним взглядом и сказать, что это реально очередь и реально 400, а не 402.
Да и нарисовать/протестировать очередь на 400 элементов за 15 минут не получится.
Была куча исследований на тему того, сколько предметов мозг человека/муравья/обезьяны способен обрабатывать одновременно. Не надо приплетать всякое левое "у электронщиков мозг способен помнить про каждый из 500 элементов". Очевидно, что большинство людей так не может. В том числе, большинство тех, кто по долгу службы работает с ОЛ.
Ну макрос ф сел сделал допустим я . А то что его хотели видеть в составе библиотеки было далеко до вашего снисхождения ....а про задержки так вообще года 3-4 назад писал и спорил с разработчиками ,пока не появились обратные связи ...Не приписывайте себе то что не вы сделали ,для этого надо было на лет пять раньше появиться .Массивы констант одномерные уже давно есть в ол .
В том то и фишка ,что электронщику помнить не надо ,достаточно взглянуть на схему ...В свое время рисовали целые альбомы схем и не чего -живы и помним ...
И не делайте из себя прорицателя -указывая на сроки появления того или иного ,у вас взгляд не похож .
fSEL просили включить в ОЛ ещё тогда, когда вы об этом форуме и не подозревали.Цитата:
Сообщение от Владимир Ситников
Я же считаю, что нужно ещё сделать ФБ fMEMR, т.к. примерно в 70-85% случаев макрос fSEL используется как ячейка памяти.
Да и ФБ MEMR не повредит, для целочисленных переменных.
http://www.owen.ru/forum/showthread....l=1#post229971
Сваял макрос на 32 элемента, оттестил его, воткнул в программу, соединил последовательно N макросов... В чём проблема?Цитата:
А вот очередь задержки на 400 элементов невозможно окинуть одним взглядом и сказать, что это реально очередь и реально 400, а не 402.
Да и нарисовать/протестировать очередь на 400 элементов за 15 минут не получится.
Монитора с разрешением 100500х100500 нет? Так он и не нужен...
Если wal79 скажет, что "рассмотрение fSEL началось с темы 'fSEL, ты где?' ", тоже не поверите ему?Цитата:
Сообщение от Алексей Геннадьевич
Цитирую (ответ программиста ОЛ на моё предолжение добавить блок fSEL в ОЛ):
Цитата:
Сообщение от wal79
Про "линию задержки" все скромно умалчивают? Или у какого-нибудь электронщика хватит смелости заявить, что переименовать "обратную связь" в линию задержки просили до того, как это сделал я?Цитата:
Сообщение от Алексей Геннадьевич
Лучше уж сразу сделать поддержку массива. "одна ячейка" это частный случай массива длины 1.Цитата:
Сообщение от Алексей Геннадьевич
Повторяю по буквам:Цитата:
Сообщение от Алексей Геннадьевич
1) Запросто может оказаться, что какая-нибудь связь пошла не туда, не подключилась, или лишняя связь.
2) В ОЛ отсутствует понятие автоматических тестов. Т.е. пощёлкать на 2-3-4 элемента ещё можно, а вот найти ошибку, что "30 и 31ый элементы перепутаны" крайне затруднительно.
3) Потребление ресурсов ПР будет чрезмерным. Например, линия задержки из 400 SEL'ов будет выполнять как минимум 400 операций в каждом цикле ПР. Каждая SEL ячейка будет "пересохранять значение". В случае же массива, добавление/чтение записи это лишь пара целочисленных операций с индексами. Т.е. не 400 операций, а 3-4.
Ну, давайте, жду чего-нибудь из серии "а в ПР и так мощный процессор, пущай на каждом цикле пересохраняет 400 значений SEL".
Те, кто, якобы, сходу замечают неправильную связь в пауке из 32 элементов пусть сначала обыграют мартышку тут: https://www.youtube.com/watch?v=n_tJoW2hctM
Владимир Ситников на кой вам ОЛ не понятно, для одаренных вроде вас есть КОДЕСИС, вам мало? устройства класса ПР не для таких умных, как вы...........не стоит так усердствовать, смысл объяснять людям не понимая, что окружающие не понимают.......нет смысла умничать не написав ни чего в ОЛ, не охота искать ваши высказывания, но складывается именно такое впечатление......
И заметьте на вопрос показать реализацию массива одни общие фразы ....
Какой такой вопрос?Цитата:
Сообщение от rovki
Разумеется, чтобы захватить мир.Цитата:
Сообщение от Павел Братковский
Кто-то поймёт. melky и Алексей, например, написали про олимпиаду. Значит, всё они поняли. И я соглашался, что это забавная олимпиадная задача.Цитата:
Сообщение от Павел Братковский
Если отбросить шутки в сторону, то по-хорошему, в ОЛ должен быть удобный механизм для работы с очередями/стеками, чтобы в эксплуатации использовать нормальные решения, а не "олимпиадные-непонятно-как-работающие".
Разумеется, окружающие могут сколько угодно считать, что "макрос EPROM" это верх мечтаний, но, надеюсь, разработчики ОЛ осознают (или уже осознали), что массивы это логичное развитие ОЛ. А там уж и электронщики начнут привыкать к массивам.
Плохо сделан OWEN Logic. Идеологически плохо сделан. Чем бесконечно латать дыры в нем лучше сделать новый продукт.
В.Ситников свою Hardella IDE на голом энтузиазме за полгода с нуля своял. Человек в одиночку все сделал за очень короткое время. Я работаю с ней и получаю хорошие результаты. Все сделано добротно, правда редактор весьма необычный.
OWEN Logic бригада разработчиков за не хилые бабки кует, кует и все никак не докует. ;)
Ну почему не поверю? Или у него есть время перечитывать все посты в разделе ПР за последние 4 года?Цитата:
Сообщение от Владимир Ситников
У 100% новичков от этой формулировки пердак подгорает.Цитата:
Про "линию задержки" все скромно умалчивают? Или у какого-нибудь электронщика хватит смелости заявить, что переименовать "обратную связь" в линию задержки просили до того, как это сделал я?
Вообще-то для таких задач контроллер лучше подходит.Цитата:
Лучше уж сразу сделать поддержку массива. "одна ячейка" это частный случай массива длины 1.
Особенно когда делаешь единичный проект.
1) Не нужно пить на рабочем месте.Цитата:
Повторяю по буквам:
1) Запросто может оказаться, что какая-нибудь связь пошла не туда, не подключилась, или лишняя связь.
2) В ОЛ отсутствует понятие автоматических тестов. Т.е. пощёлкать на 2-3-4 элемента ещё можно, а вот найти ошибку, что "30 и 31ый элементы перепутаны" крайне затруднительно.
3) Потребление ресурсов ПР будет чрезмерным. Например, линия задержки из 400 SEL'ов будет выполнять как минимум 400 операций в каждом цикле ПР. Каждая SEL ячейка будет "пересохранять значение". В случае же массива, добавление/чтение записи это лишь пара целочисленных операций с индексами. Т.е. не 400 операций, а 3-4.
2) Автотест это конечно интересно, но сколько усилий уйдёт на создание образа? И насколько уменьшим время поиска ошибки? (это при условии, что образ для автотеста написан правильно)
3) да двигай адреса вкруговую, и не надо ничего смещать-перезаписывать, те-же 3-4 операции... кто запрещает? религия?
16 mhZ. Офигительно крутая "моща"...Цитата:
Ну, давайте, жду чего-нибудь из серии "а в ПР и так мощный процессор, пущай на каждом цикле пересохраняет 400 значений SEL".
Сам-то осилишь ? У неё кратковременная память - фотографическая.Цитата:
Те, кто, якобы, сходу замечают неправильную связь в пауке из 32 элементов пусть сначала обыграют мартышку тут: https://www.youtube.com/watch?v=n_tJoW2hctM
Хорош прибедняться. Прямо как в басне Крылова про лису и виноград... Купит вам директор контроллер, если хорошо попросите и обоснуете.Цитата:
Сообщение от Павел Братковский
ОЛ для относительно простых задач.
Кстати, как ваша система из 4Х32 входных модулей + 2 х 32 выходных + ИП320 + аналоговый ввод + МДВВ работает?
Я такого монстра на ПР200 точно собирать не стану... Мозг вывихнешь на отладке... Только на ПЛК.
Сделан хорошо Овен лоджик! Главное Идеологически правильно .Вот и получайте удовольствие в курилке ,там где хардела .