ПЛК150+VLT2800+FC202+....

[BROMBA]

Проблема вот в чем:
Есть стандартный набор ПЛК150ИМ+2хМВА8+МДВВ+ИП320, работающий по протоколу modbus-RTU; работающий практически идеально.
Есть набор ПЛК150ИМ+VLT2875, работающий по протоколу modbus-RTU; работающий практически идеально.
При подключении VLT2875 к набору ПЛК150ИМ+МВА8+МДВВ+ИП320 происходит следующее: значения, читаемые из четных/нечетных регистров (как в частотнике, так и в МВА8) меняются местами, и получается полная каша.
Еще момент: нормальная работа ИП320 (8 экранов ввода/вывода) в составе набора ПЛК150ИМ+МВА8+МДВВ+ИП320 возможна исключительно через RS232; наличие/отсутствие в комплекте ИП320 на работу влияния не оказывает; отключение МВА8 от RS485 приводит к нормализации работы с частотником, отключение частотника приводит к нормализации работы комплекта.
Есть какие-нить соображения по этому поводу?

[ASo]

Проверьте пересечение адресов приборов.
Напомню, что МВА, МДВВ занимают несколько адресов подряд.

[Gans]

Здравствуйте BROMBA - Для облегчения диагностики неисправности укажите прошивку на МВА8.

В ходе копания с мва8, обнаружил некоторый мусор генерящийся с мва8 после его опроса. Полеты продолжаются 2..4мс.
С другими приборами, вкл. мдвв, такого не обнаружил

Всегда считал МВА8 беспроблемным, а тут такое Осталось выслушать мнение официальных представителей.
P. S. Не че себе Валенок зоркий, а я в этом месте не стал разбираться и ушел на протокол ОВЕН и больше с подобными глюками не сталкивался. К тому же грешил на ПЛК1хх.

[BROMBA]

Проверьте пересечение адресов приборов.
Напомню, что МВА, МДВВ занимают несколько адресов подряд.

Уже смешно...
Ну, ладно, МВА8№1 - 64, МВА8№2 - 72, МДВВ - 96, VLT2875 - шо 1, шо 128 - всё едино...

?????
Модбас-RTU. Адреса приборов - по барабану. Кроме совпадения.

Т.к. штатного мастера не использую, в ходе копания с мва8, обнаружил некоторый мусор генерящийся с мва8 после его опроса. Полеты продолжаются 2..4мс.
С другими приборами, вкл. мдвв, такого не обнаружил

Т.к. для себя данную проблему решил, никаких проблем опроса любых комбанаций выше перечисленного не имею

Позвольте поинтересовацца - как?
С другой стороны - в понедельник на стенде проверим, что да как; товарищ сниффер обязательно что-нить, да покажет. Как показал таки в своё время наличие ответа от МВА с кодом ошибки по таймаутам перед нормальным откликом с пакетами данных, при одном МВА, подоткнутом к ПЛК; подобный бред наблюдаецца обычно при попытке чтения несуществующих регистров.

[BROMBA]

Здравствуйте BROMBA - Для облегчения диагностики неисправности укажите прошивку на МВА8.

Всегда считал МВА8 беспроблемным, а тут такое Осталось выслушать мнение официальных представителей.
P. S. Не че себе Валенок зоркий, а я в этом месте не стал разбираться и ушел на протокол ОВЕН и больше с подобными глюками не сталкивался. К тому же грешил на ПЛК1хх.

Хммм... рады бы, да не можем - частотники, знаете ли, не понимают протокола Овен; ИП320, впрочем, тоже... Только modbus-RTU, шаг вправо-влево чреват боком ...
А Овен и Модбас в одном порту почему-то не уживаюцца, - приходицца разносить по разным портам...
Да, чуть не забыли - 7.5, если шо...

Хотя... если производители напишут шалбон, тьфу, шаблон на свой ПЧВ, тогда будет всеобщее щастье и благорастворение воздусей...

[BROMBA]

Мои вопросы оставшиеся без ответов: http://www.owen.ru/forum/showthread.php?t=10499

Кстате, подобненькая задачка и тупейший способ ее решения: объектовые средства связи - USB-шные 3G модемы, воткнутые в роутеры "Тенда" с вайфаём... если диспетчерский сервак не опрашивает объекты в течении 6 часов, модемы на объектах "засыпают" (этих китайских "зелёных" с их неотключаемой функцией энергосбережения, взять бы, и покарать анально, жестоко и беспощадно), и диспетчерская может их "пробудить" пингованием в одном случае из трех. Решение такое - в контроллер допилена подпрограммка, раз в 3 часа, через релюшку "передергивающая" модем/роутер по питанию. Да, тупо, да, некошерно, но шопаделать , работать-то как-то надо...

[BROMBA]

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

Syslibcom. Ну а дальше немного фантазии.

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

Благодарствуйте премного... сами б не обратили вниманья...

[BROMBA]

Типа да. Если достаточно грамотно сделаете - будет быстрее штатного мастера. Для всех слейвов. И МДВВ.

Легко сказать - "грамотно"... а, впрочем, какая разница, - ком-порт это всего лишь ком-порт...

Про нее можно забыть. В смысле организации обмена.

Это не может не радовать. Чего-то подобного и следовало ожидать...

будет, скорее, со штатным, чем с со своим.
Лично я в этом уверен, потому что лично использую своего мастера.

Вот интересно, мастер лучше писать для всех подключаемых железяк, не важно каких, или логичнее для каждой свой? И вызывать его вместе с подпрограммой или функциональным модулем: - например, термодатчики имеет смысл опрашивать раз в десять секунд, а значит, и опрос МВА делать с соответсвующей периодичностью; частотники опрашивать раз в полсекунды, а кормить командами каждые двести миллисекунд... ну, типо того...
А вобщем, идея понравилась, и даже очень. Будем посмотреть.

[Gans]

Но как тогда быть с МДВВ - для решения практических задач недопустимо даже кратковременное прерывание замкнутых контактов релюшек.

Считывать из МДВВ значения счетчиков и сравнивать с предыдущими значениями - таким образом ни чего не проспите :-)

[BROMBA]

Считывать из МДВВ значения счетчиков и сравнивать с предыдущими значениями - таким образом ни чего не проспите :-)

Речь не о входах, (программно все эти дребезги и прочие помехи легко выкусываются), а о выходах: при прерывании связи (по разным причинам) МДВВ светит сигнал "авария" и "роняет" выходы; использовать аварийные состояния нельзя - спонтанный запуск частотника двигателя может оторвать руки-ноги слесарю; прерывание сигнала "старт (или, что намного хуже -stop coasting inverted)" тоже недопустимо - частотник "сваливается" в режим "автоподхвата" двигателя, и не всегда может "подхватить" агрегат в режиме автоматического регулирования, со всеми вытекающими... решение этих негараздов пока простое и тупое до безобразия - максимально увеличить скорость обмена с МДВВ, и отдать модулю управления выходами высший приоритет - тогда всё работает практически идеально.
Второй вариант, в данное время проходящий обкатку - отказ от аналогово-контакторного управления частотниками, и подключение их через модбас; тогда весь этот релейно-контакторный хлам демонтируецца, экранированные кабельные трассы отдаюцца под датчики, им нужнее, а частотники попадают под тотальный контроль (при этом можно демонтировать часть датчиков, защитных устройств и прочих контрольноизмерительных приблуд - частотники сами могут выполнять их функции), тем более, что появляется возможность динамического управления встроенными SLC, что не может не радовать...