Да, овен плк-160. Int32 установил, так как с панели выходит в таком формате, а дальше приходится преобразовывать. Поставил int32, в настройках сервера запретил использовать команду 0х06. Запись прошла успешно.
Да, овен плк-160. Int32 установил, так как с панели выходит в таком формате, а дальше приходится преобразовывать. Поставил int32, в настройках сервера запретил использовать команду 0х06. Запись прошла успешно.
У меня такой вопрос. Установил ОРС сервер версии 3.1.0 и никак не могу добиться чтобы значение float передавалось в SCADA систему с десятыми или сотыми. Подскажите пожалуйста как это можно сделать?
Ни так слетел объяснил. С ОРС сервера выходит сигнал float, а SCADA приходит целый.
Извиняюсь, мой косяк был, надо было просто обновить данные в SCADA системе.
Не понятно - вы решили проблему или нет?
Вы используете масштабирование? Проверьте правильные ли вы типы указали в настройках "Тип данных в устройстве" и "Тип данных в сервере".
Это не совсем правильное поведение.
В качестве примера приведем наш ОРС сервер в режиме "Мастер". Если сервер чувствует обрыв соединения (приходит ошибка от системной функции ОС), то сервер прекращает попытки повтора (зачем если коннекта нет), закрывает соединение, и пытается снова соединиться.
Давайте представим такую схему. У нас есть один ПЛК и компьютер, которые соединены напрямую кабелем (перекрестным). Разорвали соединение.
Какие остатки предыдущих пакетов будут гулять по сети? И где они будут гулять?
Они могут накопиться в буфере контроллера, и потом (если контроллер не очистил буфер) выйти в сеть. У нас в ОРС сервере (в режиме Мастер) это учитывается, и буфер при новом соединении очищается.
Почему нарушена последовательность посылок? Почему стал другой номер порта и источника?
После реконнекта сменился IP и порт?
У нас в Slave нет таймаута ожидания разрыва. Разрыв детектируется операционной системой и передается в программу.
Наш Slave действительно поддерживает мультисоединение. Несколько странно почему это так удивляет главного разработчика фирмы ОВЕН. Большинство контроллеров поддерживает несколько соединений на один порт (Wago, Modicon, Delta), не говоря уже про различное ПО для операционной системы Windows (например эмулятор ModRSSim поддерживает до 1000 коннектов). Но к данной проблеме это отношения не имеет.
Ошибка приходит по таймауту коннекта, а пока его нет (а это секунды и более) - ПЛК успеет 10-к пакетов послать при описанных настройках мастера.
Буфер мастера очищается, а буфер стека TCP/IP? На логе ясно видны попытки ретрансмита.
И зачем представлять самую простую схему - использование TCP/IP предполагает что мастер находится, к примеру, в Антарктиде, 30 хопов до slave-а.
При новом соединении как минимум номер порта-source меняется именно для того чтобы можно было различить что это новое соединение а не обежавший планету 3 раза пакет.
Через сколько секунд разрыва? В протоколе TCP/IP нет нативных средств для определения разрыва от внешних причин (дядя Вася с топором) в момент разрыва, только по таймауту.
[/QUOTE]
О майн гот! Расскажите мне, что будет со SCADA если я в один порт с 2-х мастеров буду по очереди слать: то "температура реактора 100 градусов" то "500 градусов"? Вот что будет делать SCADA, будет ли там признак "Данные из разных источников"? Нельзя ли узнать на каких опасных производствах стоит Ваш OPC?
Много соединений на 1 порт нужно для Web-сервера, к примеру, где действия 1 пользователя не пересекаются с другими. А ModBus априори предполагает наличие только 1 мастера в сети.
Описанный выше апокалипсец как раз и происходит у Павла. Соединение закрыто, мастер открыл другое а OPC еще обслуживает старое соединение и получает негодные данные.
Это зависит от реализации и настроек маршрутизатора. Маршрутизатор может сбрасывать буфер при отсутствии коннекта.
А почему бы и не проверить?
Может быть г-н _Pavel_ проверит работу по такой схеме?
Не обязательно. Порт источника может остаться как и в предыдущей сессии.
Кроме того если будет установлен новый коннект, а в буфере маршрутизатора остались данные, то эти старые данные будут записаны уже в новой сессии с новыми параметрами соединения (новым портом-source).
Вы занимаетесь демагогией.
Отвечая на вопрос что будет если послать разный запрос с двух мастеров ответ прост - сервер пример и запишет в теги сначала первый запрос, затем второй запрос.
Точно также поступит и ваш контроллер, если добавлю в него два TCP порта (502 и 503).
И это полностью является проблемой разработчика - он может на уровне исполняемых контролировать подобные изменения (в MasterSCADA для этого есть параметр "блокировка обратной связи"). В конце концов существуют информационные системы - которые только получают данные, и не производят запись данных.
В контроллерах вашей разработки ни что не мешает мне добавить в узел Modbus(Slave) два TCP порта (или больше) и обращаться к ним с разных мастеров. Поэтому режим 2 мастеров у вас, просто реализован не так удобно как у других производителей.
Но вот в чём нюанс - у меня на ПЛК это будут 2 различных slave c разными тегами (в терминологии SCADA) или 1 slave с разными портами , т.е. это осознанный (не значит правильный, но осознанный) выбор. А если OPC поддерживает мультимастерность на одном порту - это будет скрытая особенность, дыра как для случайных (как у Павла) так и для намеренных действий. И противоречие со стандартом ModBus. Кстати, на ПЛК можно не включать мультимастерность, а как это сделать для OPC?
А где оно отключается?
То есть данные с прошлой сессии приходят? Тогда про какую Антарктиду идут рассуждения?
Slave можно сделать с разными портами и одинаковыми тегами.
Просим вас указать где в Modbus TCP есть запрет двух и более коннектов:
http://www.modbus.org/docs/Modbus_Me...uide_V1_0b.pdf
Мы считаем что это ничего не даст. Но можно поэкспериментировать.
В комплекте с нашим OPC сервером есть ранее упомянутая утилита ModRSSim (c:\Program Files\InSAT\MasterOPC Universal Modbus Server\MODRSSIM\) - это эмулятор Modbus Slave устройства.
Г-н _Pavel_ просим вас выполнить следующее. Установите данную утилиту, и переключите ее на режим Modbus TCP, и установите у нее в настройках один коннект (см. приложение). Воспроизведите ошибку с этой программой (вместо ОРС сервера - сервер не запускайте). Поступление пакетов с прошлой сессии можно будет увидеть по логу - кнопка Comms в правом нижнем углу. В настройках лога включите отображение времени "Show Times" - так будет легче увидеть данные после разрыва. Посмотрите какие данные поступят от контроллера после восстановления соединения.
А что мешает данным из прошлой сессии попасть в сеть при восстановлении физического линка?
Пункт 1.2 Там даже рисунок есть. И перечисление из 4-х вариантов соединений. Везде 1 мастер - (1..N) slave. Обратных вариантов нет.
И в пункте 4.2.1:
Цитата:
A MODBUS request has to be sent on the righ
t TCP connection already opened. The IP
address of the remote is used to find the TC
P connection. In case of multiple TCP
connections opened with the same remote, one connection has to be chosen to send
the MODBUS message, different choice criteria can be used like the oldest one, the
first one.
Давайте вернемся немного назад. Вы писали:
Вот сейчас г-н _Pavel_ оставил как раз самую простую схему. И 30 хопов в Антарктиде мы исключили, остается только ваш контроллер и наш OPC сервер. Поэтому давайте оставим Антарктиду г-ну Сидякину, и разберемся почему у вас в контроллере не происходит очищение буфера?
Это рекомендация, которая зачастую игнорируется - когда нужно получить быстро большой объем данных, используя несколько потоков (несколько соединений).
Посмотрите пункт пункта 3.1.1 - там несколько Modbus мастеров на шине.
Или:
A MODBUS request has to be sent on the right TCP connection already opened. The IP address of the remote is used to find the TCP connection. In case of multiple TCP
connections opened with the same remote, one connection has to be chosen to send the MODBUS message, different choice criteria can be used like the oldest one, the
first one. The connection has to maintain open during all the MODBUS communications. As described in the following sections a client can initiate several MODBUS
transactions with a server without waiting the ending of the previous one.
Как описано в следующих разделах клиент может инициировать несколько MODBUS операции с сервером, не дожидаясь окончание предыдущего.
А с чего оно должно происходить? Линк потерян, в буфере пакеты, пакеты не потеряли ещё актуальности. Линк возобновился - выдаём в сеть.
Одним Modbus клиентом. А не 2-а на 1 сервер. а шина - это ethernet - там может быть всё что угодно - но 1 мастер - N slave.
При этом N коннектов 1 клиента к серверу - но внутри 1 мастер к slave. О чём чётко пишется в пункте 4.2.1.
Банальный здравый смысл, а учитывая что ModBus TCP это надстройка над обычным ModBus serial, где жёстко 1 мастер - то и транспортный уровень не должен менять логику. На рисунке как раз и показан пример со шлюзами из serial в serial через TCP.
Иначе получится абсурд - пишем письмо бабушке - а авиакомпания меняет язык в письме.
P.S. Вот когда ГОСТ рассматривают как "рекомендацию" - и возникают проблемы.
1 клиент, один, а не 2. Если 1 мастер создаёт несколько параллельных запросов к разным данным - это можно.
Установил, пытаюсь. У меня на компьютере сразу кто-то подключается к этой утилите и занимает единственное соединение, пока не могу понять кто... вроде бы всё подозрительное убил диспетчером задач...
Если ПЛК успевает занять соединение , то после принудительного дисконнекта уже не может подключиться, т.к. соединение занято.
Успел отметить факт: произвёл дисконнект, значение в утилите замерло, проходит секунд 7-10, значение изменяется (в правильном направлении), потом ещё несколько секунд - ещё раз изменяется как будто пакет доходят. При этом ПЛК уже отключен, а соединение занял кто-то другой...
Ну мы уже писали ранее - это не совсем корректное поведение. Нужно закрыть соединение, тогда пакеты будут удалены. А после восстановления связи уже посылать новые.
А если рассуждать как вы (данные не потеряли актуальности) - то что мы тогда вообще обсуждаем, получается что у _Pavel_ проблем никаких нет - данные то поступили актуальные.
Это не играет роли. Slave поддерживает несколько коннектов, от одного мастера или от нескольких зависит от конфигурации пользователя, т.е. от реализации конечного проекта.
Вам лучше смотреть по логу - по данным вы можете и не увидеть, так как они могут изменится быстро. Посмотрите какие запросы поступают после восстановления соединения, и спустя какое то время (раз вы говорите что пакеты доходят спустя какое-то время).
Пардон, это ПЛК в сброшенном состоянии подключается...Цитата:
У меня на компьютере сразу кто-то подключается к этой утилите и занимает единственное соединение, пока не могу понять кто... вроде бы всё подозрительное убил диспетчером задач...
Вот посмотрите, пожалуйста, видео эксперимента: тынц
Как мы поняли из вашего видео, старые запросы с контроллера все равно приходят (в контроллере 1000, а в программу поступило сначала 5400, а затем 4300). Поэтому вариант с ограничением коннектов в сервере ничего не даст.
Да, старые запросы приходят. Но мне не понятен один факт: почему когда был разрыв соединения утилита всё равно показывала Connected 1/1. А после восстановления подключения, ПЛК не мог подключиться, висела ошибка "81". И в этом состоянии в утилиту как раз приходили старые пакеты. Пока не выполнил команду (в конце видео) закрыть/открыть порт.
Попробуйте посмотреть вкладку "Comms" - какие Modbus запросы поступали в это время.
Добрый день, подскажите,
как будут вести себя в плане стабильности работа двух универсальных ОПС-серверов разных версий при работе с одним ПЛК-100. В краткосрочном периоде я потестил - все гуд, хотелось узнать что будет в долгосрочном. Нужно ли приводить опс-серверы к одной версии? На плк открыты порты 501 и 502, плк настроены в режиме модбас слэйв по тcp/ip. Версии ОПС - 3.1.3 (только оплатили, еще не забирали, скорее всего версия будет такой) и 2.0.0.11 (2.0.0.9) (покупали в 2012-м). И еще - кому интересно, 2,5 года назад я перешел с кодесисного глючного опс-сервера на универсальный от модбас. Сейчас у меня в сети общее кол-во ПЛК - 275 штук и два опс-сервера. На 1-м сервере всего плк - 240 штук, на втором - пока 35 штук. Второй сервер запускается по Dcom. Все работает очень гуд, ни одного сбоя или зависания за 2,5 года, только добавляю новые ПЛК. И еще добавлять и добавлять))). Проект один. Сейчас встал вопрос об открытии 2-го проекта, будем использовать теже ПЛК, только разделим сигналы и выведим их на теперь уже третий ОПС, который будет работать параллельно либо с первым либо со вторым опс-сервером.
Добрый день, вопрос такой: возможно ли с помощью Lua опрашивать http Web сервер? Пытался подключить внешнюю библиотеку luasocket, но успеха не добился. (Хочу получать данные с прибора Мемограф-М через его встроенный Web сервер, с последующим разбором ответа) Если можно, с примером. Спасибо.
Я вернулся :). Посмотрите, пожалуйста видео и скриншот.
Вложение 16792
По скриншоту хорошо видно - после восстановления связи в ОРС сервер пришло сразу несколько "склеенных" запросов. То есть пока не было связи буфер контроллера наполнялся, а затем после установления связи все данные вышли в сеть.
Старые данные из контроллера также поступили - поэтому настройка одного коннекта в ОРС сервере ничего не даст. Нужно очищать буфер в контроллере.
Спасибо. Ситуация немного проясняется...
А почему в поле Connected значение 1/1 даже когда соединения нет?
На этот вопрос мы ответить не можем - программа не нашей разработки.
Прошу прощения, а что насчет моего вопроса #229?
Подключил библиотеку luasocket для MasterOPC Server v.3.1.3 скопировав все каталоги библиотеки в каталог c:\Program Files\InSAT\MasterOPC Universal Modbus Server_3\. Теперь в каталоге есть файл lua51.dll (из дистрибутива MasterOPC Server) и lua5.1.dll (идёт с библиотекой, без него библиотека не подключается, в этом и была ошибка). Стесняюсь спросить: точку в названии dll случайно потеряли или так надо?
Кому интересно, до WEB сервера из MasterOPC Server достучался с помощью socket.connect и последующего receive, а простой http.request не работает...
Из консоли LUA работают оба метода.
Здравствуйте! Подскажите пожалуйста! А MasrerOPC поддерживает протокол Овен? Я могу старые овеновские приборы без поддержки MadBus подключить к серрверу OPC?
Нет, протокол ОВЕН наш ОРС не поддерживает.
Используйте ОВЕНовский же OPC
Здравствуйте SCADAMaster,
Пытался реализовать подключение контроллера S7-1200 v2.2 к OPC-серверу Modbus Universal MasterOPC Server про протоколу Modbus TCP. Для реализации проекта у меня версия STEP 7 Basic от V12 SP2, Modbus Universal MasterOPC Server версии 2.0.0.12, программируемый контроллер S7-1200 версии от v2.0, сетевое соединение между контроллером и рабочей станцией. Добавил блок МОДБАС ТСР, создав в базе данных массив с именем 400001, как написано было в инструкции и обратился к этому массиву типом данных Array [0..15] of Bool в блоке MB_Server. Контроллер реагирует на запись нового значения через ОРС сервер и обратно, т.е. связь установлена.
1. Подскажите как извлечь отдельные биты средствами самого OPC сервера или же непосредственно в SCADA-системе.
2. Напишите пожалуйста инструкции как передать (со стороны ПЛК) и обратиться средствами OPC к данным не из DB, т.е. реальных В/В.
Спасибо заранее,
Ариф
Можно у тега включить "Извлечение бита", но лучше использовать распаковку на уровне SCADA. Для этого используйте ФБ "Распаковка 32-битного значения" (закладка "Вычисления" Палитры ФБ).
Также рекомендуем вам обновить вашу версию MasterOPC до текущей - 3.1.3
С этим вопросом вам лучше обратится в Siemens - узнать есть ли возможность получить доступ к входам и выходам из Modbus. Но скорее всего нельзя. Делайте промежуточные Modbus переменные.