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

[ASo]

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

[BROMBA]

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

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

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

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

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

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

[Gans]

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

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

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

[BROMBA]

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

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

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

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

[BROMBA]

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

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

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

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

[Gans]

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

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

[BROMBA]

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

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

[BETEP]

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

Хватает противников у этого способа.

А ещё получите возможность использовать частотник как модуль ввода вывода, несколько дискретных, парочка аналоговых, а на некоторых кол-во I/O и расширить можно.

[BROMBA]

Фигня. Переход в аварийное состояние - отсутствие обмена вообще. чтение, запись - без разницы. Видимо это Gans и имел ввиду - входы читаем постояно, выходы пишем по необходимости. И будет счастье.

Нет в лайфе кайфа, хоть фейсом ап тейбл... и не будет... почему? Чутка опозжа...

Как-то странно железо поставили. Обрыв связи приводит к запуску ?
Или пуск просходит без анализа текущего состояния связи ?

Я для МДВВ ставлю аварийное время выставляю в 1..2 сек.

Таки да, странно, потому, что приходилось не монтировать всё с нуля, а врезацца в существующие схемы, ибо хотелки заказчика - закон: из экономии (тут должны быть матюки) на один частотник вешаются 2,3,4 насоса через релейно-контакторную схему ("а вдруг частотник ваш сдохнет, а шо тогда"(С)), и миллисекундный сбой по выходу приводит к отпаданию контактора, (или, что еще веселее, к его "жужжанию"), а запуск привода происходит откуда? Правильно, с блок-контактов, ибо заказчик так милостиво повелеть соизволил. Без возможности перехода на "старую схему" с ручным управлением заказчику по-прежнему очччень сцыкотно, хотя частотники безаварийно молотят там уже по 8...9 лет. Посему, не так страшнО отключение по аварии МДВВ, как соббсна, восстановление связи, ибо за ним следует "бум" контактора, и запуск привода. Проходили уже вот это самое "1...2 сек" - фигня полная...
Вот почему очень, очень хочецца от этого хлама поскорее избавицца...

[BROMBA]

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

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

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

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

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

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