Разброс во времени опроса по RS-485.

[Mike HG]

Некоторые сложности имеются. Примерно так и делал. Как я уже писал, алгоритм опроса двух каналов с небольшой обработкой и отправкой команд на переключение пределов измерения модуля уже приводит к увеличению цикла на 1 мс. И при составлении и поэтапной отладке проходит все стадии от беспроблемной работы до неудовлетворительной. И вот представьте ситуацию, в предварительно отлаженный проект начинаю добавлять работу с модулем. Добавил операцию - работает нормально, добавил следующую - работает. Попутно приходится корректировать основной проект. На каком-то этапе начинаются перебои в связи. Начинаю разбираться. Естественно, что если до этого работало нормально, а добавленный фрагмент небольшой и время цикла не изменилось, то автоматом начинаю разбираться с добавленным фрагментом и с его интеграцией в проект. И небольшие изменения приводят то к улучшению, то к ухудшению ситуации, а зависимость выявить не удается. А тут еще представитель техподдержки приводит пример, что реле вполне способно работать с нужной мне скоростью и даже с запасом, при времени цикла 7 мс скорость немного падает, но в мои требования укладывается. Я то думаю, что с моими 4 мс цикла вообще все должно летать, а оно то летает, то начинает ползать. О специфической "особенности" умалчивается. Зато начинаются намеки, дескать модуль не той системы и вообще я хочу слишком много. В результате почти трех недель разбирательств докопался до сути, а оказывается да, есть такая "особенность", так и должно быть. Вот сейчас отлаженный проект с опросом попадает в неудачный диапазон. Время цикла 4 мс. Убираешь небольшую часть схемы - работает как надо, когда задействовано все, что нужно - работает на троечку. И что делать? Нагружать проект бесполезными узлами, чтобы дотянуть время цикла до 5 мс?

[capzap]

Некоторые сложности имеются. Примерно так и делал. Как я уже писал, алгоритм опроса двух каналов с небольшой обработкой и отправкой команд на переключение пределов измерения модуля уже приводит к увеличению цикла на 1 мс. И при составлении и поэтапной отладке проходит все стадии от беспроблемной работы до неудовлетворительной. И вот представьте ситуацию, в предварительно отлаженный проект начинаю добавлять работу с модулем. Добавил операцию - работает нормально, добавил следующую - работает. Попутно приходится корректировать основной проект. На каком-то этапе начинаются перебои в связи. Начинаю разбираться. Естественно, что если до этого работало нормально, а добавленный фрагмент небольшой и время цикла не изменилось, то автоматом начинаю разбираться с добавленным фрагментом и с его интеграцией в проект. И небольшие изменения приводят то к улучшению, то к ухудшению ситуации, а зависимость выявить не удается. А тут еще представитель техподдержки приводит пример, что реле вполне способно работать с нужной мне скоростью и даже с запасом, при времени цикла 7 мс скорость немного падает, но в мои требования укладывается. Я то думаю, что с моими 4 мс цикла вообще все должно летать, а оно то летает, то начинает ползать. О специфической "особенности" умалчивается. Зато начинаются намеки, дескать модуль не той системы и вообще я хочу слишком много. В результате почти трех недель разбирательств докопался до сути, а оказывается да, есть такая "особенность", так и должно быть. Вот сейчас отлаженный проект с опросом попадает в неудачный диапазон. Время цикла 4 мс. Убираешь небольшую часть схемы - работает как надо, когда задействовано все, что нужно - работает на троечку. И что делать? Нагружать проект бесполезными узлами, чтобы дотянуть время цикла до 5 мс?

Я не могу представить, о чем Вы говорите. Тот выложенный проект можно вообще не рассматривать там не понятное запоминание циклов для чего то, если это попытка некого теста, то она провалится. В нем всего две читаемых переменных видимо из трмки, а то что Вы сейчас пишите, что у Вас там даже пределы пишутся, надеюсь они по команде выставлены, а не каждый цикл записывают, не знаю можно ли считать проектом, чтение двух значений с отображением на экране, какие Вы там операции добавляете - загадка. Тем более что увеличивается цикл аж до 7мс

оказывается да, есть такая "особенность", так и должно быть

когда Вам пишут про некую особенность, это испорченный телефон, возможно ваши представления с разработчиком об интервале отличается на порядок или на два, какая бы у меня программа не была, если я выставляю опрос в 50мс, то с таким интервалом он и происходит, был бы не в командировке выгрузил бы лог, с различными по объему программами, хотя конечно вру, вряд ли я напишу проект с семью миллисекундами, но на меньших временах, запросы приходили стабильно, может в новых релизах что то изменилось, но это бы подтвердили уже давно другие пользователи, а пока Вы один

[rovki]

А почему бы и нет ? Раз уж докопались до такой особенности .Это будет быстрее ,чем ждать у моря погоды .Такова фича видать ...

[Mike HG]

В том проекте запоминание не самих циклов, а количества циклов между изменениями сетевой переменной. По количеству циклов определял период опроса. Да это был тест, но тогда задачи были еще другие. Максимальное время цикла у меня 4 мс. 7 мс делал Юрий в своих тестах. Вернетесь из командировки, могу скинуть проект со временем цикла 1 мс, на котором при опросе двух регистров float минимальный период опроса получается 160-200 мс, и периодически вообще зависает.

[capzap]

Период опроса задаётся в мастере и только лог снифа покажет что запросы идут как положено или нет, ещё как вариант станет ясно что это модуль не может отдавать изменившуюся информацию с такой скоростью. Нелепый подсчёт циклов здесь не поможет выяснить истинную причину

[Mike HG]

Период опроса задаётся в мастере и только лог снифа покажет что запросы идут как положено или нет, ещё как вариант станет ясно что это модуль не может отдавать изменившуюся информацию с такой скоростью. Нелепый подсчёт циклов здесь не поможет выяснить истинную причину

Почему это не поможет? Все четко фиксируется и считает. Время цикла известно точно. Модуль тестировал отдельно, отдает за 20 мс. Не может же модуль зависеть от сложности программы ПР? И если с одной программой я получаю эти 20 мс, а с другой нет, то дело не в модуле. Да и Юрий подтвердил, что такая "особенность" имеет место быть. А скептики продолжают сомневаться. Или Вы тоже заинтересованы не признавать этот баг? Я считаю это именно багом. На основании того, что при незначительном изменении программы частота опроса меняется в 8 раз! И ни в одном документе эта "особенность" не описана. А техподдержка про нее не знает или скрывает.

[rovki]

Это все верно ...но вопрос как это связано со сложностью проекта ,точнее с временем что остается под обмен , ведь особенность действительно есть и не факт что разработчики будут что то менять .это же типа не баг ,а особенность

[capzap]

А Вы видели реально что происходит, может как обычно тут все в одну кучу собрали, а по факту, что оно типа этого http://www.owen.ru/forum/showthread....l=1#post272050

[rovki]

Интересно - меняется только время опроса или могут быть случаи с потерей пакетов ???

[Mike HG]

Я контролировал переменную - Статус опроса. Она всегда была в 1. Можно это считать отсутствием потерь? Были случаи 100% потери, когда опрос зависал. Тогда статус падал в 0.