Владимир Ситников вот одно из условий, выполнить некую процедуру не применяя массив.
Владимир Ситников вот одно из условий, выполнить некую процедуру не применяя массив.
Сейчас в стеке по сути 5 регистров сдвига 31 разрядного, 5 бит дают 32 состояния, ноль не используется, типа когда все входы выключены(состояние "0"), поэтому максимум 31 клапан! Если добавить ещё один такой регистр, по сути увеличить стек на 1/5, это уже 6 бит, 64 возможных состояния и 63 клапана максимум("0" также не используется) и т. д. Это если не увеличивать глубину очереди(пока 31), с входными-выходными элементами проблем не возникнет, практически ничего не стоит расширить например демультиплексор или дешифратор!
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Всё это конечно интересно, но любой "сбойный" ("моросящий" по вашему) датчик кладёт всю систему (прямо "родовое пятно" какое-то). От чего могут возникать некритичные сбои датчиков уровня, говорил выше. Алгоритм чётко встаёт на сбойном датчике (заполнение не отключается), и это хорошо для поиска причины.
сбой.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 элементов" был полностью протестирован (как, кстати? ведь в ОЛ нет автотестов), то новый блок придётся тестировать заново.
Запустить в эксплуатацию и ждать когда взорвётся бак?
В случае массивов же, шансов на ошибку гораздо меньше, ведь для увеличения/уменьшения длины очереди достаточно будет лишь изменить размер массива.
Абстрактные хотелки все это для пр200 .Соединить последовательно макросы из 8(16,32) селов не представляет сложности .Если не будет связи ,то выход висящего макроса не будет активен ...О тех ошибках ,что вы говорите вообще ни кто не париться ...исправляются и находятся на раз ...Вроде умный человек ,а вьехать не можете ,что у схемотехников восприятие другое .Если на картине нарисованы 3 кита ,то он и видит три , и ему не надо читать книгу об этом ,где написано ТРИ, да еще на иностранном языке часто .
Последний раз редактировалось rovki; 15.02.2017 в 17:20.
электронщик до мозга костей и не только
Полюбуйтесь на перечень доработок в ОЛ 1.9: http://www.owen.ru/forum/showthread.php?t=25870
То, что я предлагаю идёт в работу. Можно сколько угодно с пеной у рта говорить, что "fSEL не нужно", и про "отличия прямых и обратных связей", но против факта не попрёшь. В ОЛ 1.9 добавили встроенный fSEL, и переименовали обратные связи в линии задержки.
Разумеется, массивы в ОЛ 1.9 не попадут, но это не значит, что они "никому не нужны".
С текущими темпами развития, массивы появятся в ОЛ 2.2 (года через 3).
Поймите же, наконец, отличие фраз "никому не нужно" и "не реализовано в ОЛ".
Детский сад какой-то. 3 блока AND это 3 блока AND.
А вот очередь задержки на 400 элементов невозможно окинуть одним взглядом и сказать, что это реально очередь и реально 400, а не 402.
Да и нарисовать/протестировать очередь на 400 элементов за 15 минут не получится.
Была куча исследований на тему того, сколько предметов мозг человека/муравья/обезьяны способен обрабатывать одновременно. Не надо приплетать всякое левое "у электронщиков мозг способен помнить про каждый из 500 элементов". Очевидно, что большинство людей так не может. В том числе, большинство тех, кто по долгу службы работает с ОЛ.