2G подвисает при опросе через два соединения

[1Gandalf1]

Доброго времени суток.
Есть система, в которой 2G управляем частотником по расписанию. Данные с него читают панель по RS-232 и 2Gi по Ethernet. В теории 2G должен был работать слейвом для двух мастеров по разным интерфесам и вроде противоречий нет. На практике проект разросся на большое количество переменных. В итоге при начале опроса по Ethernet, меню 2G виснет. Данные на панели и 2Gi меняются, а 2G на нажатие клавиш не реагирует и данные на экране не обновляются.

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

[Arsie]

Сообщение от 1Gandalf1

Доброго времени суток.
Есть система, в которой 2G управляем частотником по расписанию. Данные с него читают панель по RS-232 и 2Gi по Ethernet. В теории 2G должен был работать слейвом для двух мастеров по разным интерфесам и вроде противоречий нет. На практике проект разросся на большое количество переменных. В итоге при начале опроса по Ethernet, меню 2G виснет. Данные на панели и 2Gi меняются, а 2G на нажатие клавиш не реагирует и данные на экране не обновляются.

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

Самый главный вопрос: а как много и насколько часто вы опрашиваете 2G?

Другими словами, вы оставляете время 2G поработать, а не только бесконечно отдавать вам данные?

[serg-el]

Сообщение от 1Gandalf1

На практике проект разросся на большое количество переменных.

Вроде ограничение на 120 запросов. Тут.

Попробуйте оптимизировать вашу карту переменных. Возможно дело в этом.

И увеличьте время между опросами. Не принципиальные переменные можно опрашивать гораздо реже.

[1Gandalf1]

Сообщение от Arsie

Самый главный вопрос: а как много и насколько часто вы опрашиваете 2G?

Другими словами, вы оставляете время 2G поработать, а не только бесконечно отдавать вам данные?

Было по умолчанию 100 мс, сделал 200 мс, наверно, сделаю 1000 мс. Опрос небольшого количества переменных пошел, 2G заявил о превышении времени цикла. Поставил 140 мс, тормозит, но работает.

При увеличении количества опрашиваемых переменных, теперь уже 2Gi выдает ошибку проекта, код 43249/005650/1037.

По техзаданию 2Gi является неким хабом между несколькими 2G и скадой. Т.е. у меня даже при чтении все плохо, а по задумке еще и писать надо. Вот вопрос, нет ли готового макроса, который бы устанавливал флаг на отправку при изменении переменной, чтобы я запись в 2G мог сделать по запросу.

[serg-el]

Сообщение от 1Gandalf1

По техзаданию 2Gi является неким хабом между несколькими 2G и скадой. Т.е. у меня даже при чтении все плохо, а по задумке еще и писать надо. Вот вопрос, нет ли готового макроса, который бы устанавливал флаг на отправку при изменении переменной, чтобы я запись в 2G мог сделать по запросу.

Сделайте 2G мастером, 2Gi может работать и мастером и слейвом.
В 2G отправляйте переменные на 2Gi по изменению (аварийные по интервалу и изменению). Скадой опрашивайте 2Gi как слейв.

И будет вам счастье ( „СЧАСТЬЕ ДЛЯ ВСЕХ ДАРОМ, И ПУСТЬ НИКТО НЕ УЙДЁТ ОБИЖЕННЫЙ!“).

[Arsie]

Сообщение от 1Gandalf1

Было по умолчанию 100 мс, сделал 200 мс, наверно, сделаю 1000 мс. Опрос небольшого количества переменных пошел, 2G заявил о превышении времени цикла. Поставил 140 мс, тормозит, но работает.

При увеличении количества опрашиваемых переменных, теперь уже 2Gi выдает ошибку проекта, код 43249/005650/1037.

По техзаданию 2Gi является неким хабом между несколькими 2G и скадой. Т.е. у меня даже при чтении все плохо, а по задумке еще и писать надо. Вот вопрос, нет ли готового макроса, который бы устанавливал флаг на отправку при изменении переменной, чтобы я запись в 2G мог сделать по запросу.

2Gi прекрасно справляется с работой "хабом", переваривая до 4 тыс запросов.

Чтение/запись по запросу активируются заданием нулевого времени опроса.


PS. Забудьте про макросы, они не умеют делать что-то иное, чем делают блоки, выставленные на "поляну". Не бывает макросов, что-то включающих. Не бывает макросов, что-то выключающих. Обычные куски обычной программы, заключённые в тёмный прямоугольничек.

[1Gandalf1]

Сообщение от Arsie

2Gi прекрасно справляется с работой "хабом", переваривая до 4 тыс запросов.

Чтение/запись по запросу активируются заданием нулевого времени опроса.


