WAD-AIK-BUS
Вид для печати
WAD-AIK-BUS
Жутко интересно что скажет электронищик будет продолжать противоречить мне или все же скажет что код близко не похож на тот который может находить проблемы.
При времени запросов в 65 секунд как можно понять задерживается опрос или нет, а ещё эта запись в каждый цикл нуля в переменную только для чтения
Время поставил такое специально, чтобы не мешало. Об этом тоже был разговор ранее. Запросы инициируются флагами R_1 и R_2. Кто сказал, что переменная только для чтения?
Как сетевая переменная она только читается, то что Вы туда ноль пишите постоянно это Ваше дело, что же касается переменных, а где периодичность запуска, я их видел на холсте, там им постоянно присваивается единица, т. е. каждый цикл посылается запрос, не успев ответить, а если логика в ОЛ по фронту, то только один раз, что тоже не подходит. А в настройках, у меня и ни влазят в окно, я их и не видел сперва и комментов нет возле них
Как сетевая, да. Но ни что не мешает записывать в нее значение изнутри. Таким образом фиксируется ответ. При ответе переменной присваивается значение с модуля, я его запоминаю и тут же переменная сбрасывается. Периодичность запуска не обязательна. Если флаг всегда в 1 - запросы идут с максимальной частотой. Об этом мне рассказали в техподдержке. Вы бы залили проект в устройство, подключили к нему любой модуль и посмотрели. Какой смысл критиковать просто так?
вот с чем имеется возможность работать, то и обсуждаю, когда вернусь тогда и будут логи, где будет "каша" из запросов ответов, без всяких устройств это ясно. Какой смысл в этих принудительных запросах, если есть штатное средство работа по времениЦитата:
Сообщение от Mike HG
Сейчас для чистоты эксперимента в проекте № 3 убрал переменные флагов и поставил период опроса 25 мс. Получил 8 запросов в секунду. Начал добавлять понемногу блоки. Частота снизилась до 5 запросов в секунду, а потом на очередном блоке подскочила до 40. Так что разницы в способе инициации запросов нет.
А смысл такой, что мне с одного модуля надо читать 2 канала с максимальной частотой, с которой может обновлять модуль. Это 65 мс. И еще 3 канала (2 с этого же модуля и один с другого) с небольшой частотой, ну где-то 1 раз за 1-2 сек, но не в ущерб первым двум. Вот это все я и разруливаю флагами. При точной подгонке удается прочитать 2 канала примерно за 40-50 мс и за оставшееся время прочитать еще один канал из 3-х, на следующем периоде читаю второй, и так по очереди. И в основном проекте флаги конечно работают по очереди. Просто для тестов не стал заморачиваться, так как разницы нет. Я думаю, что у мастера не такая уж глупая логика, и пока он не получит ответа от устройства, или не закончится таймаут, он не будет посылать следующий запрос на каждом цикле.
раз уж встал вопрос про критику просто так, объясните какую функцию выполняет макрос "Save f min", по моему мнению это более чем остальные адекватный макрос, но какую функциональность он выполняет я не разобрал
Этот макрос запоминает минимальное значение
каким образом, я подаю любое значение и оно появляется на выходе макроса, ни какого минимального я поймать не смог
Он работает совместно с элементом fGT. Значения надо подавать на верхний вход fGT и на вход Var макроса одновременно. Если значение на входе меньше, чем на выходе, то оно перезаписывается на выход. Если больше - то не перезаписывается. По переднему фронту на входе Reset выход устанавливается в 0. В проекте это происходит каждые пять секунд.
почему, если функция макроса запомнить значение, которое одновременно подается с импульсом сохранения, не повторяется в запоминании максимального значения?
почему тогда блинк а не ловец фронта?
почему в макросе не использовать fSEL, вместо "супового набора"?
Первый вопрос не понял вообще.
По второму тоже не понятно, какой фронт нужно ловить?
По третьему. Как придумал, так и сделал. Если у Вас есть идеи по оптимизации, покажите свою схему.
макросы максимума и минимума должны быть одинаковыми, и отличаться только подачей в нужный момент импульса, для каждого случая меняя подключение входов на fGT и так, как сейчас, искать ошибки требуется и там и там, а не в одном месте
по второму, это самое основное что может приводить к неверным результатам, блинк работает какое то заданное время с учетом времени цикла, оно может быть больше, поэтому управление с блинка на вход макроса происходит,вероятнее всего, в два цикла, следовательно есть шанс потерять нужное значение
схем запоминания значений через SEL великое множество на форуме, мне тут не стать оригинальным
Кому это они должны? Я делал так, как мне удобно для своих потребностей. Изначально был просто макрос для запоминания числа float, скачанный из онлайн библиотеки. Чтобы он запоминал только максимальное значение, к нему пришлось добавить функцию fGT. А чтобы запоминать минимальное значение, пришлось еще доработать и сам макрос. Ну уж так получилось.Цитата:
Сообщение от capzap
Блинк вообще имеет второстепенную функцию. По его переднему фронту оба макроса сбрасываются в 0, так как мне достаточно наблюдать значения в течении 5 сек. В макросах значения запоминаются автоматически, блинк в этом не участвует.А мне вот попалась эта схема. С ней и работаю. Вы считаете, что она работает хуже?Цитата:
схем запоминания значений через SEL великое множество на форуме, мне тут не стать оригинальным
Это только rovki хвастается что он схемы любые просчититывает и не только свои, из тех пару раз что я на схему смотрел, я не могу сказать однозначно правильная она или нет, надо тестировать, когда я поставлял различные значения, стало ясно что минимум формируется где то из вне либо схема не рабочая. Выйдя на главный холст бросается в глаза что fGT одинаковы для поиска противоположных значений, значит второй макрос написан по другому алгоритму, а раз его функция тоже запоминать значение, то ясно что Вы впустую тратите силы.
С блинком, если фронт ловит тот элемент который внутри макроса, ну замечательно если работает правильно, только в таком случае зачем возмущаться, что К Вам отношение скептическое
Для того, что бы составить пару макросов, недостатка сил не испытываю.:cool: С блинком никак не пойму, что Вы хотите сказать. Блинк не участвует в процессе запоминания, уберите его и все будет работать также. Блинк формирует 5 секундные интервалы, через которые обнуляются макросы. От его зависимости от времени цикла или ни жарко, ни холодно. То есть на выходах отображаются минимальное и максимальное значения, зафиксированные в интервале 5 сек. Потом по сигналу блинка выходы макросов устанавливаются в 0 и процесс повторяется.
https://www.modbustools.com/download...Setup64Bit.exe прога скачивается мгновенно, ставится меньше минуты, разбираться практически не надо, давно можно было выложить лог, с такими аргументами и предъявлять претензии разработчикам, а не придумывать что от количества блоков меняется опрос
простенькая программа опрашивающая каждый 40мс по установленному значению. Лог оставляет желать лучшего, видно что мастер старается придерживаться интервалов, но плохо у него получается, да есть провалы по времени у мастера, а так же следующие за этим склеивание двух запросов, на которые есть только один ответ
дополнительно скрин с другого программного слейва, там такая же картина, что запросы совершенно не хотят придерживаться очереди, лезут кому как вздумается, что чисто по штатному временному графику, что с помощью битов принудительной записи/чтения. Если долго заниматься, играя параметрами и поглядывая на Временная диаграмма опроса из справки можно добиться улучшения ситуации, но вывод один ПР не подходит для скоростных опросов, начиная где то со 150мс на запрос, уже всё нормально не вдаваясь в подробности
Ну тоесть подтверждаете особенности выявленные ТС , только более мошьным инструментов ???
нет, ни какого отношения к количеству блоков отношение это не имеетЦитата:
Сообщение от rovki
На тех скоростях ,что вы озвучили ,а если на тех ,что испытывал TC ?Цитата:
Сообщение от capzap
при чем тут скорости, во первых я не планирую работать на 115200, еще с времен когда "мышки были большими" (СОМ-овскими), во вторых если смотрели проект у меня есть куча бесполезных блоков, которые добавлялись после очередных прогонов, разницы особой нет, здесь не правильная работа мастера, который не справляется с очередью, если таковая существует, либо ее нет и всё построено на каких то внутренних таймерах, которые тестировались например только с одной переменной. Как на форуме уже писалось, ждем групповых запросовЦитата:
Сообщение от rovki
ЗЫ Вот прикладываю скрин где все вырезал
А я пока не планирую ПР как мастер ;).Работаю исключитльно на 115200 (без проводов).Так вроде есть групповые запросы ,числом до 12 .
Во первых, у меня галка группового запроса не активна, во вторых я имел ввиду, то когда разработчики займутся в следующий раз рефакторингом/оптимизацией мастера. Для меня пока очевидно, что биты записи/чтения роли не играют, импульс это или постоянное состояние, все зависит от бита опрос, чем дольше он висит с потенциалом, тем больше ложных запросов проскакивает
А ну я про слев..
Не поленился, тоже прогнал с эмулятором. Из тех программ, что выкладывал под номером 6. Запросы идут строго по очереди, интервалы между запросами 31-32 мс. С измерениями на самом ПР совпадает. ПР показывает время между запросами одного регистра 14-16 циклов при времени цикла 2 мс и 16 запросов в секунду.
А вот тест программы под номером 3 со временем цикла 1 мс. Очередность соблюдается, а вот время пляшет. ПР показывает интервал 88-113 мс и 5 запросов в секунду. Измерения эмулятора и ПР тоже совпадают.
Значит так у разработчиков устроенна микропрограмма, только они могут объяснить. А Вы можете сто лет эмулировать.Цитата:
Сообщение от Mike HG
Можете конечно найти закономерность,но может случайно произойти событие,которое пойдет вразрез с Вашими наблюдениями.
Так Вы согласно диаграммы уменьшите время таймаута до 1мс и потом запускайте этот проектЦитата:
Сообщение от Mike HG
Ничего не понял. Согласно какой диаграммы? И какое время таймаута? Имеется ввиду таймаут ответа в настройках мастера?
В справке доходите до работы мастера и где то на середине раздела есть график, как по времени идёт работа мастера. Вы поставили такое время, когда слейв в теории давно уже ответил, а ПР даже не приступила к прослушиванию интерфейса, это тоже влияет почему у Вас нет стабильности, опять же это лично моё мнение
Это как так? Мастер начинает слушать сразу после запроса и слушает либо до прихода ответа, либо до окончания таймаута. Я пробовал менять этот параметр. Менее 4 мс начинаются потери данных, 4 мс и более - никакой разницы нет. Юрий вообще советовал ставить таймаут с запасом 100-500 мс. А в справке... Предполагаю что там имеется ввиду таймаут ответа слейва.Цитата:
Сообщение от capzap
Ну значит им надо менять документацию и справку, потому что определение в текстовом виде таймаута верное, а рисунок совсем другое предусматривает, некое подобие rs.DL в слевах. Зато, Вы выяснили что ответ от прибора приходит за 4мс,что сопоставимо с теми расчётами что были когда-то приведены в Википедии по модбас
ПР200, мастер.Переменная управления чтением сетевого регистра управляет странно. Интуитивно кажется, что если она =0, то по этому регистру запросов быть не должно. Но по факту это не так, запросы всё равно идут, только реже чем когда она =1. Если периодически подавать в нее импульсы "1",то работает подобно как постоянно =1. Хотелось бы внятных пояснений как управлять при помощи этой переменной.Цитата:
Сообщение от capzap
Когда переменая =0, запросы идут с периодичностью, установленной в поле "Период опроса". Отключить запросы по периоду опроса по моему невозможно. Можно только увеличить этот период. Максимально возможное значение 65535 сек. При установке переменной в 1 формируется запрос. capzap предполагает, что если 1 удерживать постоянно, то запросы будут формироваться чуть ли не каждый цикл. Мне кажется, что мастер до прихода ответа, или до истечения таймаута новые запросы не формирует. Но на 100% этот момент я еще не подтвердил. В тех поддержке мне когда-то говорили, что для инициации запроса нужно подавать 1 только в течении 1 цикла программы. При времени цикла в 1 мс у меня наблюдались сбои, при времени цикла 2 мс и более уже работает. Хотя тогда я еще плохо понимал, как это работает, может были и другие ошибки. Вообще все тонкостей не знают и в техподдержке, отсылают то к РЭ, то к описанию протокола Modbus.
почему я пришел к такому заключению, ну во первых в справке сам график можно трактовать как угодно, если не читать описание таймаута. Во вторых, выложенный здесь мой проект шлет запросы только с единицей в таймауте при условии что задана переменная в поле опрос, если значение больше то запросы не идут, убрав разрешение опроса, картина меняется, увеличив таймаут до адекватного значения я начинаю принимать значения регистров, с переменной в опросе ни разу не удалось отобразить на экране заданное значение в слейве, хотя лог говорит что слейв свою работу выполняет и отправляет ответы на запрос.Цитата:
Сообщение от capzap
Посмотрел внимательно ваш проект, погонял на симуляторе. Проект простой, скорее всего время цикла 1 мс. Похоже у Вас тот же эффект, что описал я. Длительность команды чтения (записи) в 1 мс недостаточна для адекватной работы. Как это связало с таймаутом, непонятно. Попробуйте увеличить длительность команды. Насколько - точно не скажу. У меня сейчас устойчиво работает при 5 мс, при меньшем времени на устойчивость не проверял. И не понятно, зачем Вы дергаете переменную опрос? Никакого практического смысла в этом не вижу, а глюков возможно добавляет.Цитата:
Сообщение от capzap
чем дольше она включена тем больше дополнительных запросов приходит в слейв, обобщенно выставив 40мс в логе будут 4 запроса без ответа и на последний, пятый, будет ответ, ставлю 20мс два запроса без ответа, на третий отвечает, что то в этом роде. И я как раз говорю, что заметна не правильна работа, глюки. В идеальных условиях всё летает, сами же писали что Юрий предоставил подробное тестирование, но если чуть "шаг в строну" от этих условий мастер перестает нормально работать, это надо исправлять
От каких условий? Он их точно не обозначил. Я пытался добиться от него подробностей, но он ответил, что ему неохота лезть в тайминги. И послал меня изучать РЭ и протокол. Хотя при чем тут протокол, когда нужно знать логику работы конкретной железяки? А в РЭ ничего толком не описано. Исправлять надо, согласен. И писать толковое РЭ.
Так это как раз следствие малого таймаута ответа. Как только он истекает - мастер посылает новый запрос. Поставьте длительность команды 5-10 мс, а таймаут 10-20 мс.Цитата:
выставив 40мс в логе будут 4 запроса без ответа и на последний, пятый, будет ответ, ставлю 20мс два запроса без ответа, на третий отвечает