Вид для печати
Здравствуйте.
Обновились на версию 1.3.6 с версии 1.3 (в названии темы оТпечтка)
В следствии чего вылезли многочисленные (порядка 1000) ошибки (предупреждения):
--->
Неявное преобразование из типа LREAL в тип INT .......
Неявное преобразование из типа SYSTEM_LREAL_PARAM .....
-----
Кто может подсказать что с этим делать и куда копать ?
Проект несмотря на предупреждения - работает.
Где-то в Проект-Свойства есть отключение LREAL, может попробовать. Ну а в принципе надо посмотреть, что за ошибки, хоть одну посмотреть и понять, в чем проблема.
Вложение 82560
Картинка с ошибками.
Ну 1371-1374 где-то в библиотеке в программе ДГУ ошибка, программу надо открыть. Путь же написан.
Можете ничего не делать, предупреждения это не ошибки. Вас предупреждают, что есть несоответствия типов переменных и будет произведена конверсия типов.
Либо вы можете ручками, привести все типы переменных в соответствие.
Спасибо всем за ответы.
Ещё проблема: вылезла c управляющими модулями для кондиционеров - СРК-М2 (TCP/MODBUS TCP/IP) - scada тупо перестала их читать, хотя судя по настройкам всё осталось на своём месте (ip и тд...) , пинг из scada на устройство - проходит.
Причины разные могут быть. Сделайте проект с одним тегом из одного модуля управляющего. Если не работает, то скиньте этот проект. И лог нужно включить расширенный, тогда весь опрос будет записан.
Вот пару строк ошибок:
6486492: |3615418048| [ERR] (192.168.1.133:502) <Modbus> ERROR: incorrect Transaction ID. Clear buffer
6486501: |3514705600| [ERR] (192.168.1.205:502) <Modbus> ERROR: get code error. Exit
Это опрос одного модуля или всех? incorrect Transaction ID - это неправильный ответ от устройства. В расширенном логе должны быть буфер отправки и приема.
incorrect Transaction ID. Clear buffer - смотрите при этом лог. ID транзакции должно соответствовать и в ответе. з.ы. иногда устройства этот параметр тупо игнорируют отсылая 00 00. Тогда швах, где-то в драйвере должна отключаться проверка.
Ответ может быть абсолютно правильным, просто устройство кладет на данный параметр... только лог покажет.
Да это как раз СРК-М2 - ERROR: incorrect Transaction ID.
"В расширенном логе должны быть буфер отправки и приема." - это как посмотреть - расширенный лог? :)
Только лучше упростить проект до одного устройства с одним тегом. Так будет понятнее.
Да спасибо за инфо. Только есть одна проблемка - работающий проект на данный момент, нельзя остановить более чем на 3 минуты. Соответственно создать расширенный лог сейчас не получается...
Может есть ещё какие-нибудь методы диагностики на работающей системе, без остановки её?
У вас СРК с Ethernet портом? В общем какая линия связи?
Wireshark попробуйте
Да, SCADA СРК опрашивает через ethernet порт (TCP/MODBUS)
А что за модель СРК? что-то я не видел с Ethernet их, или упустил.
Ну вот по вашему М2
И где у вас тут Ethernet ?Цитата:
Интерфейс связи с интерфейсными модулями 2-х проводной RS485
Интерфейс связи с верхним уровнем системы мониторинга 2-х проводной RS485
Судя по всему, вы опрашиваете его через преобразователь протокола Modbus TCP - Modbus RTU. Все претензии к преобразователю тогда. Если он Transaction ID игнорирует.
а, не досмотрел Интерфейс Ethernet :)
ну у вас два варианта без остановки системы. 1 - WireShark, как писали выше.
2. Если вы можете остановить линию опроса в MS4D. Себе на ПК развернуть по быстрому RapidScada и настроить опрос там. Она показывает полные логи запросов и ответов по умолчанию в hex формате. Если это СРК игнорирует Transaction ID думать как обойти. Как работает драйвер Modbus в MS4D не представляю.
Ну собственно в тех поддержку Master Scada напишите, можно ли там отключить контроль Transaction ID или нельзя?
Спасибо. Посмотрим.
Вот что удалось посмотреть в логе для ещё одного СРК.....пока не понятно что ему нужно....
4058404: |2187310784| [TRA] (192.168.3.23:502) Tx: [12] 00 4B 00 00 00 06 01 03 00 02 00 05
4058404: |2187310784| [INF] (192.168.3.23:502) NLTryReopenTCPSocket reason=NLTCPSend err=111
4058404: |2187310784| [INF] (192.168.3.23:502) Close socket : (state=2)
4058404: |2187310784| [ERR] (192.168.3.23:502) OpenTCPSocket failed error=115
4058405: |2187310784| [TRA] (192.168.3.23:502) Tx: [12] 00 4B 00 00 00 06 01 03 00 02 00 05
4058405: |2187310784| [INF] (192.168.3.23:502) NLTryReopenTCPSocket reason=NLTCPSend err=111
4058405: |2187310784| [INF] (192.168.3.23:502) Close socket : (state=2)
4058405: |2187310784| [ERR] (192.168.3.23:502) OpenTCPSocket failed error=115
4058405: |2187310784| [TRA] (192.168.3.23:502) Tx: [12] 00 4B 00 00 00 06 01 03 00 02 00 05
4058405: |2187310784| [INF] (192.168.3.23:502) NLTryReopenTCPSocket reason=NLTCPSend err=111
4058405: |2187310784| [INF] (192.168.3.23:502) Close socket : (state=2)
4058405: |2187310784| [ERR] (192.168.3.23:502) OpenTCPSocket failed error=115
ну тут вам скорее всего мешает опрос из MS4D. оно просто не может открыть еще один сокет. тут даже ответов от СРК нет. ну или оно там не доступно для связи...
Что касается ответа - ошибка Transaction ID - то там ответ приходит скорее всего. иначе и ошибки бы такой не было.
Вопросов стало ещё больше :)))) ...
Ну самый простой вариант, если не умеете пользоваться WireShark (к тому же его требуется запускать на машине с MS4D на том физическом интерфейсе, с которого идут запросы).
1. на ПК c MS4D выключить опрос вашего устройства, лог которого нужен.
2. на любом другом ПК установить RapidScada (web нафик не сдался, он тут не нужен). Нужен Сервер, Коммуникатор и Админка. (то есть достаточно будет установить по описанию только dotnet Desktop (Bundle на хостинг не нужен, IIS ставить не нужно)
3. Настроить там линию с вашим устройством, сделать шаблон Modbus на один регистр float или на что-то. Запустить и посмотреть лог в Статистике линии связи Коммуникатора. Он будет в hex и запросы и ответы.
5. воспользоваться этой штукой - https://rapidscada.net/modbus/
так как запросы по Modbus TCP и с учетом ошибки, тут не помогут виртуальные порты и чтение по RTU. Ибо Transaction ID это сугубо TCP-шная хрень протокола Modbus TCP.
Там же вроде ошибка отправки
Валенок, нет. это другое. На форуме RapidScada у человека было устройство, которое без смены Transaction ID вообще не работало. А здесь похоже обратное.
По идее, слейв устройство, если ему посылают xx xx должно отвечать дублируя xx xx в ответе не разбираясь. Это не задача слейва в принципе
Так до сих пор ответа никто так и не показал
Так человек не умеет пользоваться другими средствами логирования :)
Тогда как сможет чем то выцепить ответ, тогда и можно будет хоть что то сказать.
Да, пока разбираюсь.....
И вот ещё
Вложение 82774
Это значит, что плохое состояние канала, потому что нет связи.
Вообщем поигрался с настройками в MS - Таймаут, кол-во попыток, задержка запросов.....и добился положительного результата :)