This is topic Siemens_3964R_RK512 in forum TRACE MODE 6 бесплатная Базовая версия / TRACE MODE 6 free Base version at Форум TRACE MODE: техническая поддержка.
Такая ситуация: Имеем ТМ6.06.3 базовая редакция. В проекте связь между узлом ТМ и ПЛК по протоколу RK512. Соответственно есть Источники/Приемники Siemens_3964R_RK512 и каналы типа Hex16. В минимальной конфигурации их по одному. COM-порт задан утилитой R3964cfg.exe. Конфигурационный файл r3964.cfg находится в папке узла. У "источника" Siemens_3964R-RK512#1 заданы: номер [порта] - 0, Тип регистра - MemoryFlags, Номер регистра - 100, Направление - Input. С этим источником связан канал Канал#1 (HEX16, Input) узла RTM_1. На экран выводится значение канала, а в ПЛК генерируются случайные значения в регистре M100. При запуске профайлера данные на экране не меняются, однако снифер порта (PortMonitor) показывает, что ТМ генерирует запросы, ПЛК на них отвечает в соответствии с протоколом. Наблюдаемые в снифере данные изменяются в соотвествии с реальным содержимым регистра ПЛК. На экране профайлера данные не изменны. В логе узла никаких ошибок не пишется.
Добавляем еще один канал Канал#2 (Hex16, Output) и источник/приемник Siemens_3964R-RK512#2 (номер [порта] - 0, Тип регистра - DataBloks, Номер регистра - 0, Db-номер - 1, Направление - Output) и связываем их друг с другом. На экране добавляем элемент с возможностью посылки данных в канал. Запускаем профайлер. Ситуация как и прежде: данные идут, но в значениях канала не отображаются. Однако стоит в канал типа Output передать какое-либо значение, как в каналы-приемники начинают поступать полученные от ПЛК значения.
Вообщем, получается, что для инициации обмена данными требуется дополнительный канал ТМ, + дополнительный блок данных в ПЛК. Как-то можно этого избежать?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Драйвер был написан в 2001 г. на основе нелегального перехвата протокола, поскольку официального предоставления протокола и разрешения на создание и распространение драйвера не было. Последний раз драйвер успешно испытывался в 2005 г. на оборудовании Московского представительства фирмы Siemens. В силу того, что Siemens крайне отрицательно относится к попыткам использования его протоколов для подключения к чужим SCADA, испытания проходили по очень сокращенной программе. В проекте задавался всего 1 INPUT-канал с типом переменной DInputs(I/E). Уже тогда было выявлено, что прошивки в ряде контроллеров отличаются от тех, на которых драйвер проверялся в момент его создания. Не все контроллеры удалось подключить. Поддержка связей с контроллерами Siemens фактически осуществляется в статусе "как есть". Ни проверить, ни модифицировать драйверы мы не имеем возможности. Единственная устойчивая схема подключения - через OPC-сервер, поддерживающий полевые шины контроллров Siemens.
Posted by Nestor (Участник № / Member № 1148) on :
Ладно, а устойчивая работа пользовательских драйверов T11-T12 гарантируется? Благо протокол самим Сименсом опубликован.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Если речь идет о написании драйвера Вашими силами в соответствии с опубликованными в документации спецификациями TCOM, то пользовательская практика показывает, что при соблюдении спецификаций драйверы работают устойчиво. Да и все реально отработанные драйверы написаны в соответствии с этими спецификациями.
Анализ кода пользовательских драйверов на уровне программистов не входит в объем бесплатной технической поддержки.
