А что Вам мешает отловить сперва адресный байт, потом байт с командой, потом байты CRC, разобрать весь пакет на лету? Или проделать то же самое, набрав в буфер все принятые байты за время до следующего запроса?Сообщение от Одесса
А что Вам мешает отловить сперва адресный байт, потом байт с командой, потом байты CRC, разобрать весь пакет на лету? Или проделать то же самое, набрав в буфер все принятые байты за время до следующего запроса?
Я наверное Вас до конца не понял.Я програмно могу на лету поймать зараннее известный байт. Этим байтом является
из пакета только адресный, допустим я его отловил.По этому событию я могу сделать толко одно действие. это прочитать содержимое буфера на момент ,когда я этот байт поймал.Ну посмотрю я буфер и не увижу там ничего,потому,
что следующий байт еще не зашел. Я согласен с Вами,что рыть нужно в направлении указанном Вами,что и делаю в настоя
щий момент.
а там посмотреть как реализован протокол в modbus.lib и взять из него стоящие моменты, например очистка буфера...
ЗЫ jamod еще есть в сырцах
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Автору темы ничего не мешает заниматся этим онанизмом. Он даже считает что у него что-то получается.
Но для RTU это в принципе бред. В момент перехода мастера к чтению ответа в приемном буфере пусто (или мусор от помех) т.к. слейв еще принимает запрос или отбивает тайм-маркер а не генерит чего-либо. И если первый же байт не нужный адрес, можно, нет, вру, не можно, а обязательно нужно весь последующий кусок до самого тайм-маркера отправлять в мусор.
Для справки. Если программа написано правильно, в момент перехода мастера к чтению ответа в приемном буфере либо лежит ответ, либо сообщение об ошибке. Мастеру при этом даже не обязательно ждать таймаута конца передачи. В остальных случаях мастеру незачем переходить к чтению.
Последний раз редактировалось rwg; 15.09.2018 в 19:08.
а где, кстати, обозначено что реализуют мастера?
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
...............в первой посте
электронщик до мозга костей и не только
ну и кто тут троль?
Упоминание слова мастер присутствует? Да есть описание работы ведущего и что.
Ситуация, когда в приемный буфер приходит последовательность запроса модбас но частично меняющая куски запроса (конец с началом), может существовать только когда этот буфер слейва и не корректная работа мастера, который не ждет ответов от слейвов, а каждый цикл шлет запросы
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Так ведуший это разве не мастер ,а ведомый не слейв в модбасе RTU?
Последний раз редактировалось rovki; 15.09.2018 в 21:31.
Справка от кого ?
Если слейв реализовал машину времени - да. Если не реализовал, то :
Мастер переходит в чтению после отправки последнего байта.
В этот момент в слейве в лучшем случае лежит всё кроме последнего байта. Именно байта. Потому что пока нет последнего бита - на слейве не сработало прерывание о готовности к передаче в систему цельного байта.
А еще ему (слейву) нужно отбить тайм-маркер потому что все что есть у слейва до окончания тайм-маркера - мусор, и только мусор (Если, конечно мы говорим об RTU а не о "как бы RTU").
И все это время все слейвы на линии(получил первый байт, ... последний байт, выдержал тайм-маркер) молчат. Тупо молчат. А мастер тем временем уже ждет ответ. И ждет (как минимум) время пути последнего бита последнего байта запроса + тайм-маркер (который выдерживает слейв).
И откудова у мастера возникнет ответ сразу после ухода запроса ? Звездные врата форева ?
И это все - если вы сами побайтно пихаете в порт, а не из ЯВУ делает аналог неблокируемого "syscomwrite". В противном случае мастеру нужно учесть :
1. блуждание данных в собственных системных недрах
2. время физического ухода данных в линию
3. ну и тайм-маркер слейва
Ну и раз пошла такая ... детализация
4. время разбора пакета слейвом
5. время формирования ответа слейвом
6. блуждание данных в собственных системных недрах слева
7. время в пути до мастера первого (старт) бита
8. время заскакивания в мастера всех остальных битов сетевого байта
9. время обслуживания системой прерывания по приходу первого байт на мастере
10. задержка обращения пользователя к чтению данных из системы чтоб увидеть хотя бы первый пришедший байт для рестарта отсчета таймаута и начале отсчета тайм-маркера (который, в свою очередь будет рестартовать после каждого чтения из системы при условии наличия там данных).
В зависимости от релиза некоторые пункты могут слится в экстазе. Но все всегда будут.
Ну и как мастер вообще определит читать - пора ? Событие ? Так оно ж формируется из биб-ки/системы. Но при этом остается такой же программой.
И вот тут-то и переходим к ключевой фразе :
+100500.
ТС'у это и предлагал выяснить. Он предложил какие-то цветные пятна несущие кокой-то (по его словам) тайный смысл (видимо в расширенном сознании) и стал измерять ширину распальцовки. Обычное дело.
Последний раз редактировалось Валенок; 15.09.2018 в 20:29.
Ваши права
