Что почитать?

[Евгений Кислов]

1. В описании ситуации не содержится вопроса, но для начала я бы вам рекомендовал для самого себя написать ТЗ на модуль работы с MQTT и нарисовать схему взаимодействия его элементов.
2. Библиотека доступна в исходниках - можно подправить максимальную длину строк под себя.
3. Это не функция, а ФБ. Разумный подход - вызывать этот ФБ в цикле ПЛК (без каких-либо условий) и по нужным событиям генерировать передний фронт в переменной, привязанной ко входу i_xPublish.

[Stan_1]

Фух. Кажется, получилось. Спасибо большое! Даже удалось перенести все в FB. Не могу сказать, что понимаю четко почему заработало, скорее интуитивно. Но главное - что теперь можно уже экспериментировать, как Вы и советовали.

[Stan_1]

Эх. Натолкнулся опять на моменты, которые пока не могу осознать. Теперь ситуация такова. Есть FB, от которого созданы два инстанса. В каждом инстансе свой MQTT Client, который настроен на разные Subscribe topic. Инстансы вызываются один за другим, в каждом раз в 3 секунды выставляется i_xSubsribe := TRUE; и затем в каждом инстансе на каждом цикле выполнения программы вызывается mqtt(); Что я наблюдаю в итоге?
1. Допустим, в подписанных в MQTT_Client топиках установлены одинаковые значения (строка "ON"). В брокере я меняю один из топиков в "OFF". И вижу, что оба инстанса получили этот OFF, хотя ожидал, что только один инстанс должен был его получить. Если опять значение топика в брокере установить в ON - эту строку опять получат оба MQTT_Client.
2. Через некоторое время (3-4 минуты) MQTT Client выбрасывает Exception. Какое - не могу понять (где вообще это увидеть?). При этом q_sDiagMsg принимает значение "$04$10", а в q_sLastReceivedMessage выводится полная абракадабра.



Может ли такое произойти из-за одновременного запроса от двух клиентов к брокеру (вызов идет в одном цикле)? Как понять, в чем причина exception?

[Евгений Кислов]

Как понять, в чем причина exception?

1. См. Device - Журнал.

2.

поэтапно начинайте адаптировать к своей задаче, после каждого этапа проверяя, сохранилась ли работоспособность. Если после очередного изменения связь пропадет - надо приступать к анализу изменений. Так обычно происходит отладка проектов.

3. См. эту статью: https://oscat.ru/?p=382

[Stan_1]

поэтапно начинайте адаптировать к своей задаче, после каждого этапа проверяя, сохранилась ли работоспособность. Если после очередного изменения связь пропадет - надо приступать к анализу изменений. Так обычно происходит отладка проектов.

В общем, есть какой-то баг библиотеки, который то-ли появляется только в симуляторе, то-ли имеет какие-то фундаментальные причины. Связан с тем, что два инстанса MQTT_Client, видимо, за счет использования шаринга сокета - читают данные друг друга, и когда это еще и приходится на совпадения циклов - вылетают с AccessViolation. Такой вопрос задавали автору в 2018 году, но вся помощь от него была в стиле "такого не может быть". Но описанный кейс - точно мой. Вот ссылка.

Пока не понимаю, что делать. Для начала хочу попробовать две вещи:
1. Понять, как игнорировать AccessViolation (если это вообще возможно)
2. Попробовать через глобальные переменные разводить циклы чтения из разных топиков.

[Евгений Кислов]

1. Понять, как игнорировать AccessViolation (если это вообще возможно)

Если вам выстрелили в ногу - это, конечно, можно попробовать игнорировать - но лучше обратиться в больницу.

Связан с тем, что два инстанса...

Есть FB, от которого созданы два инстанса. В каждом инстансе свой MQTT Client, который настроен на разные Subscribe topic.

А зачем два инстанса?.. Что мешает подписать один инстанс на оба топика?

[Stan_1]

А зачем два инстанса?.. Что мешает подписать один инстанс на оба топика?

Возможно, архитектурно делаю неправильно. Но опять же, иду из опыта обычного программирования. Есть функциональный блок. Допустим - обрабатывающий выключатель света, скажем, FB_LIGHT_SWITCH. Соответственно, из логики ООП я делаю его максимально самодостаточным, то есть в
каждый из них добавляю mqtt: MQTT_Client.FB_MQTTClient. И затем делаю:
switchKuhnya: FB_LIGHT_SWITCH;
switchKoridor: FB_LIGHT_SWITCH;
switchKabinet: FB_LIGHT_SWITCH;

И потом,

switchKuhnya(i_sTopic := '/rooms/kuhnya');
switchKoridor(i_sTopic := '/rooms/koridor');
switchKabinet(i_sTopic := '/rooms/kabinet');

И соответственно, топик передается в экземпляр MQTT_Client внутри FB. Вроде бы нигде не сказано, что так нельзя. Также запрет на такую архитектуру не следует из ответа автора библиотеки по ссылке выше, где он пишет, что память каждого инстанса изолирована.

Каких-то примером, и best practics по такому варианту я не нашел. Если прямо совсем не прав - то просьба поправить фокус.

[Евгений Кислов]

Соответственно, из логики ООП я делаю его максимально самодостаточным, то есть в каждый из них добавляю mqtt: MQTT_Client.FB_MQTTClient

Я не знаю, что вы называете "логикой ООП", но ваша фраза не соответствует моим личным представлениям об ООП.
https://ru.wikipedia.org/wiki/%D0%91...B5%D0%BA%D1%82

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

Если прямо совсем не прав - то просьба поправить фокус.

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

Если задача носит сугубо практический характер - то проще перейти на один инстанс и подписать его на все нужные топики.
Каждый фронт в i_xSubscribe осуществляет подписку на топик, который в данный момент задан в i_sTopicSubscribe.

[melky]

FB используют общую память, насколько помню всегда и везде, не только в Овен ПЛК.
А вот изолированы как раз FUNC (Функции)...

Возможно когда вы включаете свет на Кухне и тут же в Кабинете, FB не понимает, что от него хотят, ну или где-то происходит сбой из-за этого.
Думаю вся проблема в FB и как ее вызывают, но тут только отладкой.

Точнее когда FB объявляется несколько раз, то под каждый используется свой блок памяти, возможно в конкретном FB есть использование каких-то переменных, что при вызове нескольких FB дает пересечение памяти.

[Stan_1]

Уфффф. Кажется методом проб и ошибок понял, что не так. Есть разное поведение при публикации и подписке. Смысл в том, что сначала я писал код с публикацией. И она долго не шла. Поэтому в общем случае я делал такую логику:

mqtt.i_xPublish := FALSE;
tonInterval(IN := NOT(tonInterval.Q), PT := T#3S);
IF tonInterval.Q THEN
  // Формируем json
  mqtt.i_sPayload := json;
  mqtt.i_xPublish := TRUE;
END_IF
mqtt();

И такая логика чудесно работает. Примерно по такой же логике я пытался сделать и i_xSubscribe.

mqtt.i_xSubscribe := FALSE;
tonInterval(IN := NOT(tonInterval.Q), PT := T#3S);
IF tonInterval.Q THEN
  result := mqtt.q_sLastReceivedMessage;
  mqtt.i_xSubscribe := TRUE;
END_IF
mqtt();

И на этом он падал в Access Violation. В общем, строчка: mqtt.i_xSubscribe := FALSE; - является лишней. Как только ее убрал - все стало отлично.