Кончай понты кидать, "маг" хренов.Цитата:
Сообщение от murdemon
Вид для печати
Кончай понты кидать, "маг" хренов.Цитата:
Сообщение от murdemon
штаны превращаются .. превращаются в элегантные шорты .. (PS надо денег - готоф за денег запилить супер пупер бибку для modbus rtu slave для codesys 2) ну или есть бесплатный вариант позвонить и поинтересоваться в поддержке ОВЕН (это же их железо и они профит с него получают)
"Работать ради денег - это нормально.." - (С) Машков где-то на подработках.
Народ столько энергии проявляет чтоб взломать, найти..
Хотя вопрос в 1 дне, 5 строках для выделения фрейма, и 2-4х десятках строк для его разбора. Мд-я-я-я..
такой алгоритм позволяет находить несуществующие фреймы, дык еще ответственность за это возлогаецо на протокол а не на алгоритм )Цитата:
Сообщение от Валенок
Если фрейм нашли - это как он не существует ? Вы их сами придумываете или из порта берете ?
А ответственность - на разработчике алгоритма, который учитывает протокол.
А зачем она вообще нужна почему не воспользоваться встроенными в Codesys2 средствами для настройки Modbus RTU Slave?
Он может находицо внутри другого фрейма например в ответе другого слейва, вы же не знаете где в потоке данных из порта конец одного пакета и начало другого. регистры одного из слейвов например могут совпасть адрес команда црц итд. да это маловероятно но возможно. и отличить в потоке регистры это другого слейва или запрос мастера на запись (например) никак нельзя. сумбурно мож и непонятно но как то так.Цитата:
Сообщение от Валенок
В бибке для мастера такого быть не может потому что в линии никаких данных нет пакеты для мастера появляюцо после его запроса и он их принимает сначала и целиком. на один запрос - один ответ. и различать где начало пакета не надо. он и так сначала и он один. дальше да црц и прочие дела.
(нормальный) слейв принимает все пакеты и начинает их "разбирать" только после того как пакет закончицо то есть возникнет пауза в передаче. после этого он уже проверяет црц и прочее. только после паузы. ели есть возможность каким то образом различать пакеты по паузе - да, работать будет. но как это сделать?... ) так же возможно написать слейв рту для какой то конфигурации где известно заранее что будут спрашивать итд. но это не будет универсальной бибкой.
в modbus ascii есть спецсимволы начала и конца пакетов поэтому слейв реализуем уже на существующей бибке.
Вроде как в ответе слейва тоже должен фигурировать адрес устройства, нет ? И в конце CRC.
Так же как и в запросе от мастера фигурирует номер от какого слейва ждем ответ. Если запрос не нам (другому слейву) то нафига его вообще разбирать ?
слейв знает только свой адрес и ничего о других слейвах. и начало пакета предпологаецо искать по его адресу (или по чьему?). у вас нет пакетов у вас есть поток данных из порта. ответы других слейвов вам тоже придецо разбирать как то. как? только искать в этой мешанине запрос мастера и он может найтись хотя его и не было. )Цитата:
Сообщение от melky
lazy, там из разбирательства только адрес. Определили, что не наш и очистили буфер.
Допустим слейв включился чуть позже чем остальные слейвы и мастер и уже идет обмен. в порту какие то данные, что искать, чей адрес? нет гарантий в том что вы примите чей то пакет сначала.Цитата:
Сообщение от melky
ТС нужно. А так - да. Слейв замечательный (о мастере - не скажу ))Цитата:
Сообщение от murdemon
Знаю. Поэтому не понимаю сути проблемыЦитата:
Сообщение от lazy
запросы на чтение имеют определенную размерность байт, запросы на запись содержат двойное указание сколько байт всего в запросе, чё Вы пытаетесь со всеми спорить то. Программисты всех устройств и направлений делают слейвы, ни чего в этом нет сложногоЦитата:
Сообщение от lazy
Тм чтобы принять лажовый запрос надо сильно постораться, вероятность совпадения мизерная, если вобще не равна нулю
это у меня был знакомый он с Java в преобразователь Ethernet/485 писал и не дожидаясь ответ писал и читал по всем адресам (устройствам которых было много) на 485 шине (modbus) .. а потом не понимал почему какие то странные ответы приходят. На вопрос что 485 это полудуплекс и мастер-слейв ... он четко говорил мне все равно я по Ethernet работаю и долго звонил в MOXA устраивал разбирательства почему их устройства такие дорогие и так плохо работают. :)
lazy объясните дураку, как можно начать принимать запрос с середины пакета, если в начале любого пакета данных должна быть пауза а ее тупо нет ?
Зачем что-то читать вообще, если видно что это не начало пакета ? Ну включился слейв позже и что ? программа обработчик должна дождаться начало следующего пакета и только тогда начинать их проверять, ему прислали или не ему.
Дык-ж периодически на Землю прилетает метеорит и гасит почти все живое. Последний раз запортил все настройки у завров. Вот lazy и хочет защиту от этого поставить. Видимо у заказчика на это монет взял.
Lazy ! Тут защита простая - нужно применить функцию nauchitoslachitat() из hodjanasreddin.lib
WTF? :eek:Цитата:
Сообщение от lazy
И Мастер и Слейв и RTU и TCP прекрасно реализовываются, причём на базе стандартных библиотек codesys.