1. Обязательно представиться на русском языке кириллицей (заполнить поле "Имя").
  2. Фиктивные имена мы не приветствуем. Ивановых и Пупкиных здесь уже достаточно.
  3. Не писать свой вопрос в первую попавшуюся тему - вместо этого создать новую тему.
  4. За поиск, предложение и обсуждение пиратского ПО и средств взлома - бан без предупреждения.
  5. Рекламу и частные объявления "куплю/продам/есть халтура" мы не размещаем ни на каких условиях.
  6. Перед тем как что-то написать - читать здесь и здесь, а студентам - обязательно здесь.
  7. Не надо писать в ЛС администраторам свои технические вопросы. Администраторы форума отлично знают как работает форум, а не все-все контроллеры, о которых тут пишут.

M340 и странное поведение READ_VAR

Unity Pro (Control Expert), Quantum, Premium, M340, M580, Hybrid DCS, Process Expert, Zelio, Twido, M17*, M2**, SCADAPACK, SoMachine, MachineExpert, ZelioSoft, TwidoSoft, TwidoSuite, TelePace

Модератор: Специалисты SE

Закрыто

Автор темы
dsai
здесь недавно
здесь недавно
Сообщения: 94
Зарегистрирован: 21 дек 2019, 19:49
Имя: Дмитрий
Страна: Россия
город/регион: Тамбов
Благодарил (а): 7 раз
Поблагодарили: 4 раза

M340 и странное поведение READ_VAR

Сообщение dsai »

Добрый день, уважаеммые коллеги!

Столкнулся с немного не понятной для меня проблемой, касаемой работы блока READ_VAR

Исходные данные:
Оборудование: 2 контроллера M340, 2 панели HMIGXU5512, АРМ с InTouch.

Так выклядит сеть всего этого добра.
сеть.png
Проект в панелях абсолютно идентичный, разница только в IP адрессах. Панели тянут данные с обоих контроллеров и отображают данные. АРМ соответственно делает тоже самое. А вот контроллеры по сути независимы друг от друга, но на всякий случай в контроллере №1 предусмотрена переменная, которая разрешает запускать установку, управляемую контроллером №2. То есть контроллер №2 должен читать одну единственную переменную из контроллера №1.

Естественно самый простой и надежный способ - использовать стандартный ФБ READ_VAR. Запустили, все безупречно работает. Контроллер получает разрешение и все рады.

Дабы не расписывать абсолютно все, приложу скрин кода, как это реализовано.

Кусок кода:
READ_VAR.png
Примечание.На вход EN подаем выход таймера TON. А на вход IN таймера подается его НЕ выход, таким образом циклически раз в 1 секунду даем разрешение на выполнение блока и как следствие 1 раз в секунду происходит опрос контроллера.

Суть проблемы
В течение года все превосходно работало. Контроллеры общались между собой, панели показывали данных с обоих контроллеров, арм работал и было все замечательно, до определенного момента.

Свитч, к которому подключены контроллеры и АРМ (тот, что на картинке верхний) был отключен на 2-3 дня. Связь пропала и не восстановилась. После включения свитча, АРМ данные отображает, панели видят оба контроллера. То есть связь есть. А вот READ_VAR работать перестал.

После того, как на вход/выход GEST у блока READ_VAR дал другой адресс (было %MW2900:4, заменил на %MW3900:4)- все заработало. Возращаю обратно - не работает. Указываю опять новый и отключаю свитч - связи нет, включаю свитч - связь восстанавливатеся и все работает.

Собственно вопрос. Что это такое и как это лечить?

P.S. адрес %MW2900 и далее после него точно не задействованы, то есть массив %MW2900:4 не может быть перезаписан ни чем, кроме как самим блоком READ_VAR
У вас нет необходимых прав для просмотра вложений в этом сообщении.
________________________________________________
Не так страшны первые 90% ПНР, как вторые 90% ПНР
Аватара пользователя

aranea
знаток Eplan
знаток Eplan
Сообщения: 1136
Зарегистрирован: 21 сен 2012, 22:45
Имя: aranea
Благодарил (а): 27 раз
Поблагодарили: 155 раз

M340 и странное поведение READ_VAR

Сообщение aranea »

dsai, обязательно нужно установить Timeout (GEST[3]) и использовать Activity bit (GEST[1].0) последовательно с выходом таймера по И на вход EN блока READ_VAR, чтобы если операция все еще активна не повторять запрос
Изображение

