Конфигуратор vs modbus.lib

[Спорягин Кирилл]

я не вникал в проект.. а могу чисто интереса ради попросить установить MinCycleLength 10 ? Ну, просто очень любопытно...

Пока суд да дело, провел интересующие Вас эксперименты.
Привожу данные:
MinCycleLength = 0 СВО = 7
MinCycleLength = 1 СВО = 7
MinCycleLength = 2 СВО = 8
MinCycleLength = 5 СВО = 10
MinCycleLength = 10 СВО = 20
СВО (среднее время опроса 4 байт на 115 Кбод).

Время увеличивается и кратно MinCycleLength, чего и следовало ожидать.

[Спорягин Кирилл]

А что Вы ожидаете увидеть?

[spectrum48k]

изменение времени опроса в ту или иную сторону.

[Спорягин Кирилл]

Насколько мне известно, параметр MinCycleLength определяет минимальное время цикла. Более того он дополняет его до указанного значения, если реальное время цикла меньше. Т.е. если MInCycleLength = 1 и некая PLC_PRG исполняется за 0,6 мс, то еще 0,4 мс процессор будет спать. Во время 0,6 мс я включаю и его сервисные операции. Учитывая, что у тестовой программы цикл выполнения был меньше 1 мс, то установка любого MinCycleLength отличного от 0 должна увеличить время опроса.
Вы согласны? Или у Вас другое мнение?

[capzap]

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

[Спорягин Кирилл]

Проект опроса прикреплен к посту №46.

[spectrum48k]

SKV,
я просмотрел. навскидку: применяется CASE. не кавай. при переходе к следующему шагу, шаг выполняется в след цикле, насколько я помню... сейчас попробую разобраться детально. Увидел такие вещи как сканнинг и поллинг. Вы меня заинтересовали, буду изучать Ваш подход. Обратите внимание: в modbus.lib CASE не используются (видимо для ускорения). У меня тоже есть нечто подобное на стадии тестирования. Не могу довести до ума, тк нет контроллера. Могу я попросить попользоваться ПЛК через интернет?))

[spectrum48k]

Вот тут я уже ниасилил....



IF pDisp^.AdressForPooling = Base.Adress THEN
PoolingStat.SecondPoint();
IF GetData THEN AnswerStat.FirstPoint(); END_IF;
pDisp^.GetHoldRegs(
Enable:= GetData,
Mode:= MB_RTU,
DevAddr:= Base.Adress,
FirstAddr:= DataRegister,
Quantity:= RegisterCount,
ComHandle:= pDisp^.Settings.Port,
TimeOut:= TimeOut,
Buffer:= pDisp^.ReciveBuffer);


Указатели в VAR_INPUT можно заменить на внутренние переменные FB в разделе VAR_IN_OUT (это те же указатели в более удобоваримой для этих функций форме, не создают области памяти для себя и не происходит копирования переменных при вызове экземпляра. Поправьте меня, если ошибаюсь)

В принципе без детального изучения... разобрался. Вижу основную проблему быстродействия в CASE. Очередность вызовов диспетчером: диспетчер должен (имхо) не только устанавливать флаг, если время поллинга наступило, но и сразу же осуществлять вызов экземляров фб для записи чтения - для этого модули желательно унифицировать в массив из одноипных FB с массивами регистров внутрях. А массивы уже можно привязать к суказателям на структуры самих модулей в дальнейшем. Я пошел по такому пути.

[Спорягин Кирилл]

Spectrum48k, я так понимаю, что Вы уже сами разобрались.
Действительно, ничего сложного. Каждый ФБ модуль имеет параметр PoolingTime, который определяет через какое время модуль требует опроса. В случае истечения этого времени модуль выставляет флаг ReqForPooling. Диспетчер в каждом цикле последовательно бегает по массиву модулей и как только увидел, что какой-то модуль выставил флаг на опрос, передает ему такое право, устанавливая переменную AdressForPooling в
значение адреса данного модуля. Когда модуль завершил опрос, он выставляет флаг готовности и диспетчер снова сканирует массив модулей на предмет запроса на опрос. Это общая схема.
Далее дам свое мнение по Вашим вопросам.

Указатели в VAR_INPUT можно заменить на внутренние переменные FB в разделе VAR_IN_OUT (это те же указатели в более удобоваримой для этих функций форме, не создают области памяти для себя и не происходит копирования переменных при вызове экземпляра. Поправьте меня, если ошибаюсь)

Действительно, можно так поступить. В сущности это будет тоже самое. Копирует он в область Var_input не весь массив, а только указатель. Так же он поступает в случае Var_In_out. Но подход с указателем все же имеет преимущество. Его Вы можете один раз проинициализировать (у меня это делается тут: If FirstScan ...). А вот переменную Var_IN_out вы должны при каждом вызове устанавливать.

диспетчер должен (имхо) не только устанавливать флаг, если время поллинга наступило, но и сразу же осуществлять вызов экземляров фб для записи чтения.

Я об этом не думал, но задумаюсь над этим. Может, действительно, так сделаю. Но вообще-то это не должно влиять на время опроса, так как у меня последовательность вызовов такая: диспетчер, модуль1, модуль2 и т.д. Т.е. как только диспетчер выдаст кому-то разрешение на опрос, то на этом же скане модуль начнет опрос.

В принципе без детального изучения... разобрался. Вижу основную проблему быстродействия в CASE.

Так как время скана в тестовом примере меньше 1 мс, то любые подобные вещи (Case, вызов модуля из диспетчера) могут увеличить время опроса максимум на 2 мс, а мы видим, что для опроса 4 байт на 115 Кбод требуется 7мс. Я думаю причина где-то глубже.

[Спорягин Кирилл]

Так как время скана в тестовом примере меньше 1 мс, то любые подобные вещи (Case, вызов модуля из диспетчера) могут увеличить время опроса максимум на 2 мс, а мы видим, что для опроса 4 байт на 115 Кбод требуется 7мс. Я думаю причина где-то глубже.

Поясню, что для меня это имеет теоретический, а не практический интерес. В целом 7мс на дискретный 32-х канальный модуль и 12 мс на 8-ми канальный аналоговый модуль (с диагностикой!) меня устраивает более чем.