Ответы в темах
-
Записи
-
График строится либо по минутным, либо по часовым данным в зависимости от запрашиваемого периода.
какой период задается, чтобы показать часовые данные?
Вот как собственно выглядит проблема:
Не понятно что за оборудование
конечно можно разнести по панелям, но это занимает место.
тут может быть до 30 шт.как я понял тут
value = cnlNum
metric = cnlNumа можно в качестве metric использовать cnlName (название канала), есть компоненты которые использует metric
Вывел 15 сигналов по шаблону,
время: данные за последний 5 минут (чтобы меньше загрузить, так ли это?)
время обновления: 1 сек (для краш-теста)Полет нормальный, но время от времени данные исчезает и появляется обратно через пару секунд
Параметры Data Packing всегда стояли по нулям?
Особенно Packing length и Force transmitда, мы их не трогали
пробовали
Force transmit = 100
не помоглоНа мой взгляд, если всё «на столе», то надо работать в режиме RealCOM, чтобы уменьшить количество комбинаций.
прямой опрос (MOXA/RealCOM) через виртуальный COM провалился (порт открыт) и через RS и через штатный.
Насчет проводов, тут ТРМ138 RS485 двухпроводной, без вариантов 3, 4
NPort IA5250A, прошивка свежий 1.4 Build 19032122
Если переключить на АС4 опрос идет
baur, покажите вкладку operation settings.
То что у Вас там Master, это к соединению PairConnection и к Вашему случаю отношения не имеет. Естественно так работать не будет.я использую эти режимы ничего не меняя
Если DB9, то там нестандартная распайка проводов. Проверьте очень внимательно по мануалу.
тогда как объясняется корректные ответы время от времени, если изначально неправильная распайка?
Если на столе пошел шум, значит проблемы в настройках Moxa
там задействован соседний порт, там опрос идет (потеря данных 20%) нормально, оборудование другое (конвейерные весы)
Порт может не открываться если уже занят.
мы подбирали порты где не отмечены In Use
почему то все порты (виртуальные) от 3 до 20 In Use, хотя явно нигде не используетсяПокажите вкладку Operation Settings в Moxa.
там мы ничего не меняли просто перевели в TCP Master, хотя я до этого менял ForceTransmit на 100, не помогло
обратно перевел в RealCOM когда уже пробовал маппинг
в итоге через TCP опрос идет, но с огромной потерями
СОМ не открывается (это уже проблема компьютера)А кстати FF у вас в начале ?
сеанс завершен, уже не могу посмотреть, но судя по предыдущим логам FF в основном в начале, вот примеры
Receive (5/5): FF FF 10 04 04
Receive (5/5): FF FF FE FF FF
Receive (5/5): FF DF FF FF FF
Receive (5/5): CF FF FF FF FFкстати там прошивка 1.3, на сайте 1.4
пункт Bug Fix
Pair connection mode cannot resolve the domain name.у нас задействованы обе порта
теперь попробуем через МОХА — виртуальный СОМ и ТСР но рядом без промежуточных коммутаторов
опросили напрямую через МОХА (на месте), опять пошли шум в виде FFFF и т.д.
опросили по TCPхотели через виртуальный СОМ, но почему то СОМ порты до 20 чем то заняты (in use) поэтому привязал к СОМ21, а тут RapidSCADA по умолчанию показывает до СОМ10, СОМ21 прописал вручную в итоге порт не открывается
штатная программа увидел порт СОМ21 но тоже не открывается
Вы удаленно пробовали через разные варианты Виртуальных COM портов родным ПО ?
опросили через RapidSCADA (физический COM), настройки по документации.
подбирали разные скорости Boud rate не трогая остальные, не получается
теперь попробуем через МОХА — виртуальный СОМ и ТСР но рядом без промежуточных коммутаторов
сегодня удалось опросить ТРМ напрямую (на месте) через RapidSCADA, потеря данных 0%, все работает, так что кабель исключается
получается пакеты теряется где то по пути через Ethernet?
надо включить псевдо-аппартное управление потоком
Источник: Аппаратный протокол управления потоком RTS/CTS — использует дополнительно два провода в кабеле, а не передачу специальных символов по линиям данных
получается требуется еще 2 кабеля? ТРМ138 там нету дополнительного выхода
