Про особенность я узнал от Вас, уточнил у программистов алгоритм и действительно ли может что-то подобное проявляться, мне ответили положительно. Но так как кроме обмена по интерфейсу необходимо еще обслуживать логику, дисплей вх/вых и т.д то я не считаю это проблемой или неисправностью, видимо на этапе ТЗ были заданы определенные приоритеты, и для Вашей задачи, приоритет нужен для модбас. Но увеличение приоритета для модбас, приведет к другим последствиям, это мое личное мнение. Можно обратиться официально, разве кто-то Вам запрещает, но мне кажется если проборов продано очень большое количество , и только сейчас возник этот момент, то это проблема правильного выбора оборудования для конкретной задачи. Это опять таки мое личное мнение.
Последний раз редактировалось Андрей Посохов; 11.10.2018 в 18:05.
С уважением, Ревака Юрий.
Инженер группы технической поддержки компании "ОВЕН"
e-mail: yu.revaka@owen.ru
Шаблон описания ошибки ПР или OL http://ftp-ow.owen.ru/softupdate/OWE...s/Shablon.docx
Видео уроки по ПР200 и OWEN Logic http://edu.owen.ru/series/pr200_rev/
Другие видеоролики по тематике ПР https://www.youtube.com/channel/UCj4...H5H3d_t6iDlQOQ
В моем понимании это был один эксперимент, или изыскание. Первая часть - установление минимально достижимого периода опроса, можно считать выполненной, хотя на пустом проекте, где кроме опросов нет ничего, ценность результата снижается. Вторая часть - оценка влияния нагрузки на период опроса. И вот здесь и вылез подвох. Показанный Юрием результат выглядел хорошо и дал мне уверенность, что возможностей ПР для моих задач вполне хватает. А при конкретной реализации процесс пошел не так и пришлось затратить довольно много времени, чтобы вытащить на свет эту "особенность". А вообще это изыскание надо было проделать на этапе испытаний и результаты указать в технических характеристиках. А в описании указать, от чего может зависеть период опроса. Тогда сразу было бы понятно - для каких задач ПР подходит, а для каких нет. Это было бы честно по отношению к потребителям. И подобных вопросов и претензий не возникало бы. Но тут опять мешает "особенность". Ведь за заявленные ТХ нужно отвечать. Как указывать полученные Юрием 40 мс при времени цикла 7 мс, если при 1 мс может получиться более 100? А указывать минимальные результаты или описывать особенности - будет некрасиво. Поэтому и промолчали.
Сергей и кто эту теме поднял и естественно все участники .
Естественно нужно официальное обращение . Я естественно поддержу если приоритет
по модбасу будет не в ущерб и проекты которые рабочие будут не сбоить .
И программисты железа (это не программисты ОЛ) должны быть уверены на 100% что это не повредит всему остальному.
Последний раз редактировалось Алексеев; 12.10.2018 в 10:12.
Может и не обязательно делать приоритет? Даже если цикл 10-15 мс, не так уж это и много. Главное, чтобы период опроса не гулял от сложности проекта. Я уже озвучивал вариант, что для работы с интерфейсами нужно не выкраивать остатки времени от остальных задач, а выделять столько, сколько нужно для работы без тормозов. Если остатков не хватает, добавлять 1 мс времени цикла. По моему это гораздо проще и точно ни чему не повредит.
в ОЛ нет условных переходов, время затраченное на работу со всеми элементами можно просчитать легко, но раз пишется среднее время, значит к расчетам прибавляется время на обмен с экраном, на обмен с RS485. И следует помнить, что в умных книжках пишут: "при нескольких источниках запросов прерывание становится разделяемым ресурсом, использование которого может привести к нестабильности длительности цикла выполнения программы". Нестабильность ведь не одно и тоже что прямая зависимость от увеличения блоков, может разработчики соглашались на джиттер, а не то что обозначено заглавием темы, кстати можно было бы к примеру указать процент используемых блоков для той или иной ситуации, а не просто говорить что цикл вот-вот перейдет к следующему значению, потому что разброс времени цикла может перекрывать ближайшие ситуации
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Красиво излагаетe. Только неизвестно ,тогда зачем в это ПР влупили STM 32. Если в ОЛ нет условных переходов,то в микро
программе микропроцессора это не проблема. При тактовой частоте 160 МГц для этого процессора плевое дело и клавиши обс
луживать и дисплей и интерфейс даже не прибегая к прерываниям и условным переходам. ПР заточено изначально ёлочные Гир
лянды переключать, а не обслуживать сети. Обратите внимание,что даже АЦП туда воткнули 10 разрядный. Так на всякий случай
Вдруг и правда,кому то взбредёт в голову что то измерять. А тут оба- нашлись индивидуумы ,измерять начали. Тогда посадили
грамотного Реваку,чтоб макросы проталкивал супер-пуперовские,которые линейность высшей математикой выравнивают.
По большому счету никакого криминала в данной ситуации не нахожу. Паровоз с рельс не сошел. Ну столкнулся дядя с ситуа
цией,ну и что? Если б не столкнулся никто об этом не знал и прекрасно ёлочные гирлянды и дальше переключали.
PS. Только,что сходил на Ровкину ветку. В натуре гирлянды забабахал. Только от затеи с
ПР отказался,потому,что оно медленное.
Последний раз редактировалось Одесса; 12.10.2018 в 01:14.