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

[Алексеев]

Собственно что кому не нравится ? обмен по сети всегда медленнее цикла программы будет. Не пойму вообще о чем спор. Надо быстрее получать данные с датчиков где-то, применяйте другое оборудование, тут собственно Овеном даже пахнуть не будет...

Я тоже не понимаю . Но уже 25 страниц в теме .

[Одесса]

Собственно что кому не нравится ? обмен по сети всегда медленнее цикла программы будет. Не пойму вообще о чем спор. Надо быстрее получать данные с датчиков где-то, применяйте другое оборудование, тут собственно Овеном даже пахнуть не будет...

На 100% согласен. Но хочу добавить,что дело не в ПР. А,чтобы Овном пахло ,дело за малым. ВУ должно последние обработанные
данные вытаскивать из буфера(даже если идёт процесс обработки и новые данные ещё не готовы) и немедленно отдавать их
мастеру. Только и всего.

[Ревака Юрий]

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

Про особенность я узнал от Вас, уточнил у программистов алгоритм и действительно ли может что-то подобное проявляться, мне ответили положительно. Но так как кроме обмена по интерфейсу необходимо еще обслуживать логику, дисплей вх/вых и т.д то я не считаю это проблемой или неисправностью, видимо на этапе ТЗ были заданы определенные приоритеты, и для Вашей задачи, приоритет нужен для модбас. Но увеличение приоритета для модбас, приведет к другим последствиям, это мое личное мнение. Можно обратиться официально, разве кто-то Вам запрещает, но мне кажется если проборов продано очень большое количество , и только сейчас возник этот момент, то это проблема правильного выбора оборудования для конкретной задачи. Это опять таки мое личное мнение.

[Mike HG]

Посмотрите пост 26. Это по Вашему один эксперимент? Тогда я не знаю,что такое два эксперимента. Юрий проделал колоссальную
работу ,но ради целей описанных мной в предыдущем посте.

В моем понимании это был один эксперимент, или изыскание. Первая часть - установление минимально достижимого периода опроса, можно считать выполненной, хотя на пустом проекте, где кроме опросов нет ничего, ценность результата снижается. Вторая часть - оценка влияния нагрузки на период опроса. И вот здесь и вылез подвох. Показанный Юрием результат выглядел хорошо и дал мне уверенность, что возможностей ПР для моих задач вполне хватает. А при конкретной реализации процесс пошел не так и пришлось затратить довольно много времени, чтобы вытащить на свет эту "особенность". А вообще это изыскание надо было проделать на этапе испытаний и результаты указать в технических характеристиках. А в описании указать, от чего может зависеть период опроса. Тогда сразу было бы понятно - для каких задач ПР подходит, а для каких нет. Это было бы честно по отношению к потребителям. И подобных вопросов и претензий не возникало бы. Но тут опять мешает "особенность". Ведь за заявленные ТХ нужно отвечать. Как указывать полученные Юрием 40 мс при времени цикла 7 мс, если при 1 мс может получиться более 100? А указывать минимальные результаты или описывать особенности - будет некрасиво. Поэтому и промолчали.

[Алексеев]

Сергей и кто эту теме поднял и естественно все участники .
Естественно нужно официальное обращение . Я естественно поддержу если приоритет
по модбасу будет не в ущерб и проекты которые рабочие будут не сбоить .
И программисты железа (это не программисты ОЛ) должны быть уверены на 100% что это не повредит всему остальному.

[Mike HG]

Может и не обязательно делать приоритет? Даже если цикл 10-15 мс, не так уж это и много. Главное, чтобы период опроса не гулял от сложности проекта. Я уже озвучивал вариант, что для работы с интерфейсами нужно не выкраивать остатки времени от остальных задач, а выделять столько, сколько нужно для работы без тормозов. Если остатков не хватает, добавлять 1 мс времени цикла. По моему это гораздо проще и точно ни чему не повредит.

[capzap]

