Mitsubishi FX, связь с верхним уровнем

Сообщение **keysansa** » 25 фев 2019, 10:43

Прочитав этот пост, вспомнился печальный опыт с Mitsu.
Задача была следующей.
Организовать управление системой, состоящей из более чем 400 DI/DO (часть из них опрашивалась FX2N через RS485 c IPC DAS).
ТЗ было построено так, что верхний уровень - "отображометр" и хранилище параметров и результатов работы. Причем необходимо было обеспечить работу системы при выходе из строя верхнего уровня.

Из интерфейсов - только RS485, причем, если все правильно помню, 38400bps

Ресурсов контроллера хватало за глаза, но вот передача информации на верхний уровень и из него - приводила к задержкам интерфейса 2-6 сек.

Оптимизировали все что можно. Вплоть до того, что каждый из >200 параметров отслеживался на изменение и передавался либо по старту (тут вообще около 30 сек все зависало, но это как раз не критично), либо по изменению. Задания/Состояния - все сгруппировано в слова.

Как азиаты из этой ситуации, чисто теоретически, выкручиваются?

Сообщение **Ryzhij** » 25 фев 2019, 12:53

Вообще, тут либо используются проприетарные протоколы, в которых клиентом является верхний уровень, либо ставят модуль связи со стандартным протоколом.
Кроме того, из сообщения неясно, где "затыкалась" передача, на участке "FX2N - IPC_DAS" или "FX2N - HMI"?
Может, там из всех доступных OPC-серверов для связи выбрали Лектус ;)

Сообщение **keysansa** » 25 фев 2019, 13:02

"Затыкалась" - FX2N-HMI. Если точнее - "задерживалась"
Там был и TraceMode, и Intouch.
Самый быстродейструющим в итоге стал TraceMode с нашей t13 библиотекой обмена (по поприетарному протоколу), со всеми оптимизациями.
ЗЫ. OPC - перепробовали все что нашли.

Сообщение **Ryzhij** » 25 фев 2019, 13:20

Из "вменяемых" OPC с нормальными драйверами для Мицубиши знаю два (Keepware и Bejer OPC) и слышал о третьем (Matrikon OPC).
О TraceMoude и "дружбе" InTouch с OPC тактично промолчу, чтобы не холиварить.

Сообщение **keysansa** » 25 фев 2019, 13:26

Ryzhij писал(а): ↑25 фев 2019, 13:20 Keepware и Bejer OPC

Спасибо, почитаю!

Если обменивались через круглый разъём, то там скорость либо 9600, либо 115200. 38400 может быть, если это адаптер расширения. Передача 400 параметров это около 1кБ данных или 10кбит. Вот и считайте. И это ещё если данные для передачи выстроены подряд в памяти. Использование вашей библиотеки - это значит MC протокол. Если бы использовался родной OPC, то был бы MELSEC протокол. Не помню как для FX, но вот для Q MELSEC c OPC намного эффективнее, чем MC, поскольку поддерживает передачу по изменению. У FX2N был FX2NC-ENET-ADP адаптер - Ethernet модуль для связи с верхнем уровням. Он бы тоже мог решить все проблемы. В общем варианты есть. А так: какое-то было применено странное решение, как-то очень изначально не продуманное / просчитанное, из которого пытались выжать, то на что оно не рассчитано.

Сообщение **keysansa** » 25 фев 2019, 14:28

alex_ugrumov писал(а): ↑25 фев 2019, 14:14 Если обменивались через круглый разъём, то там скорость либо 9600, либо 115200.

Родные, да 9600 и 19200

Отправлено спустя 5 минут 24 секунды:

alex_ugrumov писал(а): ↑25 фев 2019, 14:14 для Q MELSEC c OPC

Это бюджет совсем другой. В оправдашки к старту темы могу сказать, что с Азии Q серия не приезжает. Видел Немецкий проект на Q Serie, причем очень древний.

alex_ugrumov писал(а): ↑25 фев 2019, 14:14 У FX2N был FX2NC-ENET-ADP адаптер - Ethernet модуль

Этот видел только у FX3U. И он тоже не решил (был контроллер с модулем на другой проект). Задержки меньше, но так же критичные.

Отправлено спустя 10 минут 4 секунды:

alex_ugrumov писал(а): ↑25 фев 2019, 14:14 А так: какое-то было применено странное решение, как-то очень изначально не продуманное / просчитанное, из которого пытались выжать, то на что оно не рассчитано.

У заказчика все на Mtsu (контроллеры, привода). И ему не нужны траты на обучение, и мы "умели" FX. Просто попытались сделать все в 1. И угодить, и победить. Победить не удалось, 2-6 сек так и осталось.

Вопрос был больше про то, как Азиаты это преодолевают, раз они на Mitsu (самые плохие объекты - с момента запуска - 5, 6 лет - ни копейки на обслуживании не заработали )) ).

Сообщение **Serex** » 26 фев 2019, 06:37

Думаю просто принимают как данность. У нас порядка 5 разных проектов Pro-face + Mitsu Q-system. Ни в одном проекте нет трендов, архивов. Т.е. циклический опрос всех переменных отсутствует. Только те, что на экране и алармы. Работает хорошо. Вот почему они тренды не делают :)

Сообщение **keysansa** » 01 мар 2019, 21:18

Serex писал(а): ↑26 фев 2019, 06:37 Ни в одном проекте нет трендов, архивов.

Это про Q-Serie...
В FX - это "аще жуть".

ЗЫ. Не в тему Mitsubishi, но по трендам, B&R - сами умеют получать/складывать данные из/на MS SQL сервер прямо контроллером. Sie 300/1200 - только через HMI, скриптами.