PS. Забудьте про макросы, они не умеют делать что-то иное, чем делают блоки, выставленные на "поляну". Не бывает макросов, что-то включающих. Не бывает макросов, что-то выключающих. Обычные куски обычной программы, заключённые в тёмный прямоугольничек.

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

Кстати, я совсем забыл указать корень зла, с чего начало расти количество сетевых переменных.

ПЛК управляет насосом по расписанию, на каждый час своя уставка. Эти уставки задаются через меню настроек. Каждая переменная имеет вход и выход. Уставку можно изменить, как с меню ПЛК, так и с панели, а в перспективе и со скады. По умолчанию, значение в память пишется по изменению. Первая проблема возникла в том, что с панели приходит новое значение, контроллер ее принимает, но в память не пишет. Или пишет, но другое значение. Прилагаю скрин из лоджика.

Проблему пришлось решать установкой галочки "Запись по сигналу" на каждую уставку, что в результате добавило по сетевой битовой переменной к каждой уставке... В свою очередь, это создало проблему на следующем этапе. Если панель сама умеет бит отправлять при вводе значения, то при опросе по Ethernet, мне этот алгоритм нужно разрабатывать самостоятельно (см. начало поста). Вот так и мучаюсь

Если проблему с запись в память можно как-то решить проще, я только ЗА!
Прошу извинить, если непонятно излагаю мысль

[Arsie]

Сообщение от 1Gandalf1

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

http://forum.segnetics.com/showthread.php?t=736

Сообщение от 1Gandalf1

Кстати, я совсем забыл указать корень зла, с чего начало расти количество сетевых переменных.

ПЛК управляет насосом по расписанию, на каждый час своя уставка. Эти уставки задаются через меню настроек. Каждая переменная имеет вход и выход. Уставку можно изменить, как с меню ПЛК, так и с панели, а в перспективе и со скады. По умолчанию, значение в память пишется по изменению. Первая проблема возникла в том, что с панели приходит новое значение, контроллер ее принимает, но в память не пишет. Или пишет, но другое значение. Прилагаю скрин из лоджика.

Min/max для уставки точно в норме? Ещё может быть то, что одновременно меняются слишком много переменных и память перегружается.

Сообщение от 1Gandalf1

Проблему пришлось решать установкой галочки "Запись по сигналу" на каждую уставку, что в результате добавило по сетевой битовой переменной к каждой уставке... В свою очередь, это создало проблему на следующем этапе. Если панель сама умеет бит отправлять при вводе значения, то при опросе по Ethernet, мне этот алгоритм нужно разрабатывать самостоятельно (см. начало поста). Вот так и мучаюсь

Если проблему с запись в память можно как-то решить проще, я только ЗА!

Входная переменная, от неё Fronts из библиотечки, с Fronts строб на запись для уставки с "записью по сигналу".

Если при подключении мастера скопом идёт большая куча данных, то можно выстроить более сложную цепочку: переменная, триггер, уставка с "записью по изменению". При этом триггеры последовательно коммутировать, это снимет нагрузку на память.

Примерно как на картинке. Там происходит следующее:

1) После старта контроллера в любом случае ожидается готовность памяти, затем счётчик начинает перебирать группы регистров (до 4 штук в группе рекомендую), последовательно пропуская на вход меню все изменившиеся уставки

2) Если память оказывается перегружена, счётчик автоматически тормозится, ожидает, пока память освободится и переходит к следующей группе

3) Всё повторяется

Это канонически верный способ работы с памятью.

Смарт даёт автоматизированные способы решения задач, но это всё локальные задачи. Когда вы начинаете работать с большими объёмами, на задачу начинает влиять всё: неодновременность передачи данных, плотность трафика в сети, производительность памяти и так далее. На низком уровне такое можно разрулить либо руками (это как я показал), либо большой избыточностью производительности аппаратной части.

[1Gandalf1]

Спасибо большое за ответ!
Поступил следующим образом: на каждом входе "запись по сигналу" поставил макрос Fronts. Теперь когда из сети приходит новое значение, отличное от предыдущего, макрос выдает импульс на запись. Проверил, обмен идет стабильно, данные нормально записываются, как с панели, так и с 2Gi. Пока не знаю, насколько это решение получилось надежным, время покажет, но на столе все работает стабильно=))

[lau]

Когда сталкивался с проблемой превышения допустимого кол-ва запросов, то упаковывали данные (логические переменные в биты int, а числовые переменные при условии, что их значение ограничено заранее известным диапазоном (например, 0-30 или 0-100), т.е. известно сколько байт занимает максимальное число диапазона), а потом распаковывал на принимающей стороне.