Задание распределения в процентах

[VADR]

Приветствую, коллеги.

Столкнулся с задачей, вроде бы простейшей, но мысль как-то в голову не приходит.
Суть в следующем: есть три ёмкости с сыпучим материалом. Выгрузка материала из этих ёмкостей производится шнеками с ЧРП, скорость выгрузки из каждой ёмкости задаётся оборотами соответствующего шнека. Суммарная выгрузка определяется на "приёмной" стороне. Соотношение должно задаваться оператором в процентах. Емкости полностью "равноправные", то есть соотношение может быть любым. Вопрос в том, как при задании соотношения "разрулить" эти проценты. С двумя ёмкостями было бы просто: оператор задаёт процент на любой из них, система вычитает эту цифру из 100 и задаёт на второй. Как быть с тремя? Наверняка кто-то уже с такой задачей сталкивался...

[AppCreator]

Вопрос в том, как при задании соотношения "разрулить" эти проценты

Как вариант с понятной оператору логикой - по типу круговой секционной диаграммы на три секции, где 360 гр. = 100 %

[VADR]

Про такой вариант я думал, как и про линейку с двумя ползунками. Проблема: это нестандартные графические элементы и не факт, что на целевой системе это можно будет сделать. Цифры ввести точно можно.

[UNTK_RAA]

А если так: есть три ползунка. Первые два можно круть, третий - автоматический.
1 ползунок задает нагрузку в % в первом шнеке,
2 второй - во втором,
3 третий - вычисляет остаток от 100%.

Например 1:
Шнек1 Шнек 2 Шнек 3
33% 33% 34% (100%-33%-33%)

Например 2:
Шнек1 Шнек 2 Шнек 3
23% 33% 44% (100%-23%-33%)

Добавить ограничение на корректировку

[Ryzhij]

Можно окна ввода рецепта делать с кнопками записи.
Каждый компонент с двумя окошками - (1) "ввод нового значения", (2) "введённое значение" - и кнопка ввода "обновить" для компонента.
Тогда по нажатиям кнопок определяется какие компоненты будут "ведущими", а какой "по остаточному принципу".
После нажатия предпоследней, в нашем случае - второй по очереди, кнопки можно выводить экран с результатами набора для подтверждения и окончательного принятия в работу изменённой рецептуры, либо к возврату в экран ввода компонентов..
Тогда компоненты можно будет задавать в любом порядке.

[VADR]

Спасибо, варианты интересные. Собрав, перемешав и переварив (а также учтя, что "ползунки" операторам не особо нравятся), придумал примерно следующее:
1. Ввод каждой цифры действует на следующую (третья - на первую), при вводе такой цифры, при которой следующая падает в ноль - снижать введённую до суммы 100%;
2. Ввод делать во временный набор, который идёт в работу по кнопке "применить".
Как-то так, должно получиться неплохо.

Всем спасибо!

[jerri_can]

Точно так! Делал дозирование на экструдере по такому принципу. было три компонента, процентовка вводилась на ОП. Если сумма не равна 100 процентов, то аварийный сигнал. Автопересчет не делал, но встречал такое на дозаторах разных фирм.

[Jackson]

Времени много прошло, но я всё-таки внесу 5 копеек.

С двумя ёмкостями было бы просто: оператор задаёт процент на любой из них, система вычитает эту цифру из 100 и задаёт на второй. Как быть с тремя?

Точно также как и с двумя. Для каждого из трёх шнеков у оператора переключатель "задание расхода авто/ручное". Оператор задаёт общий расход - система делит этот расход поровну между теми шнеками, для которых задано "авто". Для тех, у которых задано "ручное" оператор задаёт расход сам в процентах, а между оставшимися (в "авто") система делит расход поровну: вычитаем из 100% заданное вручную и остаток делим на количество шнеков в "авто".

Если сумма не равна 100 процентов, то аварийный сигнал

А можно ещё проще. Оператор не будет крутить две ручки сразу (просто не давать ему такой возможности), и ограничивать каждую ручку оставшимся пределом. К примеру, задали первому шнеку 50%, значит ни второму ни третьему больше 50% уже не задать. А точнее, предел вычисляемый и равен он 100 минус сумма заданий соседних шнеков.

Отправлено спустя 7 минут 36 секунд:
Только ещё дискретность надо предусмотреть, потому что задание например 1% - неэффективно и, скорее всего, физически невозможно - не сможет ЧРП вращать привод шнека с частотой, равной 1% от номинальной. Надо определить минимальное возможное задание и меньше его уже быть не может: либо минимум, либо ноль (ЧРП останавливается). Что, соответственно, должно повлиять на расчёт задания для остальных.

К примеру, оператор задал для первого шнека 50%, для второго 49%, а минимальный порог - 10%. Автоматика говорит "не, дорогой, так мы работать не будем. Первый ты задал 50%, а второму больше 40% я тебе выставить не дам, ну или отключай третий шнек и тогда разрешу (допустимые пределы задания пересчитаются)."

