Тогда, пока не поздно, новая версия очереди, повысил КПД стека в 6,4 раза, раньше на запоминание включения каждого входа уходил один SEL(32 бита), теперь 5 бит! Почти все элементы с возможностью расширения, стек сразу сделал до 32 клапанов(не включительно):Сообщение от Алексей Геннадьевич
Очередь_3.PNG
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Чего только не сделают, лишь бы не массивом.
Вы таки упёрлись в ограничение по ресурсам ПР200?
С интересом посмотрю, как вы с этим подходом будете 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 напишете.Можно конечно сделать если вход выключился до включения соответствующего выхода чтобы этот клапан удалялся из очереди(если Гампус не успеет объявиться к этому времени), в следующей версии наверно так и сделаю!
А моя программа ничего не напоминает? ни на какие мысли не наводит?И насчёт массивов, я наверно ещё не осознал их полезность, чем критиковать лучше конкретный пример привели бы, не очень заумный, чтобы понятно всем стало, это Ситникову!
Конкретный пример: очередь. Т.е. с одной стороны записываем (например, номера опустевших баков), из другой читаем (первый опустел -- его перого и будем заполнять).
В варианте олимпиады под эгидой "нет массивам" это делается как кучка 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 элементов" был полностью протестирован (как, кстати? ведь в ОЛ нет автотестов), то новый блок придётся тестировать заново.
Запустить в эксплуатацию и ждать когда взорвётся бак?
В случае массивов же, шансов на ошибку гораздо меньше, ведь для увеличения/уменьшения длины очереди достаточно будет лишь изменить размер массива.
Ответить с цитированием
