This is topic Переключение на резервный ПЛК in forum TRACE MODE 6 бесплатная Базовая версия / TRACE MODE 6 free Base version at Форум TRACE MODE: техническая поддержка.
Не получается перключение на резервный ПЛК, связь ведется по протоколу MODBUS TCP. Содержание файла ip_modbus: ;502 Port 1 192.9.200.42 TCP2=192.9.200.48 Канал @e_TCP_ModBus типа OUTPUT, параметр 1, Адрес запроса MODBUS в источниках-приемниках 1. Канал Call.ChGroupReq привязан к @e_TCP_ModBus. По нажатию кнопки в 90 атрибут Call.ChGroupReq пишется 1, в 97 атрибут Call.ChGroupReq пишется 10 и в 98 атрибут Call.ChGroupReq пишется 9. Но на другое значение с резервного контроллера не переключается. Из справочной системы не понял, какой параметр должен быть у канала Call.ChGroupReq, к которому привязана @e_TCP_ModBus, может быть в этом ошибка...
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
ПАРАМЕТР у канала Call.ChGroupReq, к которому привязана @e_TCP_ModBus, должен быть равен 0.
Перепроверено в релизе 6.08.
Вот текст нашего профайлерного протокола с ключом DEBUGON=400 (устройство по второму адресу отсутствует):
(14:38:14) INF_TCP:HOST 192.168.12.13:51651 connect to 192.168.12.14:502 (14:42:22) ERR_TCP:invalid connect for unit_xx addr=192.168.3.203[502] err=10060 (14:43:13) ERR_TCP:invalid connect for unit_xx addr=192.168.3.203[502] err=10060 (14:43:21) INF_TCP:HOST 192.168.12.13:52931 connect to 192.168.12.14:502 (14:47:27) ERR_TCP:ModBus recieve zero bytes from 192.168.12.14:502 Rout_Word(3)#1 (14:47:27) ERR_TCP:ModBus recieve zero bytes from 192.168.12.14:502 GroupWrite (14:47:28) ERR_TCP:ModBus send to 192.168.12.14:502 err=10053 Rout_Word(3)#1 (14:47:28) ERR_TCP:disconnect from 192.168.12.14:502 by errors (14:47:29) ERR_TCP:invalid connect for unit_xx addr=192.168.12.14[502] err=10061 (14:47:58) ERR_TCP:invalid connect for unit_xx addr=192.168.3.203[502] err=10060 (14:48:50) ERR_TCP:invalid connect for unit_xx addr=192.168.3.203[502] err=10060
Первый адрес 192.168.12.14, второй адрес 192.168.3.203. Первая попытка переключения на второй адрес выполнена при подаче в 97 атрибут команды 19 (принудительное переключение). Попытка оказалась неудачной. Возврат на первый адрес осуществлен опять принудительно по команде 19. Затем было подано несколько команд переключения по команде 10. Однако они не были реализованы, поскольку эта команда действует только при потере связи с первым адресом. После отключения MODBUS_Slave по первому адресу (в протоколе это зафиксировано соответствующими сообщениями) и подачи команды 10 осуществлена попытка переключения на второй адрес.
Posted by sebastian (Участник № / Member № 5820) on :
Все равно не работает переключение, значение канала Call.ChGroupReq, к которому привязана @e_TCP_ModBus, при посылке 19 в 97 атрибут с 2 (соединение установлено) изменяется на 1 (подключение). Через 30 секунд оно становится равным 7 (запрет связи). Прошу ответа по этой проблеме, тестовый проект высылаю на hotline3@adastra.ru, описание внутри письма. Работаю в платной версии, но топик уже начат, поэтому разместил сообщение тут.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Пришлите, пожалуйста, к проекту профайлерный протокол с ключом DEBUGON=400
Posted by sebastian (Участник № / Member № 5820) on :
Содержание профайлерного протокола с ключом DEBUGON=400: (8:55:33) INF_LOAD:Starting... test_2 (8:55:33) INF_RTM:Detected NT5.RTM 5.1 (8:55:33) INF_RTM:Professional TRACE MODE 6 Profiler T-Factory RTM+ ver. 6.08.0 (8:55:33) ._.:RTM (8:55:33) INF_LOAD:max channel = 65535 (8:55:33) INF_LOAD:Load Channels = 5 (8:55:33) INF_LOAD:Templates=2 (math=1 sql=0 scr=1 doc=0 pnl=0) (8:55:33) INF_LOAD:Objects = 3 (8:55:33) INF_RTM:Timer=0.055s CalcLoop=275ms (8:55:33) INF_LOAD:LoadTime=0.203s CalcPeriod=275ms (8:55:33) INF_RTM:free_mem=623(639) handle=0 user=0 gui=0 after load (8:55:33) INF_RTM:DayLight enabled (8:55:36) INF_RTM:start time is 0 s (8:55:36) INF_RTM:ModeSwitch e15=0000 e18=0000 e20=0000 [0] (8:55:36) INF_RTM:mode=2(Work) e15=00 e18=00 e20=00 [0-80-src4] (8:55:36) INF_RTM:free_mem=623 handle=0 user=0 gui=0 after start (8:55:36) INF_GRAPH:popup=0 scrref=0 trend=0,0 update=1 (8:55:38) INF_TCP:HOST 192.9.200.25:8964 connect to 192.9.200.42:502 (8:55:48) ERR_TCP:invalid connect for unit_xx addr=192.9.201.43[502] err=10065 (8:56:9) INF_RTM:stoping... (8:56:10) INF_RTM:mode=5(Stop) e15=00 e18=00 e20=00 [0-80-src0] (8:56:10) INF_RTM:stop time is 1.141 s (8:56:10) INF_RTM:number of calculation = 113 (8:56:10) INF_RTM:END OF WORK Как видно из него, после подачи команды 19 обращение идет по адресу 192.9.201.43! Хотя такого ip адреса в системе нет, специально проверил пингом. Непонятно, откуда он взялся, содержание файла ip_modbus следующее: ;502 Port 1 192.9.200.42 TCP2=192.9.200.48
192.9.201.43 тут и не пахнет.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Непонятно почему, но в файле ip_modbus у Вас ошибка. Должно быть ;502 Port 1 192.9.200.42 1 TCP2=192.9.200.48
Сейчас переключение осуществляется так, как если бы второго адреса не было: "19 – если второй IP-адрес не задан – разорвать соединение, инвертировать 2 младших бита в байтах xxx.xxx.XXX.XXX IP-адреса, перейти в статус 0 и попытаться подключиться. Если задан второй IP-адрес – подключиться к нему (отключиться от первого); "
Posted by sebastian (Участник № / Member № 5820) on :
Уже ушел с объекта, но попробовал на офисном компьютере с новым ip_modbus: (17:22:48) INF_LOAD:Starting... test_2 (17:22:48) INF_RTM:Detected NT5.RTM 5.1 (17:22:48) INF_RTM:Professional TRACE MODE 6 Profiler T-Factory RTM+ ver. 6.08.0 (17:22:48) ._.:RTM (17:22:48) INF_LOAD:max channel = 65535 (17:22:48) INF_LOAD:Load Channels = 5 (17:22:48) INF_LOAD:Templates=2 (math=1 sql=0 scr=1 doc=0 pnl=0) (17:22:48) INF_LOAD:Objects = 3 (17:22:48) INF_RTM:Timer=0.055s CalcLoop=275ms (17:22:48) INF_LOAD:LoadTime=0.203s CalcPeriod=275ms (17:22:48) INF_RTM:free_mem=1192(1207) handle=0 user=0 gui=0 after load (17:22:48) INF_RTM:DayLight enabled (17:22:51) INF_RTM:start time is 0.015 s (17:22:51) INF_RTM:ModeSwitch e15=0000 e18=0000 e20=0000 [0] (17:22:51) INF_RTM:mode=2(Work) e15=00 e18=00 e20=00 [0-80-src4] (17:22:51) INF_RTM:free_mem=1192 handle=0 user=0 gui=0 after start (17:22:51) INF_GRAPH:popup=0 scrref=0 trend=0,0 update=1 (17:23:4) ERR_TCP:invalid connect for unit_xx addr=192.9.200.42[502] err=10038 (17:23:25) ERR_TCP:invalid connect for unit_xx addr=192.9.200.48[502] err=10060 (17:23:38) ERR_TCP:invalid connect for unit_xx addr=192.9.200.42[502] err=10038 (17:23:49) INF_RTM:stoping... (17:23:49) INF_RTM:mode=5(Stop) e15=00 e18=00 e20=00 [0-80-src0] (17:23:49) INF_RTM:stop time is 1.14 s (17:23:49) INF_RTM:number of calculation = 204 (17:23:49) INF_RTM:END OF WORK Как видно, 17:23:25) ERR_TCP:invalid connect for unit_xx addr=192.9.200.48[502] err=10060 переключение на требуемый адрес было! Завтра отпишусь в теме, если заработает на объекте.
Posted by sebastian (Участник № / Member № 5820) on :
Спасибо, переключение работает. Но непонятно, почему нужно писать 1 TCP2=192.9.200.48 а не TCP2=192.9.200.48 как написано в справочной системе. Это ошибка в справке или так подразумевалось?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В справочной системе релиза 6.08 написано:
<id> <IP_address_1>
<id> TCP2=<IP_address_2>
Когда вы компилируете проект, такой формат записи реализуется автоматически.
Posted by sebastian (Участник № / Member № 5820) on :
Не работает диагностика Modbus TCP по другим портам. Имеем три контроллера (основной и резервный 192.9.200.42 и 192.9.200.48) и полевой 192.9.200.41. Работа с ними ведется кроме 502 порта, еще и по 503 порту на другом АРМ, все сигналы видны (в источниках-приемниках добавил значение порта в виде <ip>:503), но значение канала Call.Chgroupreg типа OUTPUT, к которому привязана @e_TCP_ModBus равно 0 при подаче любых команд. файл ip_modbus: 503 Port 1 192.9.200.42 503 Port 2 192.9.200.41 503 Port 1 TCP2=192.9.200.48 пустая строка
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Диагностическая переменная @e_TCP_ModBus и канал Call.ChGroupReg, который к ней привязан, должны быть типа INPUT. Задайте каждому узлу в файле *.cnf ключ DEBUGON=400 и пришлите, пожалуйста, проекты с папками узлов для обоих АРМов на адрес техподдержки.
Posted by sebastian (Участник № / Member № 5820) on :
У меня были две переменных @e_TCP_ModBus - INPUT и OUTPUT. В таком виде диагностика не работала. Удалил обе вместе с каналами Call, создал новую типа INPUT и заработало. Спасибо за быструю реакцию.
Posted by sebastian (Участник № / Member № 5820) on :
Уважаемая техподдержка, возник новый вопрос по теме! Структура сети: резервированные контроллеры, каждый с двумя ethernet, и отдельный контроллер, тоже с двумя ethernet. Связь по протоколу MODBUS TCP. Первый резервированный контроллер имеет адреса 192.9.200.42 и 192.9.201.42. Второй резервированный контроллер имеет адреса 192.9.200.48 и 192.9.201.42. Отдельный контроллер имеет адреса 192.9.200.41 и 192.9.201.41. Компьютер имеет две сетевые карты, одна настроена в 200 подсети, вторая в 201 подсети. В настройках проекта выставлены галочки на прием и посылку во всех сетевых адаптерах. Если задать файл ip_modbus вида: 502 Port 1 192.9.200.42 502 Port 2 192.9.200.41 502 Port 1 TCP2=192.9.200.48 502 Port 1 TCP2=192.9.201.42 502 Port 1 TCP2=192.9.201.48 502 Port 2 TCP2=192.9.201.41
то при переключении на резервный ip-адрес (подачей значения 19 в С4)диагностическая переменная меняется со значения 2 на 7 и больше своего значения не меняет (и связи соотвественно нет). После переключения система должна работать со второй сетевой карты, сконфигурированной в 201 подсети. Прошу помочь с этой проблемой!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Видимо, "Второй резервированный контроллер имеет адреса 192.9.200.48 и 192.9.201.48".
Для обмена по Modbus TCP в настройках узла проекта адаптеры задавать не нужно. В настройках RTM задается адаптер, по которому будет осуществляться обмен по протоколу I-Net между узлами проекта.
Описанная коллизия относится к резервированному контроллеру номер 1, для которого задано 4 IP-адреса? А на какой IP-адрес предполагается осуществить переключение?
Речь может идти для каждого контроллера только об одном адресе TCP2.
Надо задать в *.cnf ключ DEBUGON=400 и в профайлерном протоколе отследить, как осуществляется попытка переключения, на какой IP-адрес, с каким результатом.
Видимо, в Вашем случае для резервированного контроллера надо создать 2 "Источника" с разными номерами устройств и парамми IP-адресов. При этом для одного из устройств надо создать полный набор каналов для обмена, а для второго - только 1 канал, который в реальном времени может быть выключен. При необходимости переключения резервных IP-адресов пользоваться штатным механизмом, а для переключения на резервный контроллер - менять номер устройства в удаленном адресе всех каналов обмена с эти контроллером. Для этого можно использовать канала CALL.MOVE или CALL.SET.
Posted by sebastian (Участник № / Member № 5820) on :
смысл переключения такой - если пропадает связь с 1 контроллером на 1 адаптере (в 200 подсети), нужно переключиться на 2 адаптер того же контроллера (в 201 подсети). если и там нет связи, то на 1 адаптер резервного контроллера (в 200 подсети) и так далее.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Я так и понял. На этом и основаны рекомендации в предыдущем посте.
