Какой проблемы? Где то обещана гарантированная частота опроса?
Вид для печати
Какой проблемы? Где то обещана гарантированная частота опроса?
Ну да. Если так рассуждать, то ни кто не гарантирует работу интерфейса вообще. Как можно гарантировать работу, если не нормированы основные параметры? Если функция заявлена, и за ее наличие берутся деньги, значит она должна обеспечивать хотя бы средние параметры, на уровне переферийных устройств того же производителя. Как минимум работать стабильно.
Стабильность - это?
Так интерфейс работает, вот тема http://www.owen.ru/forum/showthread.php?t=25978 на готовые шаблоны для работы с устройствами производителя, так же нет никаких проблем при работе с устройствами других производителей. Ваша задача специфическая, одновременно "выжать" из ПР быстродействие по RS и сложный алгоритм не получится.Цитата:
Сообщение от Mike HG
Получается, только при помощи танцев с бубном. Еще раз. Проблемы начинаются при совсем несложном алгоритме (опрос двух каналов, проверка на повторяемость полученных значений, переключение пределов измерения, измерение периода опроса, вывод результатов на дисплей), когда сложность близка к изменению времени цикла с 1 мс на 2 мс. На этом уровне буквально с каждым добавляемым элементом частота опроса падает вплоть до зависания и полной остановки! Как только сложность возрастает настолько, что реле увеличивает время цикла - частота опроса восстанавливается до максимума. При дальнейшем увеличении сложности программы процесс повторяется. Можно это назвать правильной работой?
Повторяю вопрос - а где гарантировали время опроса?
За этот момент уточню.Цитата:
Сообщение от Mike HG
Вы имеете отношение к производителю? Я Вам уже ответил в посте 129.Цитата:
Сообщение от ASo
Уточнил, действительно, данная особенность присутствует, связана с внутренними механизмами автоподстройки времени цикла программы, и работы всей многозадачной системы в целом.
То есть это просто особенность, о которой тактично умалчивается и проблемой не признается? Соответственно никаких мер принимать не планируется?
а какие сложности, сперва отработайте логику программы, для этого специально введен режим симуляции, а потом уже готовый проект "обкатывайте" с внешними связями. Вы ведь не утверждаете, что запрос при одном состоянии наполнения программы не стабильныйЦитата:
Сообщение от Mike HG
Некоторые сложности имеются. Примерно так и делал. Как я уже писал, алгоритм опроса двух каналов с небольшой обработкой и отправкой команд на переключение пределов измерения модуля уже приводит к увеличению цикла на 1 мс. И при составлении и поэтапной отладке проходит все стадии от беспроблемной работы до неудовлетворительной. И вот представьте ситуацию, в предварительно отлаженный проект начинаю добавлять работу с модулем. Добавил операцию - работает нормально, добавил следующую - работает. Попутно приходится корректировать основной проект. На каком-то этапе начинаются перебои в связи. Начинаю разбираться. Естественно, что если до этого работало нормально, а добавленный фрагмент небольшой и время цикла не изменилось, то автоматом начинаю разбираться с добавленным фрагментом и с его интеграцией в проект. И небольшие изменения приводят то к улучшению, то к ухудшению ситуации, а зависимость выявить не удается. А тут еще представитель техподдержки приводит пример, что реле вполне способно работать с нужной мне скоростью и даже с запасом, при времени цикла 7 мс скорость немного падает, но в мои требования укладывается. Я то думаю, что с моими 4 мс цикла вообще все должно летать, а оно то летает, то начинает ползать. О специфической "особенности" умалчивается. Зато начинаются намеки, дескать модуль не той системы и вообще я хочу слишком много. В результате почти трех недель разбирательств докопался до сути, а оказывается да, есть такая "особенность", так и должно быть. Вот сейчас отлаженный проект с опросом попадает в неудачный диапазон. Время цикла 4 мс. Убираешь небольшую часть схемы - работает как надо, когда задействовано все, что нужно - работает на троечку. И что делать? Нагружать проект бесполезными узлами, чтобы дотянуть время цикла до 5 мс?
А почему бы и нет ? Раз уж докопались до такой особенности .Это будет быстрее ,чем ждать у моря погоды .Такова фича видать ...
Я не могу представить, о чем Вы говорите. Тот выложенный проект можно вообще не рассматривать там не понятное запоминание циклов для чего то, если это попытка некого теста, то она провалится. В нем всего две читаемых переменных видимо из трмки, а то что Вы сейчас пишите, что у Вас там даже пределы пишутся, надеюсь они по команде выставлены, а не каждый цикл записывают, не знаю можно ли считать проектом, чтение двух значений с отображением на экране, какие Вы там операции добавляете - загадка. Тем более что увеличивается цикл аж до 7мсЦитата:
Сообщение от Mike HG
когда Вам пишут про некую особенность, это испорченный телефон, возможно ваши представления с разработчиком об интервале отличается на порядок или на два, какая бы у меня программа не была, если я выставляю опрос в 50мс, то с таким интервалом он и происходит, был бы не в командировке выгрузил бы лог, с различными по объему программами, хотя конечно вру, вряд ли я напишу проект с семью миллисекундами, но на меньших временах, запросы приходили стабильно, может в новых релизах что то изменилось, но это бы подтвердили уже давно другие пользователи, а пока Вы одинЦитата:
оказывается да, есть такая "особенность", так и должно быть
В том проекте запоминание не самих циклов, а количества циклов между изменениями сетевой переменной. По количеству циклов определял период опроса. Да это был тест, но тогда задачи были еще другие. Максимальное время цикла у меня 4 мс. 7 мс делал Юрий в своих тестах. Вернетесь из командировки, могу скинуть проект со временем цикла 1 мс, на котором при опросе двух регистров float минимальный период опроса получается 160-200 мс, и периодически вообще зависает.
Период опроса задаётся в мастере и только лог снифа покажет что запросы идут как положено или нет, ещё как вариант станет ясно что это модуль не может отдавать изменившуюся информацию с такой скоростью. Нелепый подсчёт циклов здесь не поможет выяснить истинную причину
Это все верно ...но вопрос как это связано со сложностью проекта ,точнее с временем что остается под обмен , ведь особенность действительно есть и не факт что разработчики будут что то менять .это же типа не баг ,а особенность
А Вы видели реально что происходит, может как обычно тут все в одну кучу собрали, а по факту, что оно типа этого http://www.owen.ru/forum/showthread....l=1#post272050
Почему это не поможет? Все четко фиксируется и считает. Время цикла известно точно. Модуль тестировал отдельно, отдает за 20 мс. Не может же модуль зависеть от сложности программы ПР? И если с одной программой я получаю эти 20 мс, а с другой нет, то дело не в модуле. Да и Юрий подтвердил, что такая "особенность" имеет место быть. А скептики продолжают сомневаться. Или Вы тоже заинтересованы не признавать этот баг? Я считаю это именно багом. На основании того, что при незначительном изменении программы частота опроса меняется в 8 раз! И ни в одном документе эта "особенность" не описана. А техподдержка про нее не знает или скрывает.Цитата:
Сообщение от capzap
Интересно - меняется только время опроса или могут быть случаи с потерей пакетов ???
Я контролировал переменную - Статус опроса. Она всегда была в 1. Можно это считать отсутствием потерь? Были случаи 100% потери, когда опрос зависал. Тогда статус падал в 0.
Хорошо бы ОПС сервером глянуть ,там и запросы и ответы видны ...и настройки по таймерам можно всякие выставить и количество циклов ....да и режимы работы задать (мастер ,слев) ....если будут потери и они будут зависить от времени цикла ПР и настроек RS485 ,то это досадный баг ,но нужны точные подтверждения ,прямые, а не косвенные ...
У меня сейчас нет такой возможности. Итак уже потратил на отладку слишком много времени. Прибор нужно запускать в работу. До этого я не занимался на таком глубоком уровне RS-485 сетями, у меня нет никаких диагностических средств и программ, и я не умею с ними работать. Поэтому для меня проще всего использовать средства самого ПР. А вообще на каком этапе Вы предполагаете потери? Если ПР не пошлет вовремя запрос - это будет увеличение времени опроса. А когда пошлет, то устройство по любому ответит, оно-то на время цикла не завязано. Остается вариант, что ПР не сможет (не успеет) обработать этот ответ. Но это извне не увидишь. Тут как раз нужна диагностика на уровне внутренней программы.
херней Вы занимались, а не отладкой и это еще мягко сказано, кому нужны данные со скоростью 65мс, передавать на верхний уровень, так у ПР оба интерфейса 485, можно напрямую опрос делать, отображать на экране, так человеческий глаз только после 200мс начинает различать незначительные изменения, а уж отреагировать тем более бессмысленно, он же не сидит не отрываясь от экрана, программная логика остается, так и здесь всевозможные регуляторы умеют предсказывать результат по выборке за несколько периодов и отдельные всплески они всё равно будут сглаживать.Цитата:
Сообщение от Mike HG
Отдельно фраза: "ПР не сможет (не успеет) обработать этот ответ" это что вобще за бред, данные все полностью обрабатываются за цикл проекта, а запросы со слейвов приходят через несколько таких циклов
Чем бы он не занимался ,он выявил фичу ,как минимум .И разработчики ее подтвердили .То что вы говорите ,так должно быть ,но есть по другому .ТС может и не правильно выражается,делая выводы или предположения ,но здраво мыслит и находит фичи теми средствами что имеет и знает.Другие более опытные ее не выявили.Задачи есть разные и может в некоторых из них эта фича сказаться и не обязательно на глаза (мелькание).
Не надо использовать дешевое ПР как измерительное быстродействующее устройство. Для этого есть другие системы.
Я не слышал ни чего от разработчиков, Юрий передал слова и ни слова во сколько раз, не понятно что там задерживается, Тс утверждает что задержки увеличиваются в восемь раз, это запрос идёт в районе 500 мс, это можно заметить любому, а не отдельно взятому персонажу, логов не представлено, потому что их не будет, запросы как шли с валим чередом так и будут идти, а его предположения основываться на собственном чудо-коде
Потому что сами разработчики не замеряли это время ,они просто знают об этой фичи и благодаря ТС об этом узнали и другие пользователи .Как мог так и измерил ,имхо .Поднял вопрос и то спасибо ,а дальше пусть разработчики проверяют ,измеряют ,документируют это не дело пользователей (хотя могут быть помошники) .Цитата:
Сообщение от capzap
Речь не об этом только ,а о том как связана скорость обмена с временем цикла ,точнее почему она меняется не линейно , а по пиле ...Цитата:
Сообщение от ASo
а как тогда мы такие счастливчики пишем программы и ни разу не разочаровываемся что опрос идет реже чем заданный в настройках, Вас вообще не удивляет, что немножко доработать можно цикл увеличить на одну миллисекундуЦитата:
Сообщение от rovki
capzap. Вы либо невнимательно читаете тему, либо целенаправленно пытаетесь "замять" проблему и придираетесь к моим формулировкам. Для чего мне нужно такое время, я уже писал ранее. Да, для передачи на верхний уровень (ПК). И есть причины делать именно так. Фраза: "ПР не сможет (не успеет) обработать этот ответ" - прочитайте еще раз, по какому поводу я ее написал, если с первого не дошло. Самое быстрое время, которое мне удалось получить при опросе двух регистров float - 20 мс, а самое медленное - 190 мс. При этом в программу добавил всего 1 элемент и две константы. Могу выложить проекты, желающие могут проверить. Правда не факт, что на другом приборе, возможно с другой прошивкой точно совпадет. Но должно быть близко.
А почему бы и нет? У него очень быстрые входы. В других системах использую. Просто у нас эти реле применяются для многих задач и весьма успешно. Появилась новая задача, немного посложнее, но по всем расчетам посильная, вот и применили то, что хорошо знакомо и есть под руками. Опять же унификация. Кстати на предыдущей задаче тоже был подобный косяк, только в меньших масштабах. Модуль ICP опрашивается всего один канал. Должен отдавать с периодом 100 мс. Как не бился, получил только 130 мс. Грешил на модуль и оставил как есть. Надо будет проверить еще раз с учетом последних наработок.Цитата:
Сообщение от ASo
Костыли ни кто не отменял ,не об этом же речь. Не проверял ,но верю ТС - что цикл может резко увеличится вплодь до прекращения обмена .Не увеличение время обмена напрягает ,а не предсказуемость ,если она есть ...и ни какой симулятор главное не покажет это .Работает все прекрасно 50 сетевых перменных, время отклика 1 сек устраивает ,а тут внес изменение ,добавил макрос или ФБ и бац - 10сек ...кому понравиться ...Цитата:
Сообщение от capzap
Потому что оно для этого не предназначено. Просто воспримите это как данность.Цитата:
Сообщение от Mike HG
Ну здесь скорее наоборот, когда уберешь блок. Резко ухудшается, если время цикла реле уменьшается. Когда добавляешь элементы - ухудшается постепенно. А Вы проверяли, всегда ли переменные обновляются через 1000 мс? Хоть одну на выбор.
Если реле справляется с задачей, я это воспринимаю как данность. Когда не справиться, тогда посмотрим.
ну так а чего еще не выложили, однозначно Вы конкуренцию ни кому не составите и Ваши интеллектуальная собственность не пострадаетЦитата:
Сообщение от Mike HG
Пока ни кто не проявил интереса. Про интеллектуальную собственность на простенькую тестовую программу - улыбнуло. :) Вот, пожалуйста, файл под номером 3 - опрос тормозит и зависает, файл под номером 6 - период опроса 20-25 мс. Измеряется количество циклов между изменениями сетевой переменной Сн2. На экран выводится минимальное, текущее и максимальное значение, количество изменений за 1 секунду. Текущее мелькает слишком быстро, поэтому сделал запоминание крайних значений.
неплохо было бы еще написать в какой версии делали
Последняя, доступная на сайте.
Да, вроде поставил, а у модуля есть имя