Хоть 10 штук, порты разные на slave выставьте и всё. При этом порты мастера вообще не причём и могут совпадать с портами slave.
P.S. Теоретически ПЛК может сам себя опрашивать так, но я не пробовал
Вид для печати
Хоть 10 штук, порты разные на slave выставьте и всё. При этом порты мастера вообще не причём и могут совпадать с портами slave.
P.S. Теоретически ПЛК может сам себя опрашивать так, но я не пробовал
Вот это http://atrium-tr.ru/products/privody...ty-tipa-pem-10 подключить получится?
Или умощнитель ваять?
нет там аккумулятора
О том, что в новом ПЛК100 нет аккумулятора, я узнал немного раньше, поэтому и хочу его применить,
вопрос в том, что смогу ли.
PS. Батарейки, которые ставят на заводе, тоже г. Я в этом году ставил 9 шт. СПК105, во всех они были разряжены, пришлось покупать в магазине.
Андрей, у Вас какие-то ужасные условия.
У меня ПЛК с Акб минимум 3 года без проблем все отрабатывали.
СПК меня не зацепил, но в инж образце ПЛК АКБ 2-й год живет.
Я кстати писал про ПЛК 1998г, в которых АКБ все живы...!
1- мы немного ушли от темы, я спрашивал про новый ПЛК,
2- в инженерном образце нет аккумулятора, там батарейка, и ставили ее не на заводе.
3- надежность аккумулятора на форуме обсуждалась. Срок жизни системы автоматизации должен быть равен сроку жизни технологического оборудования,
а это не менее 15 лет, а обычно 30 и более, если какие-то компоненты не отвечают этому требованию, они должны меняться без проблем.
В старом ПЛК с этим никак, поэтому я не хочу его применять.
А в чем в итоге вопрос?
Там не аккумулятор, там стандартная батарейка Lir. Ставим мы их на заводе при производстве ПЛК. Ставим из упаковок (покупаются не по 10 штук).
При н\у должны проработать не менее 5 лет.
О. Точно. Прошу прощения - отвлекся на ответ Сергея.
Завтра будет принято решение. Постараемся к марту - апрелю сделать все модификации М02. Тогда ни одна М01 до этого времени не появится.
Точно ответить можно будет только завтра вечером.
сегодня уже "после завтра".... нужен ПЛК110-60К 400 МГц !!!!!
С М01 все так.
М02 - добавляются программные фичи. В принципе я на вебинаре прям даже сводную табличку делал.
GPRS\ppp, 100% поддержка архивирования на USB и т.д.
С запросами на тестирование вышла заминка. Наша ошибка. Приношу извинения. Пришлите мне в личку или на почту Ваши данные.
Выложите где-нибудь. У меня в то время интернет сдох на всём предприятии.:(
М02 из М01 делается сменой прошивки контроллера, правильно понимаю?
1) совместимость обновлённого ПЛК со старым по программному обеспечению - Управляющая программа для старой модели в новом ПЛК будет работать без внесения изменений? (Кнопочки F1&старт/стоп не рассматриваем, таргет тоже).
2) совместимость по выводам - порядок не меняли? изменений не вносили? Т.Е. можно тупо прошить и воткнуть на место старого ПЛК, просто выдернув контактные планки и вставив их в новый без перемонтажа?
3) если ответы на предыдущие вопросы положительные, то когда можно будет купить?
Выхода не меняли
Таргет другой но минимальные изменения
Программа в основном не меняется, исключение сокеты - более полная реализация, например работает функция accept как в описании стандартных сокетов.
Владислав, Вы не могли бы прокомментировать, пожалуйста:
http://www.owen.ru/forum/showthread....l=1#post160512
Цитата:
Подскажите, пожалуйста. Столкнулся со странной проблемой:
Скада в режиме исполнения, идёт интенсивный обмен данными с контроллером (ОВЕН ПЛК-110 new) через MASTER-OPC Server. Контроллер TCP-мастер (объявлен в конфигурации) - OPC-сервер соответственно TCP-slave. Имитирую разрыв связи методом отключения кабеля ethernet от контроллера, затем через некоторое время подключаю обратно (интенсивный обмен за это время заканчивается). Соединение восстанавливается, данные текущие приходят корректно, однако через несколько секунд по некоторым тегам (которые активно менялись) несколько раз приходят ложные данные, затем всё становится нормально ( у меня картинка с динамизацией положения "левый" начинает прыгать, в визуализации CDS эта же картинка, привязанная к этой же переменной в этот момент не прыгает). В логе обмена OPC-сервера действительно присутствуют эти ложные значения как принятые, однако я параллельно открываю CDS смотрю переменные конфигурации в режиме online и не вижу изменений на борту контроллера. Такое ощущение, что приходят значения, которые принимал тэг во время разрыва... Подскажите, пожалуйста с чем это может быть связано?
Такое ощущение, что приходят значения, которые принимал тэг во время разрыва... Подскажите, пожалуйста с чем это может быть связано? - Если TCP-slave не игнорирует значения из предыдущей сессии - такое поведение возможно, я думаю. Но почему slave не игнорирует данные? Свяжитесь с разработчиком OPC
Два вопроса:
1. Когда в продаже появятся новые ПЛК110-60К?
2. Будет ли работать в нем одновременно ABZ-энкодер и высокоскоростной (аппаратный?)счетчик?
Пункт 2. Да
Владислав, я снова к Вам :)
Прокомментируйте, пожалуйста.
Вложение 16583Цитата:
Во вложении скриншот ситуации, которая меня беспокоит. Это происходит после физического разрыва соединения. Стрелками отмечены связанные тэги. Реальное значение = 1077 не меняется в контроллере, а в сервере вижу ложные значения. Судя по логу сервер эти ложные значения честно получает. Чрез несколько секунд значение в сервере восстановится. Кто же всё-таки виноват- контроллер, который почему-то генерит неправильное сообщение, или сервер, который не должен это сообщение принимать?
Параметры мастера:
Вложение 16584
оригинал
так мы не выясним причин. Надо:
1. Сделать значение, которое выдаёт ПЛК константным и сымитировать обрыв.
2. Значение 7067 вообще бывает на выходе ПЛК?
3. Ну и обязательно нужен снифер чтобы посмотреть на трафик.
1. Хорошо, попробую, но для себя я исключил ситуацию, когда значение в контроллере действительно прыгало, уже по скриншоту видно, что есть рассинхронизация. Обратите внимание, что режим работы у мастера - "both", то есть и пойлинг и по изменению, стало быть значение должно было синхронизироваться быстро и я не успел бы сделать скриншот...
2. Не совсем понял вопрос. Это один из параметров, который программно рассчитывается на борту ПЛК для имитации физического состояния объекта... Может принимать вобщем-то любые значения из диапазона типа типа DWORD.
3. :) Я так и знал...
если ПЛК генерит число 5 а в скаде 7067 - это одно.
Если же ПЛК генерил число 7067 - то это другое.
И таки да, снифер нужен :D
Итак, прикладываю лог сниффера.
20:25:38 - разрыв, через несколько секунд соединение.
нормальное значение - 1077
плохое значение - 3151, зафиксировано 20:25:53..54
адрес тэга - 6
(значение константой пока не делал, но после восстановления связи значение уже не меняется, до и частично во время разрыва - меняется раз в 100 ms.)
не прочитал лог, что там по первым двум байтам запроса, последовательность не нарушена когда появилось неправильное значение
Что видно по логу - сначала идёт транзакция по 6 unit, к-я обрывается. и она передаёт число близкое к 3190.
Далее идёт пауза, возобновление транзакции и 1 раз значение 1077, а затем опять близкое к 3190.
Вот по этому я и предлагаю Вам сделать число константным и оборвать связь. Если число поменяется - то проблема в ПЛК, если нет - данные меняются по какой-либо причине в момент обрыва.
P.S. Как я понял у Вас одновременно на ПЛК и на ПК и мастер и slave?
Хорошо, я проведу эксперимент с константой. Хотя мне кажется, что в этом случае эффект не проявится...
да, ПЛК и OPC и мастер и слэйв одновременно. Для организации событийного обмена.
Вот лог с константой. Значение = 1075.
20:13:50 разрыв
20:14:05 подключил кабель
эффект не наблюдаю
Что и ожидалось. При обрыве какие-то данные меняются и передаются в SCADA при восстановлении питания.
Нужна логика поведения при обрыве канала. Т.к. есть и мастер и slave - можно организовать пинг-понг значения и определять обрыв.
Коротко расскажу что происходит у меня в ПЛК во время обрыва:
Есть некая переменная Х, которая рассчитывается на борту и отражает положение (координату) движущегося объекта. Объект умеет плавно разгоняться и плавно тормозить, т.е. Х резко меняться не может. Так как объект подвижный, связь со скадой осуществляется через WiFi. Беспроводная связь не гарантирована и поэтому я тестирую всю систему в условиях, когда связь кратковременно пропадает в различных ситуациях. Вышеописанная ситуация возникает при следующих условиях: объект движется, Х равномерно меняется, я имитирую разрыв соединения путём отключения кабеля ethernet от контроллера, объект при этом продолжает двигаться, соотвтетсвенно Х продолжает меняться. Затем объект останавливается и Х соответственно становится постоянной. Далее я подключаю кабель ethernet, соединение успешно восстанавливается скада видит правильное текущее значение Х, которое уже не меняется. Затем через несколько секунд Х в скаде начинает резко прыгать несколько раз и если параллельно смотреть это значение на борту ПЛК через CDS то оно, как и должно быть, никак не меняется. Потом, через некоторое время, всё становится хорошо.
Кроме того на борту ПЛК контролируется переменная ошибок модуля модбас мастер и если она не равна нулю (+ определённый таймаут), то код, присваивающий расчётную Х соотв. переменной в конфигурации мастера не выполняется. Но в любом случае переменная, объявленная в конфигурации может меняться не зависимо от того есть связь или нет.
В общем и целом проблема не является критичной ибо на борту ПЛК всё хорошо, но визуализация страдает. Я чувствую, что здесь есть косяк, только не пойму у кого: в реализации модбас TCP в конфигураторе ПЛК или всё-таки дело в OPC-сервере. Поэтому:
1. Попробую применить другой OPC-сервер
2. Напишу простенькую программку для ПЛК, имитирующую поведение ПЛК в этой ситуации без остального кода. И таки докажу проблему :)
3. Пойму, что сам дурак и чего-то не вижу или неправильно понимаю...
Итак, мне удалось получить проблему на простенькой программке, которая имитирует вышеописанный алгоритм. Во вложении к данному посту проект CDS, конфигурация OPC-сервера MasterOPC, а также лог сниффера, в котором зафиксировано появление ошибки при работе этого теста.
Кабель выдёргивал при значении MB_X примерно 5000. После стабилизации значения подключал кабель примерно через 2-3 секунды. Зафиксированы ложные значения: 5300 и 4200.
Владислав, посмотрите, пожалуйста. Алгоритм работы теста описывать не буду, там всё тривиально.
Итак, каждые 100 мс ПЛК уменьшает значение на 100.
В р-не значения 5300 кабель вынимают.
ПЛК ещё некоторое время продолжает посылать пакеты (с числами всё меньше и меньше, тем более у Вас стоит 3 попытки повтора.
Наконец Мастер рвет коннект, пробует новое соединение и когда кабель втыкают - соединяется.
Но некоторое время остатки предыдущих пакетов с разорванного коннекта гуляют по сети.
Непонятно по какой причине slave их воспринимает как ликвидные, хотя: номер порта-источника другой, последовательность посылок по TCP разрушена.
Но соединение в Slave всё еще воспринимает данные из "фантомного соединения".
Причины:
1. Таймаут на разрыв соединения в slave много больше чем у мастера. +
2. Slave поддерживает мультисоединение - несколько мастеров на 1 slave (это вообще невообразимо - 2(3, 4 ...100?) мастера на 1 slave ???)
Настройки слэйва во вложении.
Всё таки виноват OPC-сервер?
Владислав, поучавствуйте, пожалуйста в этой теме.
Владислав, позвольте Вас снова побеспокоить.
Коллеги утверждают (тынц), что неактуальные данные передаёт-таки контроллер после восстановления соединения. Подскажите, пожалуйста, это можно как-то исправить или это нормальное поведение? (и соответственно нужно понять и простить :))
Я считаю, что это правильное поведение. Данные, которые передаёт контроллер, это не переданные, но попавшие в очередь на передачу данные предыдущей сессии (в реальной сети такие "фантомы" встречаются регулярно). Эти данные slave-ом должны игнорироваться, т.к. уже установлена новая сессия.
Утверждение, что все так делают и можно иметь мультимастерный ModBus противоречит самой концепции Мастер-slave. И тем более, такое поведение slave-а должно быть не "по умолчанию", а специально настраиваться. Тем более на 1 порту.