[VADR]

Я в итоге решил особо не мудрить. Три поля с лимитами 0..100%, оператор вводит, как хочет, а система потом пересчитывает как доли от суммы. То есть - ввели 100, 60, 40 - получили 50, 30, 20. И с низкими скоростями тоже придумано. Минимальная частота для стабильной работы - 10 Гц (вернее, проверяли на 5 - нормально, оставили 10 с запасом). Наездники на движках есть, так что перегрева не будет. Ну а скорости ниже 10 Гц делаем периодическим пуском: например, чтобы сделать 5 Гц - крутим с частотой 10 Гц 10 секунд и 10 секунд стоим. Шнеки, движки и редукторы такой режим выдержат - тоже проверено: есть один узел, на котором оригинальные немецкие разработчики так сделали (изначально в проекте ошиблись с производительностью) - работает уже 5-й год.

[Jackson]

Я в итоге решил особо не мудрить. Три поля с лимитами 0..100%, оператор вводит, как хочет, а система потом пересчитывает как доли от суммы.

Просто я не знаю что там за АРМ и какие у него возможности. Видел в нескольких местах визуальные контролы для задания параметров с переменным порогом, и этот порог подставляется из переменной, а пересчёт делается в момент записи нового задания. Соответственно, если не дать оператору возможность крутить больше 1 ручки за раз, то не будет вот этих непоняток для оператора:

ввели 100, 60, 40 - получили 50, 30, 20

Ввели, получили, не устроило - вводим снова, может опять не устроит - снова вводим....

По сути ничего не меняется, просто оператор сразу видит и понимает пределы в которых он может рулить и что надо сделать, чтобы эти пределы изменились.
Оператор задал одно значение - пределы пересчитались и в двух других ручках, когда до них дойдёт оператор, они уже новые актуальные.

Просто удобство оператора. Когда ввёл одно, а получил другое - это заставляет операторов нервничать и дополнительно соображать "а правильно ли я всё сделал? или система глючит?" Если можно исключить дополнительную нагрузку на мозг оператора - я бы так и сделал.

[VADR]

Просто я не знаю что там за АРМ и какие у него возможности. Видел в нескольких местах визуальные контролы для задания параметров с переменным порогом, и этот порог подставляется из переменной, а пересчёт делается в момент записи нового задания.

Там панельки 7". Функционал довольно ограничен. Наилучшим решением, на мой взгляд, была бы линейка с несколькими ползунками. Для трёх шнеков - два ползунка, делящие линейку на три части. двигаем один - меняются цифры двух соседних, а сумма всегда 100. Но такого контрола в панельке нет, и самодельные не поддерживаются.

Ввели, получили, не устроило - вводим снова, может опять не устроит - снова вводим....

Через поля ввода - нужна ещё одна кнопка "применить". И, желательно, отдельные поля для ввода и для вывода результирующих цифр. Что касается самих вводимых цифирь - их оператор не из головы берёт, а технологическое руководство выдаёт: смешивать в соотношении, к примеру, 60/30/10. И тут уже их забота, чтобы 100% в сумме получалось. Им высшее образование на то дано :)

[Jackson]

Там панельки 7". Функционал довольно ограничен.

Панельки разные бывают. В вейнтеке это есть. Ну да ладно, проехали.

[SBeaRM]

Три поля с лимитами 0..100%, оператор вводит, как хочет, а система потом пересчитывает как доли от суммы. То есть - ввели 100, 60, 40 - получили 50, 30, 20.

Оператор должен всё таки быть умнее обезьяны. Нужно просто сделать контроль суммы введенного рецепта в ПЛК или панели и если она не равна 100%, запрещать работу, сообщив оператору, что он ввел некорректные числа.
Пересчитывать не правильно. При ошибке оператора, система должна сообщить ему, что он ошибся, а не работать по какому-то левому рецепту.
Так работают некоторые асфальтовые заводы, где рецепт по компонентам вводится как соотношение на тонну. В рецепте параметров 6-7 и при не равенстве их суммы 100% завод не дает загрузить рецепт, сообщая об ошибке. Оператор должен проверить где ошибся и поправить некорректные параметры.
Данный подход пока ни у кого проблем не вызывал.

[Михайло]

С точки зрения управления как-то некорректно регулировать такие проценты. Это как-то и уму непостижимо. Наверняка оператор мыслит другими категориями... Скорее он хочет управлять временем опустошения ёмкостей и чтобы между опустошением ёмкостей было определенный временной промежуток. Так почему же не взять именно эти величины для регулирования?

Выбираешь порядок опустошения и три промежутка времени, при чем первый промежуток времени вычисляется.

[Ryzhij]

Наверняка оператор мыслит другими категориями... Скорее он хочет управлять временем опустошения ёмкостей

