[skv8016 0]

7 hours ago, AlexandrY said:

Для ПЛК оставьте место в ящиках.  
Они хоть и надежные, но медленные,  слишком прожорливые и слишком габаритные.
Именно с фантазией там не разгуляешься. Сами же сказали что не видите особо хитрых алгоритмов для них. 
Потому что вы скованы их ограниченными IDE,  рамками RT движков и закостеневшими нотациями.

Медленные для чего? Для синхронного подрыва зарядов в ядреной бомбе? Или для реакции на действия человека. 

Мне пока не довелось упираться в не решаемую задачу. А фантазии необходимо укладывать в рамки разумного, иначе потребитель вас не поймет. К тому же я опираюсь на фантазии заказчика

Теперь понятно почему вы так быстро меняете архитектуры. А у меня есть товарищ, который до сих пор делает регуляторы для контактной сварки на атмегах и не желает ничего менять, т.к. скорости хватает. Но у него есть устройства и на линухе. Где необходимо- там быстро, где хватает - там надёжней.

[mantech 34]

2 часа назад, skv8016 сказал:

Теперь понятно почему вы так быстро меняете архитектуры. А у меня есть товарищ, который до сих пор делает регуляторы для контактной сварки на атмегах и не желает ничего менять, т.к. скорости хватает.

Абсолютно здравый подход, зачем что-то менять, если все прекрасно и стабильно работает. Но вас сейчас обвинят в старомодности, олдскуле и пр...

Изменено 18 сентября, 2020 пользователем mantech

[haker_fox 60]

2 hours ago, skv8016 said:

и не желает ничего менять

Я вас понимаю. Но это тоже тупиковый путь)

[AlexandrY 3]

2 hours ago, skv8016 said:

Медленные для чего? Для синхронного подрыва зарядов в ядреной бомбе? Или для реакции на действия человека. 

Сделайте например на кнопке дешифратор азбуки Морзе, а потом мультиплицируйте его на 40 кнопок и несколько каплеров по TCP  Modbus.
И сразу почувствуете тормоза.
Не, ну конечно можно поставить ПЛК c атомных станций исказать, что нет ничего нереализуемого на ПЛК.
Но на самом деле те дешевые ПЛК из умных домов  действительно заточены на узкий круг  функциональностей.
Есть конечно возможность туда всунуть линуксовый  докер и всякие облачные технологии, но они с подсистемой физических входов-выходов будут общаться все через тот-же заторможенный основным приложением RT движок, причем через межзадачный внутренний TCP/IP канал.   
Словом ПЛК в некторых случаях хуже костылей, но надо глубоко разбираться. 

[mantech 34]

4 часа назад, AlexandrY сказал:

Сделайте например на кнопке дешифратор азбуки Морзе, а потом мультиплицируйте его на 40 кнопок и несколько каплеров по TCP  Modbus.

Сразу видно - у человека полно свободного времени

4 часа назад, AlexandrY сказал:

но они с подсистемой физических входов-выходов будут общаться все через тот-же заторможенный основным приложением RT движок,

Вы можете конкретно сослаться на пример, когда быстродействия не хватает, только без бреда про кнопки Морзе?

По вашей аналогии я тоже могу придумать управление яркостью напрямую управляя затвором полевика с I\O выхода контроллера, вопрос только один - нафига...

Изменено 18 сентября, 2020 пользователем mantech

[AlexandrY 3]

1 hour ago, mantech said:

Вы можете конкретно сослаться на пример, когда быстродействия не хватает,

На самом деле мои кнопки могут отслеживать больше градаций длительностей нажатия чем требуется для Морзе. 
Не нравится Морзе, назовите это декодер ввода. Факт в том что сложные декодеры и парсеры тормозят в ПЛК.
Не нравяться парсеры, возьмите алгоритмы требующие поиска или сортировки  или итеративные алгоритмы поиска оптимума, или корреляционные.

Хороший пример - алгоритмы управления гибридными системами зеленых источников энергии. 

[skv8016 0]

6 hours ago, haker_fox said:

Я вас понимаю. Но это тоже тупиковый путь)

Отнюдь. Человек использует разные архитектуры для разных задач. Текущая задача решена на атмеге и вылизана за много лет и зачем что-то менять не ясно.

[skv8016 0]

32 minutes ago, AlexandrY said:

На самом деле мои кнопки могут отслеживать больше градаций длительностей нажатия чем требуется для Морзе. 
Не нравится Морзе, назовите это декодер ввода. Факт в том что сложные декодеры и парсеры тормозят в ПЛК.
Не нравяться парсеры, возьмите алгоритмы требующие поиска или сортировки  или итеративные алгоритмы поиска оптимума, или корреляционные.

Хороший пример - алгоритмы управления гибридными системами зеленых источников энергии. 

