c# + банальное чтение com port

[alexusankov]

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

...вообще-то, до 32-х устройств на одной шине без концентраторов, это адресов до 247. Но не суть.

Эммммм....

Raxp - CRC это чудесно, но вы обратите внимание на суть вопроса.
Суть вопроса - как мне считать 73 байта?
Нужно - отправить запрос, выждать секунду, и принять 73 байта. Все.
Поставленный вопрос - а вдруг не пришли 2 байта, идет как опровержение предложения "сидеть и ждать пока не придут 73 байта, читая их кол-во в DataRecieved".
Суть то проста - дать устройству секунду, и считать 73 байта.
Вариации, что не пришли некоторые байты, обрабатываются иначе, на одном участке стоит 12 устройств, для страховки, даже при отвале 11 девайсов, информацию, я получу.
Не дошли пару байтов? Не сошлась CRC? Да и хрен с ними, главное не задерживаться на одном устройстве дольше 1 секунды
P.s.s. слово "концентратор" - использовалось в другом смысле, нежели возможно поняли его ВЫ. Я так назвал блок управления

[simples]

Ну поставьте жестко вшитую в код секунду ожидания.
Никто Вас не заставляет писать как "было бы хорошо" (событийная модель, четко поделенный код на оправителя, получателя, прием данных, парсер данных) - пишите как хотите.
По сабжу - все у Вас получится.
Кстати, мб просветите, откуда такой лимит "не задерживаться более 1 сек на одном девайсе"?

[raxp]

Вы TC читаете между строк. Считать 73 байта вам удасться в том случае, если придут 73 байта, а не придут, то и не примите, никогда. Ответ от запрашиваемого устройства может быть либо одним длинным пакетом, либо разбит на несколько, вот для этого и считается CRC (которая в Modbus-е присутствует жестко в составе пакета). Если CRC принятого вами пакета не совпадает, пакет не принят, и ваше жесткое ограничение в 73 байта на прием граничит с маразмом, длина пакетов может быть разная.

Не дошли пару байтов? Не сошлась CRC? Да и хрен с ними, главное не задерживаться на одном устройстве дольше 1 секунды

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

P.s.s. слово "концентратор" - использовалось в другом смысле, нежели возможно поняли его ВЫ. Я так назвал блок управления

не знаю, что вы за смысл там вкладывали, надо называть модели сферических устройств и телепаты в отпуске. Но в контексте упомянутого вами RS-485 и Modbus все обстоит именно так, как я сказал и согласно стандарту.

[WorldMaster]

Почему только мне бросилось в глаза
что после отправки сообщения порт закрывается?

  myPort.Open();
10|    myPort.Write(ask, 0, ask.Length);
11|    myPort.Close();
12|    Console.Read();

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

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

[raxp]

...дык, в посту #5 для TC уже говорилось, что данные элементарно могут не успеть все прийти и их нужно ожидать в потоке.

[WorldMaster]

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

...дык, в посту #5 для TC уже говорилось, что данные элементарно могут не успеть все прийти и их нужно ожидать в потоке.

ДатаРесивер сработает когда будут получены какие либо данные .. а секунду ждать уже с момента срабатывания.

[raxp]

Некошерный вариант. Если запускать событие ожидания (считай поток, таймер) только с момента прихода данных, то проверка "неприхода" данных при отсутствии данных с одного из устройств никогда не будет запущена. Секунду следует ждать с момента отправки запроса.

[WorldMaster]

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

Некошерный вариант. Если запускать событие ожидания (считай поток, таймер) только с момента прихода данных, то проверка "неприхода" данных при отсутствии данных с одного из устройств никогда не будет запущена. Секунду следует ждать с момента отправки запроса.

Это тонкости...
Ежу понятно что нужно делать цикл из нескольких попыток отправки. А приход контролировать по свойству ByteToReceive (Не помню как точно называется).

[raxp]

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