Предлагаю не фантазировать на тему конкретной реализации технологической схемы, а исходить из постановки задачи.
Есть рецептура и её надо ввести в систему.
Остальное - от лукавого.

[VADR]

Пересчитывать не правильно. При ошибке оператора, система должна сообщить ему, что он ошибся, а не работать по какому-то левому рецепту.
Так работают некоторые асфальтовые заводы, где рецепт по компонентам вводится как соотношение на тонну.

Поясню по поводу объекта. Это склад твёрдого топлива для котлоагрегата. В бункерах - разные виды топлива: рубленая топливная древесина, кородревесные отходы со своего производства и привозные древесные отходы. Отходы самостоятельно горят не очень хорошо, поэтому их придумали смешивать с рубленой топливной щепой. Некоторое смещение пропорции туда/сюда на небольшой период времени проблемы не вызовет (в отличие от нарушения рецептуры бетонной смеси). К тому же этот объект подсунут в управление оператору котла "заодно". Ему и котла более чем достаточно, чтобы следить за правильными режимами. Если тут ещё и склад будет капризничать - из-за ошибки в пару процентов отказываться работать - это лишняя головная боль для оператора.

Наверняка оператор мыслит другими категориями... Скорее он хочет управлять временем опустошения ёмкостей и чтобы между опустошением ёмкостей было определенный временной промежуток.

Ваще не так (С). В идеале (т.е. когда всё исправно и топлива достаточно) ёмкости вообще не должны опустошаться. Оператор берёт топливо в том количестве, которое надо для работы, а соседний цех этим топливом его обеспечивает.

[Михайло]

В идеале (т.е. когда всё исправно и топлива достаточно) ёмкости вообще не должны опустошаться.

Ну и какая стратегия управления? Выравнивание уровня? Тогда оператор должен отрабатывать как три датчика уровня - ему это понятно и просто. А от этого уже автоматически вычислять скорости шнеков, исходя из стратегии выравнивания уровней. А рулить дифференциалом - боже упаси.
Если загрузка известного объема, то сделать кнопки "загрузка", которые облегчат выставление нового уровня после стандартной загрузки.

[VADR]

Ну и какая стратегия управления? Выравнивание уровня?

Зачем? Уровни в ёмкостях вообще не являются здесь целевыми функциями. Это склад топлива для котельной. Как бензобак в машине: контроллер двигателя, управляющий подачей топлива, не имеет цели поддержания уровня в бензобаке. Он управляет подачей бензина в двигатель, а уж за уровнем в баке пусть водитель следит и заправляет по необходимости.

[Ryzhij]

Ну и какая стратегия управления?

Поддержание заданных пропорций в смеси независимо от расхода смеси.
Это потоковое смешение.
Алгоритмы подобного смешения используются во многих отраслях.

[Looker]

Делал почти 20 лет назад, датчик чистого метана вечно "бардачил". Датчики по всем углеводородам работали отлично, но тяжелыми углеводородами добавляли до 3% (к метану, которого более 30% не было - дегазация шахты.). Даже скандал был, поэтому такой экран возник. На другом экране был выбор: что использовать.

[Jackson]

Оператор должен всё таки быть умнее обезьяны.

Но требование иметь защиту от неправильных действий оператора из ПБ не вычеркнешь.
Да и по сути, лично меня очень бесит когда задал одни значения, а в итоге получил другие потому что системе виднее как надо. Любому человеку противно осознать, что кусок металла и пластика что-то решает за него, или вносит коррективы в его решения (восстанием машин попахивает). Это как комиссия за платёж, о которой Вы узнаёте уже по факту платежа, когда заднего хода уже нет и придётся платить. Устраивает? Нравится? Не думаю.

Даже такие "умные" системы управления как БЩУ ядерного реактора, которые сами подбирают кое-какие параметры за человека - если там оператор задаёт какие-то цифры, то именно эти цифры он в итоге и получает (остальными можно варьировать, но не теми которые задаёт оператор). Оператор всегда ждёт что заданные им параметры будут достигнуты, природа человека такая, а когда кто-то или что-то корректирует его ожидания - это никому не по душе и всегда нервирует, а значит повышает вероятность ошибки и впоследствии аварии.

Интуитивно понятный интерфейс - это предсказуемый интерфейс. Что задал - то и получил, а если получить заданное физически невозможно то и возможности задать такие значения быть не должно.
Но это вопрос реализации. Это моё ИМХО. По крайней мере я делаю интерфейсы так.

[Михайло]

Это потоковое смешение.

Это теория. А практика? Смешение одинаковых щепок?
Я бы выставил пропорцию 33/33/33 и забыл бы про ваши теории. Но что-то толкает на изменение пропорции... Это осталось нераскрытым.

[VADR]

А практика? Смешение одинаковых щепок?

Вот как раз суть в том, что не одинаковых. Для одинаковых вообще не проблема - грузить можно поочерёдно из разных бункеров (что сейчас и делается).