SysComWrite() & SysComRead()

[spectrum48k]

Подскажите или дайте ссылку на информацию, пожалуйста.
В какой момент времени ПЛК серии 100/150/154 выполняет отправку буффера при использовании функции SysComWrite() : непосредственно выполняя остановку выполнения задачи или между задачами? Когда после отправки запроса выполнять прием ответа посредством SysComRead() - сразу после SysComWrite() или при следующем вызове задачи?

[lazy]

Эти функции возвращают количество прочитанных (переданных) байт. соотв. читать (писать новый) буфер нужно как только это количество сравняецо с dwBytesToRead (dwBytesToWrite).

[Yegor]

непосредственно выполняя остановку выполнения задачи или между задачами?Это синхронные функции, т.е. они выполняются блокируя вызывающий поток.
Когда после отправки запроса выполнять прием ответа посредством SysComRead() - сразу после SysComWrite() или при следующем вызове задачи?Когда вам удобнее с точки зрения написания кода. Временем выполнения одного цикла ПЛК в данном случае можно пренебречь. Я обычно жду ответ со следующего цикла — это получается естественным образом в автомате опроса (пример (http://owen.ru/forum/showthread.php?t=19435) — см. библиотеку). Можете и сразу SysComRead вызвать — всё-равно получите ноль и в итоге продолжите ждать.

[Sergey666]

Подскажите или дайте ссылку на информацию, пожалуйста.
В какой момент времени ПЛК серии 100/150/154 выполняет отправку буффера при использовании функции SysComWrite() : непосредственно выполняя остановку выполнения задачи или между задачами? Когда после отправки запроса выполнять прием ответа посредством SysComRead() - сразу после SysComWrite() или при следующем вызове задачи?

В "Примеры программ и полезности" раздела ПЛК есть(Должны быть - были:confused:) примеры работы с этими функциями .

[Валенок]

Это синхронные функции, т.е. они выполняются блокируя вызывающий поток...
Пример : отправка 512-ти байт на 38400 реально займет 150..200мс, а тупая засечка времени до/после syscomwrite - 1мс.
?

Имхо :
syscomwrite - пересылка данных в внутренний буффер. Дальше - отправка данных системой на прерываниях а не между циклами.
Именно прерывания - т.к., например, модбасную транзакцию (запрос-ответ) можно провести в течении одного рабочего цикла (т.е. не выходя из него). Делать так в реальных проектах не нужно.

С остальным полностью согласен.

[Yegor]

Ну да, асинхронные без обратной связи. Или синхронные с буферизацией. Момент отправки по проводам как бы не должен волновать пользователя SysComWrite ))

Я обычно таких правил придерживаюсь:
1) Больше одного раза за цикл для одного порта SysComRead или SysComWrite не вызывать (разве что для опустошения буфера).
2) SysComRead вызывать скользящим способом: iCount := iCount + SysComRead(hPort, pBuf + iCount, iExpected - iCount).

[Sergey666]

Ну да, асинхронные без обратной связи. Или синхронные с буферизацией. Момент отправки по проводам как бы не должен волновать пользователя SysComWrite ))

Я обычно таких правил придерживаюсь:
1) Больше одного раза за цикл для одного порта SysComRead или SysComWrite не вызывать (разве что для опустошения буфера).
2) SysComRead вызывать скользящим способом: iCount := iCount + SysComRead(hPort, pBuf + iCount, iExpected - iCount).

Правильно функции асинхронные , да и сам обмен асинхронный .
SysComRead читает за раз (вызов в цикле программы) содержимое буфера приема , буфер в микросхеме - 4кБ (вроде как , но не суть) , но в течении одного цикла при обмене (приеме пакетов от прибора) залезет около 4х байт . Поэтому принятые байты надо "склеивать" (складывать) до получения полного пакета . Напр ответ от прибора должен быть 16 байт - результат получится примерно за 4 цикла . Можно конечно читать с задержкой и вытаскивать сразу все из буфера , но тогда не будет гарантии отсутствия "лишних" байт .
Поэтому буфер приема надо постоянно подчищать .
Все с опытом приходит , т.к "детальное"-подробное описание работы (принципа правильной работы) этих функций отсутствует .