Хотя память и ресурсы ПР200 заняты на 20%....
Вложение 45912
Вид для печати
Хотя память и ресурсы ПР200 заняты на 20%....
Вложение 45912
Т.е. получается пока макрос не завершит свой цикл, программа ждет?
А какие именно настройки?
в контроллерах и ПР нет многозадачности. В данном случае нет разделения макрос и программа, макрос это часть программы, в качестве примера это как обед, пищу принимают по порядку первое, второе и компот, так вот макрос это тарелка второго, а обед это программа, после того как программа выполнилась, записываются выхода, затем считываются входа и опять выполняется программа со всеми своими макросами
Т.е. согласно Вашим же словам и получается, что пока я "обед" не съем - "компота" на видать? Если в макросе есть циклические связи (а они наверняка есть), то вполне может получится, что "обед" затянется..... А на счет много задачности - возможно Вы и правы, в ПР точно не должно быть многозадачности...
Изменил все временные интервалы, менял по разному - эффекта нет... Сейчас переписываю программу без макросов... Циклические связи как то могут вносить корректировку по временным интервалам? И все равно не очень понятно... если в среднем один цикл = 10мс... то в секунду наша программа повторится 100 раз... даже если будет 50 раз повторяться программа - не должно быть задержек таких больших....
циклы типа FOR | WHILE в ПР не реализованы, все выполняется один раз. Влияние циклической связи проявиться уже в следующем цикле контроллера
Не нужно менять по разному, нужно вдумчиво понимать как происходит обмен. В модулях МВ/МУ проверить и уменьшить до минимума время ответа, проверить только на модуле вывода, какая длина линии связи, модули подключены последовательно?
Судя по симптомам, что без макросов связь норма, значит при увеличении цикла или идут перезапросы к модулям что соответственно увеличивает время реакции, или действительно так долго происходит запись всех регистров, но на 10 мс цикла что-то не верится.
Время меняли не бездумчиво... ставились и большие временные интервалы и маленькие - не было разницы... Вот по поводу перезапросов я тоже думал... что каждый макрос вызывает процедуру опроса датчиков и выходов... и тога вполне понятно почему происходят такие задержки... Как перепишу все без макросов - отпишусь....
Если с ПР ушел бит включения по 485 и панель его быстро увидела, а модуль сработал не сразу, то причем тут ПР с программой? Явно модули тормозят.
А, сейчас вспомнил, что они на разных портах. Задержка между портами? Неужели так может быть? Я бы осциллографом полез проверять.
без проекта бессмысленно вообще разговаривать, просить помощи в решении проблемы
Я так понимаю, что датчик привинчен к МВ, а реле -- к МУ? Но тогда между срабатыванием датчика и срабатыванием реле как минимум 1 цикл, насколь я понимаю. Вообще, кмк, неплохо было бы для начала определить точное время цикла, раз уж программа такая тяжёлая. Был где-то макрос, позволяющий это сделать. Или действительно сниффером послушать. А определив время цикла, от этого уже плясать и устанавливать периоды опроса. А тайм-аут ответа -- побольше.
А он вызывает? В сетевых переменных использованы поля "запуск чтения" и "запуск записи"?Цитата:
каждый макрос вызывает процедуру опроса датчиков и выходов
Подключено именно так: Датчики к МВ, реле к МУ. Вот и я понимаю что один цикл между изменениями... даже если 2-5 цикла... это где-то 50 раз в секунду... Но.... жизненные реалии совсем другие.... сегодня займусь анализом цикла... макрос уже нашел для подсчета времени цикла... буду смотреть какие именно временные интервалы и что происходит...
Установлена галка "Запись по изменению"...
Почитал последние посты - какие-то дебри!
roman_1986,
Никаких опросов/ записей сетевых переменных в середине цикла выполнения программы, а тем более в макросах НЕ ПРОИСХОДИТ!Цитата:
Вот по поводу перезапросов я тоже думал... что каждый макрос вызывает процедуру опроса датчиков и выходов... и тога вполне понятно почему происходят такие задержки... Как перепишу все без макросов - отпишусь....
ПР работает строго циклически
1. читаются физические входы и входные сетевые переменные
2. значения полученные в п.1 запоминаются в буфере и до конца цикла используются в программе в не измененном виде Даже если состояние входа изменилось, то ПР узнает об этом только в следующем цикле
3. Выполняется ВСЯ программа на холсте, включая ВСЕ макросы.
4. Новые значения ВСЕХ внутренних и сетевых переменных запоминаются в буфере.
5. Происходит запись значений полученных в п.4 в физические выходы
6. Выполняется внутренние процедуры сетевого обмена(запросы чтения или записи)
далее все повторяется с п.1
Перестаньте извращаться над ПР, не нужно делать период опроса 20мс! Вы не даете ПР "вздохнуть" ПР не успевает обрабатывать ответы на запросы! Оставьте значение "по умолчанию" - 100мс, время реакции системы возрастет - не будет 1,5 секунды, а будет 0,1 сек.
И самое главное - зачем Вы читаете из МВ110 по два регистра и соответственно пишете по два регистра в МУ110?
Мастер в ПР не умеет делать групповые запросы и будет делать четыре отдельных запроса - два на чтение из МВ110 и два на запись в МУ110. И то, если в настройках сетевых переменных Вы отключили чтение для МУ110 иначе ПР еще будет делать два запроса на чтение из МУ100, а зачем это?
Я рекомендую читать и писать для модулей сразу по два регистра (DWORD), для них будет выполнятся по одному запросу!
ВВОД_32
Вложение 45929
1. Период опроса - 100мс
2. читаем сразу два регистра с адреса 99
3. функции записи - НЕТ.
ВЫВОД_32
Вложение 45930
1. Включаем галку "Запись по изменению"
2. Период опроса в этом случае - не имеет значения, т.к. запись будет однократная - только по факту изменения значения.
3. Пишем сразу два регистра с адреса 97
4. функция записи -0х10,
5. функции чтения - НЕТ
Обнаружил еще одну ошибку в последнем ОЛ, ну и раньше я думаю она была. если установить сетевую переменную на рабочее поле, а потом изменить ее название не в перечне переменных, а через "настройку прибора" то в списке переменных она название поменяет, а на рабочем поле останется со старым именем, при этом будет совершенно работоспособна. чтобы поменять отображаемое имя эту переменную над заменить на любую другую, а потом снова на нужную но обязательно с применением изменений каждый раз.
Сегодня на другом компьютере открыл большой проект. Гляжу, а у логического И один вход никуда не подключен... Точно знаю, что проект рабочий и я в нем ничего не менял. Запустил эмуляцию и, о чудо! На обоих входах лог.1. Значит связь есть, но она просто не отображается. Подвигал элемент, масштаб несколько раз менял - без толку, связь не видна, как будто вход никуда не подключен...
Чтобы восстановить видимость связи я удаляю старую невидимую и вновь протягиваю связь! Если удалить(выделить) старую невидимую не получается можно удалить вместе с элементом!
Такое(невидимость связи) получается при перемещении элемента с протянутой к нему связью, короче, чтобы такого не возникало, сначала перемещайте элемент, а затем протягивайте связь и горя знать не будете!
з.ы. добавьте возможность в макросах использования системных переменных.
А то для Года, Месяца и т.д. надо создавать входа. Ну ведь просится же ?
Кстати я бы добавил и возможность как-то использовать и сетевые переменные, ну это ладно....
Нет всё таки глюк, по крайней мере, с AND. Заметил ещё на пред. сборкеВложение 45999
RockTeal, Логическая единица на неподключенных входах AND -- это абсолютно нормальная ситуация, и это есть у других производителей программируемых реле. Иначе любой неподключенный вход попросту заблокировал бы этот AND. Кста, а зачем оставлять неподключенными входы AND, когда их всего 2 штуки?
Ollema это нормально. Например у некоторых производителей нет И на 2 входа, сразу на 4. А вам нужно 2, чтобы не лепить к каждому свободному лог 1, так специально запрограммировано.
для ИЛИ свободные входы будут всегда лог 0 например.
з.ы. это программа а не КМОП, здесь предусматриваются такие ситуации.
Щас прям ностальгическую слезу смахнул, вспомнив времена, когда не было этих ваших ПРок, а были сплошь 176 и 155 серии. Понятно, что у логики в "железном" исполнении неиспользуемые выводы сажаются либо на общий, либо на питание. В программной модели это необязательно, ибо с эфира там ничего не прилетит.
Я по первости сажал на ноль и в OL ;)
Некоторые для формирования "1" ставят в программе элемент "не" с "оторванным" входом, что мне кажется просто какой-то дикостью! Я предпочитаю константу для таких случаев!
Угу, видывал и такое буквально сегодня, хыхыхы! Оборванный инвертор с TON использовался как детектор включения питания ПР. И да, сам в таких случая предпочитаю константы.
Если после включения при первом цикле ПР на выходе элемента "не" с "оторванным" входом логическое "0", то это неправильно и лишний раз доказывает, что так не нужно делать(оставлять элементы с неподключенными входами! И это легко сделать с помощью константы логической "1" и линии задержки на цикл!
На первом цикле константа даёт 1. А вот, так сказать, в "нулевом" цикле, до включения питания -- не даёт. Поэтому линия задержки на цикл в первом цикле выдаёт 0. Ежели задержки на цикл недостаточно, используем TON, который будет =0 на протяжении времени своей выдержки.
в электронных элементах неопределенное состояние на выходе это нормально, но здесь программирование, если переменная/элемент не инициализированы то его начальное состояние ноль/фальш, но константа должна инициализироваться перед запуском программы тем значением которое установлено в проекте. По факту, вы оба рекомендуете действительно ошибочный вариант, а если его исправят?