Простите за прямоту, но хотелось бы поинтересоваться, чего вы такого забористого употребляете? Вы вообще знакомы с подходами используемыми в реальных системах? Градации нажатия кнопок по длительности делаются в несколько строчек или блоков без всяких проблем, что такое "больше"? Вы про аглицкий термин "юзабилити" слышали? Куда мне использовать Морзе? Фиксировать топотание юзера на горшке что-ли? Даже двойные нажатия на кнопку это зло. Слово "тормозят" необходимо сопоставлять с допустимым временем реакции: если рулить температурой в помещении, достаточно реагировать в течение 5 минут, а если рулить механизмом, движущимся со скоростью 10 мм/с, то вполне хватает реакции 10-20 мс. Для особых случаев есть прерывания, которые обрабатываются за 1-2 мс на самых захудалых контроллерах. Отработку аварий для быстрых и критических систем никто ПЛК не доверяет полностью

Алгоритмы поиска и сортировки не всегда крутятся непрерывно. Поиски оптимума и корреляции вполне реализуемы, но только это не всегда необходимо, я по крайней мере пока не понимаю зачем мне корреляция, а оптимумы обычно подбирают во время наладки. И регулятор с наблюдателем на фильтре Калмана можно, если нужно, и даже на не самых быстрых ПЛК из бюджетных серий.

У меня сейчас в работе машина с 4-мя сервоприводами с управлением по A/B и обратной связью по A/B и лазерным слежением с медианной фильтрацией  показаний датчика по четырем точкам, обменом по eth с панелью оператора, станцией ввода-вывода и стойкой со СКАДА(в обмене под сотню переменных по 16-32 бит) и реализованы алгоритмы слежения с запоминанием траектории и многое-многое другое. И все это укладывается в 10 мс на ПЛК s7-1200(устроило бы и 100-200) - это долго и тормозит? А еще была реализована машина с 5-ю приводами, вращающимися синхронно и не очень, под сотню входов-выходов, панелью оператора, кучей кнопок и датчиков, но на слабеньком ПЛК DVP от Delta(там внутри вообще stm32f103 стоит) - вот тут ПЛК слабоват оказался, время реакции получилось около 30-40 мс

Открою для вас маленький секрет: есть ПЛК общепромышленные(универсальные), а есть специализированные. К специализированным например относятся контроллеры управления движением(пару-тройку десятков осей за 1мс хватит?) или отдельный мир контроллеров для BMS(это где протоколы типа BACnet рулят). А для зеленых энергетиков есть свое. На универсальном реализуется почти все, но не всегда оптимально или ценой бОльших усилий.

 

[AlexandrY 3]

46 minutes ago, skv8016 said:

Отнюдь. Человек использует разные архитектуры для разных задач. Текущая задача решена на атмеге и вылизана за много лет и зачем что-то менять не ясно.

Да не бывает такого.
Ничего он не вылизывал. После линукса совершенно не до вылизываний.
Линукс приучает смотреть на баги сквозь пальцы, как на неизбежное зло. 
Поэтому если чел попробовал линукс, то он больше уже ничего не вылизывает. 
Либо наоброт. Он перешел на линукс поскольку никогда ничего не вылизывал. 

Как то так.  

[mantech 34]

3 минуты назад, skv8016 сказал:

Простите за прямоту, но хотелось бы поинтересоваться, чего вы такого забористого употребляете?

Мне тоже интересно

2 минуты назад, AlexandrY сказал:

После линукса совершенно не до вылизываний.

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

6 минут назад, AlexandrY сказал:

Как то так

Точнее не скажешь

8 минут назад, skv8016 сказал:

А еще была реализована машина с 5-ю приводами, вращающимися синхронно и не очень, под сотню входов-выходов, панелью оператора, кучей кнопок и датчиков, но на слабеньком ПЛК DVP от Delta(там внутри вообще stm32f103 стоит) - вот тут ПЛК слабоват оказался, время реакции получилось около 30-40 мс

В таком случае можно это сделать на МК с программой на Си, вывести на какой-нибудь стандартный интерфейс и подключить уже к системе управления...

[AlexandrY 3]

6 minutes ago, skv8016 said:

Открою для вас маленький секрет: есть ПЛК общепромышленные(универсальные), а есть специализированные. К специализированным например относятся контроллеры управления движением(пару-тройку десятков осей за 1мс хватит?) или отдельный мир контроллеров для BMS(это где протоколы типа BACnet рулят). А для зеленых энергетиков есть свое. На универсальном реализуется почти все, но не всегда оптимально или ценой бОльших усилий.

Спасибо Кэп, я прям не знал о таком. 
Только я говорю не про сотню датчиков,  а про сотню стэйт машин  в одной задаче. Т.е не десяток осей, а сотня в ваших терминах. 
Про контроллеры с Ethercat это к  siomа.  
Вообще детям понятно, что если в контроллере написана поддержка 1000 точек вводы вывода за 1 мс., то он честно их и примет-отправит. 
Но это ничего не говорит о том какой сложности алгоритмы он успеет с этими точками произвести. 
Так что не трясите воздух. 

