Это когда светофоры на командоаппаратах работали, а сейчас ты можешь хоть все цвета одновременно включить. Реле это хорошо, но не панацея. То-же самое и с лифтом. Несомненно, там должны быть цепи безопасности, которые заблокируют движение на уровне разрыва контакта, но если все делать по такому принципу то схема станет максимально сложной и не практичной. Вы вышедшую из строя релюху будете смену искать.
Лапшу накрутили уже не французы, а наши. А европейцы, американцы и прочие всегда делают шкафы с кучей защиты, только в 99,9% случаев они не нужны, но у них такое требование.
В чем проблема помехозащищенности микроконтроллеров? Если человек напрямую тащит кнопку через перекрытия, вдоль силовых линий в порт микроконтроллера, то он по умолчанию - бездарь, а если у меня кнопка заводится через оптопару (как это делается на ПЛК, кстати), то мне вообще плевать на помехи. Что касается взаимоблокировок, так это делается ещё проще и без реле, программный код отрабатывает быстрее чем срабатывает контакт реле, а обработку дребезга кнопки так вообще без проблем. Да, я понимаю о чем вы говорите и даже частично поддерживаю, но не настолько категорично.
Какой смысл ставить промышленный ПЛК для простого проекта, брать для него модули ввода-вывода, искать программиста (именно для этого ПЛК), возможно покупать софт, а потом наполнить его банальной логикой и загрузить на 0,1% от его мощности??? Вот это то как раз и не логично! Проект, который должен быть доступным становится неприступным для людей, а потом санкции и нет возможности замены, софт не поддерживает старые ПЛК и так далее.
P. S. А табло для отражения этажей 1 или 2 сделай в виде одного 7-ми сегментного индикатора, которому при помощи диодов сформируй цифру 1 и 2. И отдавай 2 битовых сигнала с реле, от микроконтроллера, которые развязаны оптопарой. Если понимаешь о чем я...
Я так понимаю что к МК Atmega328 или 168 или 8 вопросов нет, это достаточно надёжные микроконтроллеры и вполне себе может (сам видел лично в куче датчиков и модулей промышленной автоматизации) быть использован для управления хоть лифтом, хоть самогонным аппаратом, хоть конвейером. С автором соглашусь во многих аспектах: исполнение проектов горе-ардуинщиками, когда они собирают из кучки готовых модулей проект и выглядит это как комок проводов, которые связаны в "Гордеев узел". И то, что эти-же горе-ардунщики клепают управление микроконтроллерами при помощи нейросетей. А ещё, вместо того, что бы взять более мощный МК, начинают добавлять модули расширителей входов/выходов, что тоже накладывает отпечаток. С другой стороны, если это все собрано на нормальной плате, с корректными входами и выходами, реле, расчитанные на определённые токи и так далее, а так-же отлаженный программный код, то можно сложные проекты делать и на более простых МК. Взять тот-же лифт, много ли ему нужно? 2 кнопки вызова лифта, 2 кнопки для этажей, 2 концевика и 2 реле управления контакторами двигателя (ну или УПП или ЧП), возможно ещё что-то, для лифта на 2 этажа, но это уже мелочи, 20 входов/выходов, с учётом всех датчиков безопасности, кнопок и даже подсветки, хватит с головой. Как бы логика не сложная, тут и Atmega8 справится. А что касается зависаний, то Watchdog timer никто не отменял. Просто делается программа инициализации, при которой лифт уходит на определённый этаж и там останавливается, ожидая команд. И работать это все будет без проблем. А для надёжности можно ещё один такой МК запрограммировать и положить рядом. 20 лет он точно стабильно отработает. Потом поставить второй, если будет актуально.
Из статьи и ответных комментариев делаю вывод: молодые ребята, программисты (с современным складом ума и опытом в прикладном программировании и это видно из профиля и предыдущих статей автора) , решили, что автоматизация = простое программирование и не более, решили сделать за небольшие деньги автоматизацию металлургического производства (ну это они так решили, что будут именно автоматизацию делать, а не маленький узел аналитики), используя свой небольшой опыт, не понимая суть, смысл и логику промышленной автоматизации, сделали по своему, как умели.
Да, что-то получилось и стало работать, не смотря на множество костылей и подпорок и ребята решили заявить о себе через Хабр, думая что вся автоматизация так работает и им скажут что они большие молодцы, но ребята не могли подумать, что автоматизация работает по другому и множество людей, которые годами с этим работают и знают это всё изнутри, будут не согласны с таким заявлением и прямым текстом скажут ребятам, что они в корне не правы и все, что они сделали и гордо называют автоматизацией, не является таковым. Но ребята решили доказать, что они правы и ввиду своей некомпетентности в вопросах автоматизации просто потопили себя ещё глубже...
Итог всей басни: ребята, учитесь и называйте вещи своими именами, если вам указывают на некорректность ваших заявлений, не спешите доказать что вы умнее, сначала потрудитесь выяснить, почему вам на это указали и только потом делайте выводы и пишите ответные комментарии. В мире немало умных людей, а уж на Хабре их предостаточно и здесь "раскатают" таких экспертов, как вы.
В целом, все неплохо, идеи хорошие, а реализацию до ума можно довести и вы сможете делать аналитику сложных промышленных процессов, главное вникайте в их суть. Для вас это новая сфера и отрасль и там не работают банальные принципы программирования и логика сильно другая. Там нет FrontEnd и BackEnd, там базы данных только на уровне MES систем и устроены они не по классической схеме. И так далее, это совсем другая среда. Простой прикладной программист не зайдёт сюда "с ноги" и не скажет, какой он крутой. Просто не сможет
Ребята, ну какие жы вы тогда автоматизаторы, если не можете интегрировать весы? Вот тут у меня ещё больше вопросов, причём к вашей компетенции и профессионализму. Вы сейчас пишете настолько не корректные вещи, но при этом стремитесь сказать, что не вмешиваетесь в основную инфраструктуру. А в чем тогда смысл вашей доработки - аналитика или все же автоматизация?
А что касается использования подручных средств, то и из веток можно "шалаш" собрать, но будет ли являться это промышленным объектом, вот в чем вопрос. Если бы вы написали, что сделали дополнение к существующий автоматизации, которое позволяет повысить производительность, снизить затраты и так далее, это было бы корректно, ну так вы гордо с максимализмом заявили: "Промышленная автоматизация металлургического производства. Архитектурные решения и техническая реализация" - теперь вам и пишут "коллеги", хотя я не уверен, что вы именно автоматизацией занимаетесь, что то, что вы сделали - не тянет на автоматизацию и даже к "заплатке" мало относится. Ну так вы себя дальше "закапываете", заявляя что не можете интегрировать весы и говорите про какой-то эфимерный датчик воздуха.
Вы вообще понимаете, что такое архитектура автоматизации, что лежит в её основе и как технически это все реализуется?
Плотный проект - это круто! И это несомненно будет работать, но не долго. Через небольшое время, камера покроется слоем пыли, а сетевой диск отвалится и оператор не нажмет кнопку. И так далее. В вашей модели в основе - "костыли", которые "подпирают" процесс, но не автоматизируют. Автоматизация предполагает унификацию, сокращение участков обработки информации, упрощение, отказ от промежуточных блоков обработки, что ведёт к надёжности и возможности запустить линейные и цикличные процессы в автоматическом или автоматизированном режиме (надеюсь понимаете в чем разница) и уже потом отказ от оператора или максимальное снижение зависимости от действий оператора. Не просто так учат в университетах отдельно на промышленную автоматизацию и там нет Pyton, потому что он там не нужен (медленно и не надёжно, требует больших ресурсов для вычисления, что недопустимо для процессов). То, что вы сделали подходит для проведения исследований и переноса этого алгоритма на автоматизацию через ПЛК.
А в чем проблема использовать конвейерные весы? Зачем делать такой сложный механизм анализа? В производстве, если вы делаете высокую точность, 1 минута - это очень много. PID регуляторы отрабатывают порой миллисекунды и крутятся на ПЛК. Да, возможно я не понял суть задачи и мы делали что-то похожее, но так или иначе потом переносили софтовые решения на железо. Иметь кусок программы (для управления, а не для статистики и анализа) в производственном цикле - это огромный риск. Но, если описанный технологический процесс не имел вообще никакой автоматизации, то да, временно, таким сложным, софтовым решением можно закрыть эту "дыру".
Я просто не понимаю, как микросервисы, web и Pyton ассоциируются с надёжностью, доступностью, отказоустойчивостью на уровне промышленной автоматизации? А уж тем более файлы на сетевом диске!
Очень интересные размышления. Главное - актуальные. Предлагаю рассмотреть оба варианта, но с другой стороны. Сделать вообще распределенную систему умного дома, в которой локальные контроллеры самостоятельные единицы и не привязаны к софтверной логике, они могут работать не зависимо от локального сервера (при потере связи с ним). Локальный сервер - это больше визуализация и объединение данных + комплексное управление. Облако - в большей мере - это удалённый доступ без каких либо сокетов, которые отвечают за управление, визуализация и ограниченное управление. Как показывает практика промышленной автоматизации - лучше всего иметь распределены системы. Они как правило надёжнее и не влияют на соседние процессы. Это мои мысли, но возможно они будут полезны.
Это когда светофоры на командоаппаратах работали, а сейчас ты можешь хоть все цвета одновременно включить. Реле это хорошо, но не панацея. То-же самое и с лифтом. Несомненно, там должны быть цепи безопасности, которые заблокируют движение на уровне разрыва контакта, но если все делать по такому принципу то схема станет максимально сложной и не практичной. Вы вышедшую из строя релюху будете смену искать.
Все правильно! Для прототипирования!
Лапшу накрутили уже не французы, а наши. А европейцы, американцы и прочие всегда делают шкафы с кучей защиты, только в 99,9% случаев они не нужны, но у них такое требование.
В чем проблема помехозащищенности микроконтроллеров? Если человек напрямую тащит кнопку через перекрытия, вдоль силовых линий в порт микроконтроллера, то он по умолчанию - бездарь, а если у меня кнопка заводится через оптопару (как это делается на ПЛК, кстати), то мне вообще плевать на помехи. Что касается взаимоблокировок, так это делается ещё проще и без реле, программный код отрабатывает быстрее чем срабатывает контакт реле, а обработку дребезга кнопки так вообще без проблем. Да, я понимаю о чем вы говорите и даже частично поддерживаю, но не настолько категорично.
Какой смысл ставить промышленный ПЛК для простого проекта, брать для него модули ввода-вывода, искать программиста (именно для этого ПЛК), возможно покупать софт, а потом наполнить его банальной логикой и загрузить на 0,1% от его мощности??? Вот это то как раз и не логично! Проект, который должен быть доступным становится неприступным для людей, а потом санкции и нет возможности замены, софт не поддерживает старые ПЛК и так далее.
P. S. А табло для отражения этажей 1 или 2 сделай в виде одного 7-ми сегментного индикатора, которому при помощи диодов сформируй цифру 1 и 2. И отдавай 2 битовых сигнала с реле, от микроконтроллера, которые развязаны оптопарой. Если понимаешь о чем я...
Я так понимаю что к МК Atmega328 или 168 или 8 вопросов нет, это достаточно надёжные микроконтроллеры и вполне себе может (сам видел лично в куче датчиков и модулей промышленной автоматизации) быть использован для управления хоть лифтом, хоть самогонным аппаратом, хоть конвейером. С автором соглашусь во многих аспектах: исполнение проектов горе-ардуинщиками, когда они собирают из кучки готовых модулей проект и выглядит это как комок проводов, которые связаны в "Гордеев узел". И то, что эти-же горе-ардунщики клепают управление микроконтроллерами при помощи нейросетей. А ещё, вместо того, что бы взять более мощный МК, начинают добавлять модули расширителей входов/выходов, что тоже накладывает отпечаток. С другой стороны, если это все собрано на нормальной плате, с корректными входами и выходами, реле, расчитанные на определённые токи и так далее, а так-же отлаженный программный код, то можно сложные проекты делать и на более простых МК. Взять тот-же лифт, много ли ему нужно? 2 кнопки вызова лифта, 2 кнопки для этажей, 2 концевика и 2 реле управления контакторами двигателя (ну или УПП или ЧП), возможно ещё что-то, для лифта на 2 этажа, но это уже мелочи, 20 входов/выходов, с учётом всех датчиков безопасности, кнопок и даже подсветки, хватит с головой. Как бы логика не сложная, тут и Atmega8 справится. А что касается зависаний, то Watchdog timer никто не отменял. Просто делается программа инициализации, при которой лифт уходит на определённый этаж и там останавливается, ожидая команд. И работать это все будет без проблем. А для надёжности можно ещё один такой МК запрограммировать и положить рядом. 20 лет он точно стабильно отработает. Потом поставить второй, если будет актуально.
Из статьи и ответных комментариев делаю вывод: молодые ребята, программисты (с современным складом ума и опытом в прикладном программировании и это видно из профиля и предыдущих статей автора) , решили, что автоматизация = простое программирование и не более, решили сделать за небольшие деньги автоматизацию металлургического производства (ну это они так решили, что будут именно автоматизацию делать, а не маленький узел аналитики), используя свой небольшой опыт, не понимая суть, смысл и логику промышленной автоматизации, сделали по своему, как умели.
Да, что-то получилось и стало работать, не смотря на множество костылей и подпорок и ребята решили заявить о себе через Хабр, думая что вся автоматизация так работает и им скажут что они большие молодцы, но ребята не могли подумать, что автоматизация работает по другому и множество людей, которые годами с этим работают и знают это всё изнутри, будут не согласны с таким заявлением и прямым текстом скажут ребятам, что они в корне не правы и все, что они сделали и гордо называют автоматизацией, не является таковым. Но ребята решили доказать, что они правы и ввиду своей некомпетентности в вопросах автоматизации просто потопили себя ещё глубже...
Итог всей басни: ребята, учитесь и называйте вещи своими именами, если вам указывают на некорректность ваших заявлений, не спешите доказать что вы умнее, сначала потрудитесь выяснить, почему вам на это указали и только потом делайте выводы и пишите ответные комментарии. В мире немало умных людей, а уж на Хабре их предостаточно и здесь "раскатают" таких экспертов, как вы.
В целом, все неплохо, идеи хорошие, а реализацию до ума можно довести и вы сможете делать аналитику сложных промышленных процессов, главное вникайте в их суть. Для вас это новая сфера и отрасль и там не работают банальные принципы программирования и логика сильно другая. Там нет FrontEnd и BackEnd, там базы данных только на уровне MES систем и устроены они не по классической схеме. И так далее, это совсем другая среда. Простой прикладной программист не зайдёт сюда "с ноги" и не скажет, какой он крутой. Просто не сможет
Ребята, ну какие жы вы тогда автоматизаторы, если не можете интегрировать весы? Вот тут у меня ещё больше вопросов, причём к вашей компетенции и профессионализму. Вы сейчас пишете настолько не корректные вещи, но при этом стремитесь сказать, что не вмешиваетесь в основную инфраструктуру. А в чем тогда смысл вашей доработки - аналитика или все же автоматизация?
А что касается использования подручных средств, то и из веток можно "шалаш" собрать, но будет ли являться это промышленным объектом, вот в чем вопрос. Если бы вы написали, что сделали дополнение к существующий автоматизации, которое позволяет повысить производительность, снизить затраты и так далее, это было бы корректно, ну так вы гордо с максимализмом заявили: "Промышленная автоматизация металлургического производства. Архитектурные решения и техническая реализация" - теперь вам и пишут "коллеги", хотя я не уверен, что вы именно автоматизацией занимаетесь, что то, что вы сделали - не тянет на автоматизацию и даже к "заплатке" мало относится. Ну так вы себя дальше "закапываете", заявляя что не можете интегрировать весы и говорите про какой-то эфимерный датчик воздуха.
Вы вообще понимаете, что такое архитектура автоматизации, что лежит в её основе и как технически это все реализуется?
Плотный проект - это круто! И это несомненно будет работать, но не долго. Через небольшое время, камера покроется слоем пыли, а сетевой диск отвалится и оператор не нажмет кнопку. И так далее. В вашей модели в основе - "костыли", которые "подпирают" процесс, но не автоматизируют. Автоматизация предполагает унификацию, сокращение участков обработки информации, упрощение, отказ от промежуточных блоков обработки, что ведёт к надёжности и возможности запустить линейные и цикличные процессы в автоматическом или автоматизированном режиме (надеюсь понимаете в чем разница) и уже потом отказ от оператора или максимальное снижение зависимости от действий оператора. Не просто так учат в университетах отдельно на промышленную автоматизацию и там нет Pyton, потому что он там не нужен (медленно и не надёжно, требует больших ресурсов для вычисления, что недопустимо для процессов). То, что вы сделали подходит для проведения исследований и переноса этого алгоритма на автоматизацию через ПЛК.
А в чем проблема использовать конвейерные весы? Зачем делать такой сложный механизм анализа? В производстве, если вы делаете высокую точность, 1 минута - это очень много. PID регуляторы отрабатывают порой миллисекунды и крутятся на ПЛК. Да, возможно я не понял суть задачи и мы делали что-то похожее, но так или иначе потом переносили софтовые решения на железо. Иметь кусок программы (для управления, а не для статистики и анализа) в производственном цикле - это огромный риск. Но, если описанный технологический процесс не имел вообще никакой автоматизации, то да, временно, таким сложным, софтовым решением можно закрыть эту "дыру".
Я просто не понимаю, как микросервисы, web и Pyton ассоциируются с надёжностью, доступностью, отказоустойчивостью на уровне промышленной автоматизации? А уж тем более файлы на сетевом диске!
Понравился фрагмент "Раньше тела из самолётов просто сбрасывали наружу", понимаю что очепятка, но улыбнуло.
Очень интересные размышления. Главное - актуальные. Предлагаю рассмотреть оба варианта, но с другой стороны. Сделать вообще распределенную систему умного дома, в которой локальные контроллеры самостоятельные единицы и не привязаны к софтверной логике, они могут работать не зависимо от локального сервера (при потере связи с ним). Локальный сервер - это больше визуализация и объединение данных + комплексное управление. Облако - в большей мере - это удалённый доступ без каких либо сокетов, которые отвечают за управление, визуализация и ограниченное управление. Как показывает практика промышленной автоматизации - лучше всего иметь распределены системы. Они как правило надёжнее и не влияют на соседние процессы. Это мои мысли, но возможно они будут полезны.