Автор темы
dsai
здесь недавно
здесь недавно
Сообщения: 94
Зарегистрирован: 21 дек 2019, 19:49
Имя: Дмитрий
Страна: Россия
город/регион: Тамбов
Благодарил (а): 7 раз
Поблагодарили: 4 раза

M340 и странное поведение READ_VAR

Сообщение dsai »

aranea писал(а): 18 сен 2020, 21:51 dsai, обязательно нужно установить Timeout (GEST[3]) и использовать Activity bit (GEST[1].0) последовательно с выходом таймера по И, чтобы если операция все еще активна не повторять запрос
Судя по всему действительно в этом дело. GEST[1].0 равен единице, если запрос выполняется? Я правильно понял?

Таймаут выставлен, забыл про это сказать.
________________________________________________
Не так страшны первые 90% ПНР, как вторые 90% ПНР
Аватара пользователя

aranea
знаток Eplan
знаток Eplan
Сообщения: 1136
Зарегистрирован: 21 сен 2012, 22:45
Имя: aranea
Благодарил (а): 27 раз
Поблагодарили: 155 раз

M340 и странное поведение READ_VAR

Сообщение aranea »

F1 писал(а):Activity Bit
This bit indicates the execution status of the communication function.
It is set to 1 when launched and returns to 0 when its execution is complete.

Timeout
Timeout determines the maximum waiting time for the response. The time base for this parameter is 100 ms (the value 0 corresponds to an infinite waiting value).
Изображение

Автор темы
dsai
здесь недавно
здесь недавно
Сообщения: 94
Зарегистрирован: 21 дек 2019, 19:49
Имя: Дмитрий
Страна: Россия
город/регион: Тамбов
Благодарил (а): 7 раз
Поблагодарили: 4 раза

M340 и странное поведение READ_VAR

Сообщение dsai »

aranea писал(а): 18 сен 2020, 22:00
F1 писал(а):Activity Bit
This bit indicates the execution status of the communication function.
It is set to 1 when launched and returns to 0 when its execution is complete.

Timeout
Timeout determines the maximum waiting time for the response. The time base for this parameter is 100 ms (the value 0 corresponds to an infinite waiting value).
Огромное спасибо, картинка сошлась.

изначально стоял 0 в таймауте (это уже сейчас он выставлен у меня), в итоге ответ ожидался с того момента, как связь пропала, соответственно новые запросы не выполнялись.
________________________________________________
Не так страшны первые 90% ПНР, как вторые 90% ПНР

Iskander19981717
здесь недавно
здесь недавно
Сообщения: 30
Зарегистрирован: 05 янв 2020, 00:14
Имя: Искандер
Страна: Россия
Благодарил (а): 2 раза

M340 и странное поведение READ_VAR

Сообщение Iskander19981717 »

Добрый день, есть тут еще люди?

Автор темы
dsai
здесь недавно
здесь недавно
Сообщения: 94
Зарегистрирован: 21 дек 2019, 19:49
Имя: Дмитрий
Страна: Россия
город/регион: Тамбов
Благодарил (а): 7 раз
Поблагодарили: 4 раза

M340 и странное поведение READ_VAR

Сообщение dsai »

aranea писал(а): 18 сен 2020, 22:00
F1 писал(а):Activity Bit
This bit indicates the execution status of the communication function.
It is set to 1 when launched and returns to 0 when its execution is complete.

Timeout
Timeout determines the maximum waiting time for the response. The time base for this parameter is 100 ms (the value 0 corresponds to an infinite waiting value).
Снова появилась такая же проблема. При этом после Вашего комментария сделал, чтобы запрос не выполнялся, если бит активности показывает, что выполняется запрос и принудительно в начале каждого цикла программы в GEST[3] (таймаут) прописываю значение в 200мс (после выполнения блока в данный параметр записываются какие-то другие значения, поэтому принудительно сбрасываю). Блок снова впал в ступор и не производит опрос (при этом бит активности показывает, что опроса не выполняется). Пришлось использовать "костыль". Панель читает переменную с 1ого ПЛК и пишет ее во 2ой. Но вопрос остается открытым, так как аналогичный блок читает по 485 интерфейсу с УПП информацию и там наблюдается картинка абсолютно такая же.

Где я делаю что-то не правильно?
________________________________________________
Не так страшны первые 90% ПНР, как вторые 90% ПНР