в ОЛ нет условных переходов, время затраченное на работу со всеми элементами можно просчитать легко, но раз пишется среднее время, значит к расчетам прибавляется время на обмен с экраном, на обмен с RS485. И следует помнить, что в умных книжках пишут: "при нескольких источниках запросов прерывание становится разделяемым ресурсом, использование которого может привести к нестабильности длительности цикла выполнения программы". Нестабильность ведь не одно и тоже что прямая зависимость от увеличения блоков, может разработчики соглашались на джиттер, а не то что обозначено заглавием темы, кстати можно было бы к примеру указать процент используемых блоков для той или иной ситуации, а не просто говорить что цикл вот-вот перейдет к следующему значению, потому что разброс времени цикла может перекрывать ближайшие ситуации

[Одесса]

в ОЛ нет условных переходов, время затраченное на работу со всеми элементами можно просчитать легко, но раз пишется среднее время, значит к расчетам прибавляется время на обмен с экраном, на обмен с RS485. И следует помнить, что в умных книжках пишут: "при нескольких источниках запросов прерывание становится разделяемым ресурсом, использование которого может привести к нестабильности длительности цикла выполнения программы". Нестабильность ведь не одно и тоже что прямая зависимость от увеличения блоков, может разработчики соглашались на джиттер, а не то что обозначено заглавием темы, кстати можно было бы к примеру указать процент используемых блоков для той или иной ситуации, а не просто говорить что цикл вот-вот перейдет к следующему значению, потому что разброс времени цикла может перекрывать ближайшие ситуации

Красиво излагаетe. Только неизвестно ,тогда зачем в это ПР влупили STM 32. Если в ОЛ нет условных переходов,то в микро
программе микропроцессора это не проблема. При тактовой частоте 160 МГц для этого процессора плевое дело и клавиши обс
луживать и дисплей и интерфейс даже не прибегая к прерываниям и условным переходам. ПР заточено изначально ёлочные Гир
лянды переключать, а не обслуживать сети. Обратите внимание,что даже АЦП туда воткнули 10 разрядный. Так на всякий случай
Вдруг и правда,кому то взбредёт в голову что то измерять. А тут оба- нашлись индивидуумы ,измерять начали. Тогда посадили
грамотного Реваку,чтоб макросы проталкивал супер-пуперовские,которые линейность высшей математикой выравнивают.
По большому счету никакого криминала в данной ситуации не нахожу. Паровоз с рельс не сошел. Ну столкнулся дядя с ситуа
цией,ну и что? Если б не столкнулся никто об этом не знал и прекрасно ёлочные гирлянды и дальше переключали.
PS. Только,что сходил на Ровкину ветку. В натуре гирлянды забабахал. Только от затеи с
ПР отказался,потому,что оно медленное.

[Филоненко Владислав]

Красиво излагаетe. Только неизвестно ,тогда зачем в это ПР влупили STM 32. Если в ОЛ нет условных переходов,то в микро
программе микропроцессора это не проблема. При тактовой частоте 160 МГц для этого процессора плевое дело и клавиши обс
луживать и дисплей и интерфейс даже не прибегая к прерываниям и условным переходам. ПР заточено изначально ёлочные Гир
лянды переключать, а не обслуживать сети. Обратите внимание,что даже АЦП туда воткнули 10 разрядный. Так на всякий случай
Вдруг и правда,кому то взбредёт в голову что то измерять. А тут оба- нашлись индивидуумы ,измерять начали. Тогда посадили
грамотного Реваку,чтоб макросы проталкивал супер-пуперовские,которые линейность высшей математикой выравнивают.
По большому счету никакого криминала в данной ситуации не нахожу. Паровоз с рельс не сошел. Ну столкнулся дядя с ситуа
цией,ну и что? Если б не столкнулся никто об этом не знал и прекрасно ёлочные гирлянды и дальше переключали.
PS. Только,что сходил на Ровкину ветку. В натуре гирлянды забабахал. Только от затеи с
ПР отказался,потому,что оно медленное.

Приходите к нам работать, такие гениальные программисты нам нужны!

[rovki]

Приходите к нам работать, такие гениальные программисты нам нужны!

Шутить надо аккуратней