Вы таки упёрлись в ограничение по ресурсам ПР200?Сообщение от Сергей0308
С интересом посмотрю, как вы с этим подходом будете 33 клапан подключать.Почти все элементы с возможностью расширения, стек сразу сделал до 32 клапанов(не включительно):
Обладатель чёрного пояса по вышке и программированию явился на нашу школьную олимпиаду.
Уважаемый, не мешайте людям развлекаться и кипятить свои мозги.
Сейчас в стеке по сути 5 регистров сдвига 31 разрядного, 5 бит дают 32 состояния, ноль не используется, типа когда все входы выключены(состояние "0"), поэтому максимум 31 клапан! Если добавить ещё один такой регистр, по сути увеличить стек на 1/5, это уже 6 бит, 64 возможных состояния и 63 клапана максимум("0" также не используется) и т. д. Это если не увеличивать глубину очереди(пока 31), с входными-выходными элементами проблем не возникнет, практически ничего не стоит расширить например демультиплексор или дешифратор!Вы таки упёрлись в ограничение по ресурсам ПР200?
С интересом посмотрю, как вы с этим подходом будете 33 клапан подключать.
Обладатель чёрного пояса по вышке и программированию явился на нашу школьную олимпиаду.
Уважаемый, не мешайте людям развлекаться и кипятить свои мозги.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Всё это конечно интересно, но любой "сбойный" ("моросящий" по вашему) датчик кладёт всю систему (прямо "родовое пятно" какое-то). От чего могут возникать некритичные сбои датчиков уровня, говорил выше. Алгоритм чётко встаёт на сбойном датчике (заполнение не отключается), и это хорошо для поиска причины.
сбой.PNG
У моего решения подобных недостатков нет.
1)Можно одновременно открывать несколько линий залива. (от превышения числа открытых линий при сбоях избавился)
2) использование 2х уровней. верх/низ (можно объединить в 1 датчик).
3) "моросящий" по зыби датчик, отправляется в конец очереди. (уровень жидкости упадёт, и он нормально отработает).
4) задержка включения следующего клапана - (это важно для катушек переменного тока при одновременной работе нескольких линий)
В исходном (после запуска симулятора) - все датчики показывают минимальный уровень.
Вроде всё уже писал, думаю повторять в каждом посте нет необходимости?! И что мешает это отдельно сделать по гистерезису или как Мелкий предлагал, по времени или и то и другое всё вместе! Мне кажется это правильней, чем городить супер макрос, лучше когда под рукой отдельные функции и лепишь из них что хочешь, это как буквы и иероглифы!
Можно конечно сделать если вход выключился до включения соответствующего выхода чтобы этот клапан удалялся из очереди(если Гампус не успеет объявиться к этому времени), в следующей версии наверно так и сделаю!
И насчёт массивов, я наверно ещё не осознал их полезность, чем критиковать лучше конкретный пример привели бы, не очень заумный, чтобы понятно всем стало, это Ситникову!
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
У меня и сделано по гистерезису, при использовании 2х датчиков на канал. Необходимо и достаточно.
У каждого свой подход. Каждый пишет так, как ему удобнее.Мне кажется это правильней, чем городить супер макрос, лучше когда под рукой отдельные функции и лепишь из них что хочешь, это как буквы и иероглифы!
С использованием специализированных макросов проще масштабирование делать.
Если вы это будете делать со стеком - то ещё и ALU напишете.Можно конечно сделать если вход выключился до включения соответствующего выхода чтобы этот клапан удалялся из очереди(если Гампус не успеет объявиться к этому времени), в следующей версии наверно так и сделаю!
А моя программа ничего не напоминает? ни на какие мысли не наводит?И насчёт массивов, я наверно ещё не осознал их полезность, чем критиковать лучше конкретный пример привели бы, не очень заумный, чтобы понятно всем стало, это Ситникову!
Программа как программа, кстати тоже очень несовершенная, нажал на верхний уровень ёмкости работающего клапана, переключился на следующий, а по-моему неправильно, нижнего уровня нет, а верхний сработал, по-моему как минимум предупреждение о неисправности!У меня и сделано по гистерезису, при использовании 2х датчиков на канал. Необходимо и достаточно.
У каждого свой подход. Каждый пишет так, как ему удобнее.
С использованием специализированных макросов проще масштабирование делать.
Если вы это будете делать со стеком - то ещё и ALU напишете.
А моя программа ничего не напоминает? ни на какие мысли не наводит?
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Подобную защиту при необходимости удобнее "навесной" сделать, а не включать в состав основного модуля.
Конкретный пример: очередь. Т.е. с одной стороны записываем (например, номера опустевших баков), из другой читаем (первый опустел -- его перого и будем заполнять).
В варианте олимпиады под эгидой "нет массивам" это делается как кучка 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 элементов" был полностью протестирован (как, кстати? ведь в ОЛ нет автотестов), то новый блок придётся тестировать заново.
Запустить в эксплуатацию и ждать когда взорвётся бак?
В случае массивов же, шансов на ошибку гораздо меньше, ведь для увеличения/уменьшения длины очереди достаточно будет лишь изменить размер массива.
Вот у меня есть такой макрос:
EEPROM.PNG
Чем он не дотягивает до массива(способ создания опустим)? На сколько понял на запись счётчик поставить, чтобы каждый раз увеличивал на единицу адрес ячейки записи, на чтение не очень понятно и надо ли там какие связи "налаживать", а то у меня все ячейки независимые, никак между собой не связаны?
Вот, на всякий случай проект с макросом:
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Вот тут я отвечал на этот же вопрос:
И чуть позже дополнял: http://www.owen.ru/forum/showthread....l=1#post237637
Да, в вашем проекте вместо линий задержки используются переменные, но это всё равно не исключает шанса на ошибку (выбор не той переменной). И всё равно ПР проводит все-все-все вычисления на каждом цикле.
С массивом не пришлось бы переливать из пустого в порожнее весь набор данных на каждом цикле ПР.
Ответить с цитированием
