Работа со слейвами

Max · 26 июля 2016, 06:49:48

Реализовывал алгоритм работы одного М100s с тремя одинаковыми слейвами. Работу реализовал, но, как мне кажется, не самым оптимальным способом...
Берем блок записи по интерфейсу (W(slave)).. На вход port подается только константа, ладно, порт "онлайн" менять не смогу, но это правильно... а вот вход "dev" на который подаем адрес контроллера можно менять "онлайн".... пока я реализовал работу с 3 слейвами установив 3 блока W(slave) и задав в них разные адреса контроллеров... но вот хожу и думаю.. наверное ведь можно сделать "цикл" и записав данные в один слейв, переключить адрес на входе dev, записать во второй и снова переключить... теоретически выход RDY становится в 1 после осуществления записи.. но как правильно синхронизировать алгоритм? Предположим, мне надо записать 5 переменных. Ставлю счетчик, считаю до 5, переключаю счетчик адреса, сбрасываю счетчик переменных, и пишу в следующий слейв... работоспособная будет схема? Может есть готовые решения "обвязки" такой системы? И не может такая система сбиться? Ведь стоит просчитаться на 1 и все "съедет"...(к примеру, что будет, если произойдет коллизия? И переменная не запишется?)

mike · 26 июля 2016, 08:07:13

Прекрасный вопрос!
Для реализации такой обвязки существует нога sent.
Более подробно о ней расскажет Артем или Юрий, я их приглашу в эту ветку.
Реализация вашей задачи может быть выполнена несколькими способами.
Можно посылать широковещательные пакеты (если не требуется контроль приема слейвом посылки);
Можно использовать предложенную вами конструкцию;
Можно использовать индивидуальные блоки записи.

Artem · 26 июля 2016, 08:19:26

Выход rdy является гарантией того, что пакет дошел до адресата и адресат об сообщил об этом мастеру. В этом случае можно смело переключать адрес на входе блока. Однако надо не забывать, что сигнал на rdy приходит в виде "иголки".
По поводу схемы готовой синхронизации. Таковой пока нет, так как не было смысла в ее использовании. Дело в том, что эта схема займет гораздо больше объема кода чем простое дублирование блоков Modbus, если конечно их количество находится в разумных пределах. А вход dev необходимо применять совместно с макросами. То есть вы создаете макрос работы с каким-либо устройством и создаете у него вход, который завязан на вход блока dev. В этом случае вы получаете универсальный макрос работы с устройством одного типа, но разным адресом.

Max · 26 июля 2016, 08:23:13

Цитата: Artem от 26 июля 2016, 08:19:26
Выход rdy является гарантией того, что пакет дошел до адресата и адресат об сообщил об этом мастеру. В этом случае можно смело переключать адрес на входе блока. Однако надо не забывать, что сигнал на rdy приходит в виде "иголки".
По поводу схемы готовой синхронизации. Таковой пока нет, так как не было смысла в ее использовании. Дело в том, что эта схема займет гораздо больше объема кода чем простое дублирование блоков Modbus, если конечно их количество находится в разумных пределах. А вход dev необходимо применять совместно с макросами. То есть вы создаете макрос работы с каким-либо устройством и создаете у него вход, который завязан на вход блока dev. В этом случае вы получаете универсальный макрос работы с устройством одного типа, но разным адресом.

Тоесть смысла "городить" такой огород нет? ПРоще накопировать блоков и поменять адреса?

mike · 26 июля 2016, 08:58:38

Да, именно так

serge197a · 09 ноября 2016, 14:46:35

Здравствуйте!
пытался организовать опрос слейвов с динамическим изменением адреса слейвов.
Столкнулся с трудностью распределения данных.
К примеру:
опрос провожу по времени(периодически).
полученные данные нужно записать в переменные, соответствующие опрашиваемому устройству. Но на выходе функции чтения нет возможности понять, от какого устройства пришел ответ.
Делал временную задержку, не помогает.
В общем так и не победил.
Если бы вместе с данными, после приема, на фыход функции выдавался адрес,
то все было бы проще. Можно было бы использовать в условной записи.
Или поделитесь советом, как сделать эту условную запись с гарантией, что данные
от нужного слейва запишутся в нужную переменную.

mike · 09 ноября 2016, 17:12:34

Цитата: serge197a от 09 ноября 2016, 14:46:35
Здравствуйте!
пытался организовать опрос слейвов с динамическим изменением адреса слейвов.
Столкнулся с трудностью распределения данных.
К примеру:
опрос провожу по времени(периодически).
полученные данные нужно записать в переменные, соответствующие опрашиваемому устройству. Но на выходе функции чтения нет возможности понять, от какого устройства пришел ответ.
Делал временную задержку, не помогает.
В общем так и не победил.
Если бы вместе с данными, после приема, на фыход функции выдавался адрес,
то все было бы проще. Можно было бы использовать в условной записи.
Или поделитесь советом, как сделать эту условную запись с гарантией, что данные
от нужного слейва запишутся в нужную переменную.

Так вы же мне написали, что все работает

serge197a · 09 ноября 2016, 17:21:38

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