Iskander19981717
здесь недавно
здесь недавно
Сообщения: 30
Зарегистрирован: 05 янв 2020, 00:14
Имя: Искандер
Страна: Россия
Благодарил (а): 2 раза

M340 и странное поведение READ_VAR

Сообщение Iskander19981717 »

Добрый день, есть вопрос касаемо массива, который нужно передать в Gest, почему в описании говорится что это массив типа INT и там лежат биты состояния обмена, если это массив Tab_Gest ARRAY [1..4], то что будет значить запись Tab_Gest[1].0, к чему мы обращаемся? Что из этого слово состояния, а что из этого бит состояния? В двоичной системе Tab_Gest[1].0 будет выглядеть так 2#0000_0000_0000_0000, что из этого есть что? 2#0000_0000_0000_0000 этот последний бит отвечает за процесс обмена? как к нему обратиться, если переменная типа INT?
У вас нет необходимых прав для просмотра вложений в этом сообщении.

ogorsv
завсегдатай
завсегдатай
Сообщения: 569
Зарегистрирован: 02 дек 2015, 06:57
Имя: Огородников Сергей
Страна: РФ
Благодарил (а): 110 раз
Поблагодарили: 102 раза

M340 и странное поведение READ_VAR

Сообщение ogorsv »

Добрый день, Искандер!

1. Прочитайте, пожалуйста, правила форума - в самом начале страницы
Дублирование сообщений приравнивается к спаму. Как и флуд "есть тут еще люди?"

2. Tab_Gest ARRAY [1..4] - лучше, всё-таки, использовать Tab_Gest ARRAY [0..3]
Иногда функции отказываются работать с массивами, индекс которых начинается не с нуля

3. Tab_Gest[1].0 (или в моём случае - Tab_Gest[0].0) - это обращение к нулевому биту самого первого слова массива Tab_Gest ARRAY

Что из этого слово состояния, а что из этого бит состояния? После точки - бит, в скобках - слово

4. 2#0000_0000_0000_0000 - самый правый бит индицирует активность функции
Обратиться к нему так, как написано в п.3 - Tab_Gest[0].0

Отправлено спустя 6 минут 19 секунд:
dsai писал(а): 17 май 2021, 12:54 принудительно в начале каждого цикла программы в GEST[3] (таймаут) прописываю значение в 200мс (после выполнения блока в данный параметр записываются какие-то другие значения, поэтому принудительно сбрасываю)
1. Проверьте, не считаете ли вы четвёртый элемент за третий?
Если %MW380:4, то таймаут писать нужно в %MW382

2. в %MW383 будут отображаться количество принятых/отправленных байтов - проверьте

3. Каждый вызов можно не писать значения таймаута - кто их переписывает в программе? Можно сделать однократно при запуске ПЛК

4. Выкладывайте схемы/части кода, когда задаёте вопрос - проще сразу посмотреть, чем листать всю тему, да к тому же, что-то уже могло измениться
СВ

Iskander19981717
здесь недавно
здесь недавно
Сообщения: 30
Зарегистрирован: 05 янв 2020, 00:14
Имя: Искандер
Страна: Россия
Благодарил (а): 2 раза

M340 и странное поведение READ_VAR

Сообщение Iskander19981717 »

ogorsv, спасибо за ответ, не хотел флудить, нашел такую запись Tab_Gest[0]=0 и Tab_Gest[1]=1, то есть мы в элементы массива записываем значения, которые при переводе в двоичную у Tab_Gest[0]=0 будет (2#0000_0000_0000_0000), Tab_Gest[0]=2 будет (2#0000_0000_0000_0010)
а у Tab_Gest[1]=1 (16#01) правильно ли я понял?

ogorsv
завсегдатай
завсегдатай
Сообщения: 569
Зарегистрирован: 02 дек 2015, 06:57
Имя: Огородников Сергей
Страна: РФ
Благодарил (а): 110 раз
Поблагодарили: 102 раза

M340 и странное поведение READ_VAR

Сообщение ogorsv »

Tab_Gest[0]=1 - это значение в десятичной, 2#0000_0000_0000_0001 в двоичной, 16#01 в шестнадцатеричной.
То же, что и Tab_Gest[0].0

Tab_Gest[0]=2 - это значение в десятичной, 2#0000_0000_0000_0010 в двоичной, 16#02 в шестнадцатеричной
То же, что и Tab_Gest[0].1
СВ
Закрыто

Вернуться в «ПЛК»