[skv8016 0]

3 hours ago, AlexandrY said:

Да не бывает такого.
Ничего он не вылизывал. После линукса совершенно не до вылизываний.
Линукс приучает смотреть на баги сквозь пальцы, как на неизбежное зло. 
Поэтому если чел попробовал линукс, то он больше уже ничего не вылизывает. 
Либо наоброт. Он перешел на линукс поскольку никогда ничего не вылизывал. 

Как то так.  

А вы это у кого прочитали? Линукс был использован в устройствах для регистрации процессов, где без него просто неудобно и долго в реализации. А в остальном...вы знаете, бывает. Это про серийные изделия с историей около 15 лет. Вылизано всё, ресурсы использованы по максимуму. В вашем мире голубых океанов это не допустимо: надо быть на гребне волны и прыгать с платформы на платформу.

 

3 hours ago, mantech said:

В таком случае можно это сделать на МК с программой на Си, вывести на какой-нибудь стандартный интерфейс и подключить уже к системе управления

А зачем? Я занимаюсь автоматизацией, некоторые заказы делаются за несколько дней, какие-то могут тянуться несколько лет. Объем контроллеров мизерный и разработка себя никогда не окупит, а сроки сдачи станут не приемлемы. Сейчас есть из чего выбрать и по гибкости я мало ограничен. К тому же, в процессе наладки новой машины, часто возникает необходимость что-то добавить или поменять. Боюсь, что все сведётся к разработке того, от чего уходим: к ПЛК с модулями расширения

[mantech 34]

19 минут назад, skv8016 сказал:

Боюсь, что все сведётся к разработке того, от чего уходим: к ПЛК с модулями расширения

А чем такое решение плохо? Или я что-то упустил?

[skv8016 0]

8 minutes ago, mantech said:

А чем такое решение плохо? Или я что-то упустил?

Имел ввиду, что незачем и некогда разрабатывать что-то свое, когда всё реализуется на уже готовом оборудовании. И не всё удобно отлаживать на Си и других текстовых языках. На LD отладка легче и быстрее

[syoma 1]

On 9/18/2020 at 7:53 PM, mantech said:

А чем такое решение плохо? Или я что-то упустил?

Я тоже не понял, но потом прошел по вашему предыдущему сообщению. Вы написали:

Quote

 

On 9/18/2020 at 4:10 PM, skv8016 said:

А еще была реализована машина с 5-ю приводами, вращающимися синхронно и не очень, под сотню входов-выходов, панелью оператора, кучей кнопок и датчиков, но на слабеньком ПЛК DVP от Delta(там внутри вообще stm32f103 стоит) - вот тут ПЛК слабоват оказался, время реакции получилось около 30-40 мс

В таком случае можно это сделать на МК с программой на Си, вывести на какой-нибудь стандартный интерфейс и подключить уже к системе управления...

Я так понял, что в этом случае разрабатывать железяку и софт на основе МК в единичном экземпляре имело бы мало смысла.

Хотя тут, как и AlexandrY, предложу альтернативу между МК и ПЛК. Называется автоматическая генерация кода.

То есть проблема ПЛК в том, что это практически интерпретатор с языков IEC61131, да еще и с весьма медленной RTOS, которая забирает полно ресурсов для отладки, визуализации и поддержки всяческих стеков коммуникационных протоколов. В то же время часто требуется замутить быстро реал-таймовое управление на 32-х разрядном МК с хорошим быстродействием и ограниченным количеством I/O и интерфейсов. То есть прога должна быть на Си, но времени ее писать и отлаживать нет.

Что предлагает Mathworks/Matlab? Рисуете и отлаживаете свой алгоритм управления в Simulink/Stateflow. Вы это делаете путем моделирования, так как в реальной железяке с этим будут проблемы. А затем экспортируете свой алгоритм как Си код, который вы можете встроить в свой МК. Практически каждый сегодня имеет свою отлаженную МК платформу, которой просто не хватает новой проги. Вот туда его и можно встроить. Причем Матлаб сразу предлагает свой шедулер без ОСРВ, а можно и выбрать уже у вас имеющийся. Если нет коммуникационных стеков, то Матлаб предлагает простейшие UART, Modbus и прочие, которые тоже работают напрямую из вашего алгоритма. То есть вы можете запилить полностью функционирующую реалтаймовую прогу на МК платформе за считанные часы - всякие АтМеги и Ардуины полностью поддерживаются. При этом это будет уже production-ready код, который даже может соответствовать всяким Safety и MISRA стандартам, путем выбора соответствующих галочек. То есть при желании говнокода там почти не будет, и проверить вы это сможете открыв сгенерированный Си файл.  Вам остается только разработать/выбрать/достать подходящее по требованиям железо.

Получается быстро и качественно, только затратно по средствам разработки.

ПС Тема плавно переходит в Вопросы системного уровня проектирования, где эти вопросы обсуждались не раз.