Галочку Writeable на вкладке General поставили?
Галочку Writeable на вкладке General поставили?
Галочка Writable превращает Holding registers в Input registers, адреса меняются с %IW на %QW:Цитата:
Сообщение от Евгений Кислов
https://s1.hostingkartinok.com/uploa...660da913a3.png
А нужны именно честные Holding, которые будут читаться извне функцией 03 - Read Holding Registers
Вы ошибаетесь. Галочка делает holding регистры доступными для изменения из кода программы, вот и всё.Цитата:
"Галочка Writable превращает Holding registers в Input registers, адреса меняются с %IW на %QW"
Считываться они по-прежнему будут функцией 03.
Пробовал, почему-то не вышло - функцией 03 считывались нули, а функцией 04 - считывались данные.Цитата:
Сообщение от Евгений Кислов
В целом, такой подход выглядит еще как больший костыль, чем наложение, которое было раньше. Т.е. часть %QW будет читаться функцией 3, а часть - функцией 4?
Покажите скринами - какие значения у вас в holding регистрах и что вы видите в мастере.Цитата:
Сообщение от vozlov
Вот пример - может, с ним станет понятнее, как надо действовать:
https://youtu.be/Q3hqQlqcESo?t=5501
Пользователю вообще не надо думать о %QW.Цитата:
Сообщение от vozlov
Пользователь работает с переменными, привязанными к регистрам.
Добрый день.
Не очень понимаю как настроить связь между двумя ПЛК 210 по средством GVL отправитель/получатель. Хочу из одного плк передавать в другой пачку переменных. Есть два шкафа управления, в каждом стоит плк, в обоих случаях плк выполняют роль мастера. Подключаю между собой плк на 2 порт eth. В проекте, который на ПЛК-ОС я добавил GVL отправителя. Вложение 65777
Затем добавил в этот проект ПЛК-получателя(ПЛК-ЖБ) и добавил в нем GVL получателя. Вложение 65778 Что следует сделать в проекте ПЛК-ЖБ чтобы получать данные с ПЛК-ОС?
Добрый день.Цитата:
Сообщение от Андрей Чернов
См. видеопример:
https://www.youtube.com/watch?v=-MYbECw9Ots&t=4982s
Получается мне необходимо перенести обе программы плк в один проект?Цитата:
Сообщение от Евгений Кислов
Это самый простой способ.Цитата:
Сообщение от Андрей Чернов
Второй вариант - через экспорт/импорт файла. Его я рассматривал здесь (во второй половине видео):
https://youtu.be/46_XHKU9UoI
А сложный - это поднять на плк слейв, например библиотекой owenCommunication, и опрашивать его другим плк добавив в него слейв-плк стандартными средствами, верно?Цитата:
Сообщение от Евгений Кислов
Я вообще имел в виду способы настройки обмена через сетевые переменные (добавление всех ПЛК в один проект проще, чем экспорт/импорт файлов).Цитата:
Сообщение от Андрей Чернов
Но ваше утверждение тоже в целом верно.
Как разбить MIB на подпапки? ФБ агент SNMP c одним TypeDevice занимает порт и выключает экземпляр агента c другим TypeDevice. Только менять порты в браузере/включать нужный агент, или я что-то упускаю?
Да, можно использовать несколько экземпляров ФБ с разными портами.Цитата:
Сообщение от xjkpt
Мы не предусматривали группировку, у нас реализация с плоским списком.
Всем привет,
Прошу помощи с настройкой обмена.
Суть:
СПК 107 - Master Modbus RTU. Пытается читать переменные из слейва (ПР200, INT 0x0200). При отладке: стрелочки обмена зеленые: ошибок нет, но в данных канала "не обновлено". И, что интересно: в списке использований переменной есть ошибка.
ПО СПК обновлен до последних версий с сайта.
OPC сервер, висящий в той же сети, но запускаемый, естественно, когда спк молчит - все
Скриншоты:
Добрый день.Цитата:
Сообщение от kaftanati
См. информацию здесь:
https://owen.ru/forum/showthread.php...l=1#post343792
Спасибо! Помогло!Цитата:
Сообщение от Евгений Кислов
Всех приветствую. Подскажите пожалуйста как контроллером ПЛК210 считать данные с MXConfigurator или ПЛК Mitsubishi FX5U. Возможно ли с помощью .csv файла импортировать каналы или OPC UA клиентом? Связь пытаюсь настроить по TCP.
Добрый день.Цитата:
Сообщение от ВалераМ
У нас нет опыта работы с Mitsubishi.
Вот видеопримеры настройки обмена по Modbus TCP и OPC UA, которые демонстрируют, как это выполняется на стороне наших ПЛК:
https://youtu.be/mkpY3u7K8Kg
https://youtu.be/iO5phx9zENM
А контроллер может быть клиентом OPC? Я слышал вроде как есть драйвер отдельный?Цитата:
Сообщение от Евгений Кислов
В наших контроллерах работа в режиме OPC UA Client не поддерживается.Цитата:
Сообщение от ВалераМ
Подскажите, штатно CoDeSys поддерживает Modbus RTU over TCP? Или как такой обмен настроить?
Поддерживает в режиме master. См. в библиотеке OwenCommunication ФБ MB_TcpClient.Цитата:
Сообщение от vozlov
Только через библиотеку OwenCommunication, верно? Штатно имелось в виду через интерфейс CoDeSys, их стандартными устройствами.Цитата:
Сообщение от Евгений Кислов
Стандартные средства CODESYS не поддерживают этот протокол.Цитата:
Сообщение от vozlov
Всем добра! Подскажите пожалуйста, как работает библиотека CmpOPCUAClient Implementation ? Есть документалка как либо или примеры на эту библиотеку?
Добрый день.Цитата:
Сообщение от ВалераМ
На наших контроллерах эта библиотека не поддерживается.
Есть вот такая проблема с обменом по Modbus TCP со слейвом (RESPONSE INVALID HEADER):
https://s1.hostingkartinok.com/uploa...3516b9b2c8.png
Различными Modbus-сканерами этот слейв опрашивается. Проведенный анализ показал, что проблема может быть связана с тем, что слейв шлет "лишний" байт в каждом ответе:
https://s1.hostingkartinok.com/uploa...80a374e63f.png
Поэтому CoDeSyS-реализация Modbus TCP мастера отбраковывает данный ответ, и данные не принимает. Библиотека OwenCommunication - тоже.
Подскажите, как проще "подстроиться" под данную явно кривую реализацию слейва? Что-то изменить на стороне слейва возможности нет.
Использовать ФБ UNM_TcpRequest из библиотеки OwenCommunication.Цитата:
Подскажите, как проще "подстроиться" под данную явно кривую реализацию слейва?
Существует ли готовый пример реализации "правильного" Modbus TCP с использованием данного ФБ? Чтобы убрать в нем строгую проверку длины ответа...Цитата:
Сообщение от Евгений Кислов
У вас цель - полностью сделать "правильную" реализацию Modbus TCP с использованием данного ФБ или решить конкретную проблему с вашим конкретным слэйвом с "кривой реализацией" протокола?Цитата:
Сообщение от vozlov
Если второе - то достаточно хардкодом задать нужные запросы и написать примитивный парсер ответов, вычленяющий данные по известным байтовым смещениям.
Вся нужная для этого информация на вашем скриншоте с Communication Traffic есть.
Цель - решить проблему с кривым слейвом. Имея готовую "правильную" реализацию Modbus TCP это сделать очень просто - заменить проверку длины ответа (строгое равенство =) на >=.Цитата:
Сообщение от Евгений Кислов
Со слейва нужно вытаскивать много данных разными запросами, т.е. нужен полноценный Modbus TCP. Слейв просто лепит везде лишний байт, а так отвечает нормально.
Вопрос только в лишнем байте (последнем), который не дает использовать (предположительно) штатный Modbus TCP / реализацию Modbus TCP в OwenCommunication.Цитата:
Сообщение от capzap
Утилиты опроса по Modbus (например, Modbus Poll), опрашивают данный слейв, отображают данные, несмотря на некорректные ответы (лишний байт в конце).
Тогда вам придется реализовать его самостоятельно.Цитата:
Имея готовую "правильную" реализацию Modbus TCP
Мы не распространяем исходники своих библиотек.
Имелся в виду пример CoDeSys-реализации Modbus TCP с использованием UNM_TcpRequest. Не исходники "правильного" MB_TcpRequest.Цитата:
Сообщение от Евгений Кислов
Это синонимичные вещи. MB_TcpRequest построен на базе UNM_TcpRequest.Цитата:
Сообщение от vozlov
Поскольку обычно производители слэйвов не имеют привычки вставлять в ответ лишние байты - то ни у кого не возникало поводов создавать альтернативную open-source реализацию.
Да. Мастер (ПЛК200) без проблем опрашивает правильные слейвы штатным драйвером CoDeSyS и блоком MB_TcpRequest библиотекой OwenCommunication.Цитата:
Сообщение от capzap
Этот слейв оба варианта не могут опросить.
Подскажите, для управления ПЧ AFD-E есть шаблон в котором управление происходит по отправке командного слова и подтверждающий Бит записи
Вложение 66430
хочу повторить код запроса без шаблона, часть кода есть - это отправка самого командного слова
а вот куда записывать бит не понятноКод:VAR
...
fbKnopTrig: R_TRIG;
END_VAR
// Проверка привода на готовность
fbComControl1
(
xEnable := TRUE,
udiComPort := 5,
udiBaudrate := 9600,
udiByteSize := 8,
eParity := OCL.COM_PARITY.NONE,
eStopBit := OCL.COM_STOPBIT.ONE
);
IF fbComControl1.xActive THEN
fbKnopTrig(CLK := xKnop);
IF fbKnopTrig.Q THEN
eState := 20;
END_IF
CASE eState OF
0: // ожидание команды
10: // Опрос состояния AFD-E
20: // запуск AFD-E
wCmdWord := 22;
fbMbSerialRequest.xExecute := TRUE;
fbMbSerialRequest.hCom := fbComControl1.hCom;
fbMbSerialRequest.xIsAsciiMode := FALSE;
fbMbSerialRequest.usiSlaveId := 15; // адрес слейва
fbMbSerialRequest.eFuncCode := OCL.MB_FC.WRITE_SINGLE_REGISTER; // функция
fbMbSerialRequest.uiDataAddr := 4864; // адрес начального запроса
fbMbSerialRequest.uiDataCount := 1; // число регистров
fbMbSerialRequest.pData := ADR(wCmdWord);
fbMbSerialRequest.szSize := SIZEOF(wCmdWord);
fbMbSerialRequest();
// fbMbSerialRequest.xError := xError;
// fbMbSerialRequest.eError := wError;
IF fbMbSerialRequest.xDone OR fbMbSerialRequest.xError THEN
fbMbSerialRequest(xExecute := FALSE);
eState := 0;
END_IF
END_CASE
END_IF
В тех поддержу обращался, но там не поняли что надо и сбросили файл в котором они тестировали подключение.
Вложение 66431Вложение 66432Вложение 66433
Аналогом бита записи шаблона является вход xExecute в fbMbSerialRequest.Цитата:
а вот куда записывать бит не понятно
В вашем коде аналогом этого бита является xKnop.
В тех поддержке написали что регистр 4864 всегда должен быть в значении 22Цитата:
Сообщение от Евгений Кислов
Т.Е. надо сделать зацикливание в программе я правильно понимаю?
Код:IF fbMbSerialRequest.xDone OR fbMbSerialRequest.xError THEN
fbMbSerialRequest(xExecute := FALSE);
eState := 20;
END_IF
Я не вижу причин делать "зацикливание в программе".