А здесь говорится про очередь. http://www.owen.ru/forum/showthread....l=1#post235996Сообщение от Алексей Геннадьевич
А здесь говорится про очередь. http://www.owen.ru/forum/showthread....l=1#post235996
Таки да.
Только это не нужно. И если рассматривать и реализовывать полную группу событий, то алгоритм некислый получается...
Вообще-то все клапана.
Grampus явится, и решит что ему больше подойдёт.
Последний раз редактировалось Алексей Геннадьевич; 14.02.2017 в 14:08.
Тогда, пока не поздно, новая версия очереди, повысил КПД стека в 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) задержка включения следующего клапана - (это важно для катушек переменного тока при одновременной работе нескольких линий)
В исходном (после запуска симулятора) - все датчики показывают минимальный уровень.
Ответить с цитированием
