Статьи, обзоры, цены на станки и комплектующие.
https://cnc-club.ru/forum/
Вообще-то это несколько разные вещи. DTR/DSR это одно, а контроль потока это RTS/CTS.sidor094 писал(а):Все кроме настройки режима с DTR RTS работает.
Код: Выделить всё
HANDLE hcom = CreateFile("COM1:", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
if (hcom == INVALID_HANDLE_VALUE)
{
hcom = NULL;
DWORD err = GetLastError();
_stprintf(cerr, _T("Ошибка открытия %s - %d\r\n"), cvalue, err);
MessageBox(NULL, cerr, updcapt, MB_OK);
return 1002;
}
COMSTAT cst;
BOOL res = ClearCommError(hcom, &rdd, &cst);
DCB dcb;
COMMTIMEOUTS cto;
dcb.DCBlength = sizeof(DCB);
res = GetCommState(hcom, &dcb);
dcb.DCBlength = sizeof(DCB);
dcb.BaudRate = 115200;
dcb.ByteSize = 8;
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT;
dcb.fBinary = 1;
dcb.fParity = 0;
dcb.fOutxCtsFlow = 0;
dcb.fOutxDsrFlow = 0;
dcb.fDtrControl = DTR_CONTROL_DISABLE;
dcb.fDsrSensitivity = 0;
dcb.fTXContinueOnXoff = 1;
dcb.fOutX = 0;
dcb.fInX = 0;
dcb.fErrorChar = 0;
dcb.fNull = 0;
dcb.fRtsControl = 0;
dcb.fAbortOnError = 0;
res = SetCommState(hcom, &dcb);
if (!res)
{
CloseHandle(hcom);
hcom = NULL;
throw (1004, 1);
MessageBox(NULL, _T("Error DCB set\r\n"), updcapt, MB_OK);
return 1004;
}
но есть сомнения, что это будет правильно работать вместе с этимAndyBig писал(а):dcb.fTXContinueOnXoff = 1;
AndyBig писал(а):dcb.fBinary = 1;
Вот это не оно?sidor094 писал(а):А где тут включение контроля за DTR RTS CTS DSR?
Код: Выделить всё
dcb.fOutxCtsFlow = 0;
dcb.fOutxDsrFlow = 0;
dcb.fDtrControl = DTR_CONTROL_DISABLE;
dcb.fDsrSensitivity = 0;
dcb.fRtsControl = 0;fOutxCtsFlow
If this member is TRUE, the CTS (clear-to-send) signal is monitored for output flow control. If this member is TRUE and CTS is turned off, output is suspended until CTS is sent again.
fOutxDsrFlow
If this member is TRUE, the DSR (data-set-ready) signal is monitored for output flow control. If this member is TRUE and DSR is turned off, output is suspended until DSR is sent again.
fDtrControl
The DTR (data-terminal-ready) flow control. This member can be one of the following values.
Value Meaning
DTR_CONTROL_DISABLE
0x00
Disables the DTR line when the device is opened and leaves it disabled.
DTR_CONTROL_ENABLE
0x01
Enables the DTR line when the device is opened and leaves it on.
DTR_CONTROL_HANDSHAKE
0x02
Enables DTR handshaking. If handshaking is enabled, it is an error for the application to adjust the line by using the EscapeCommFunction function.
fDsrSensitivity
If this member is TRUE, the communications driver is sensitive to the state of the DSR signal. The driver ignores any bytes received, unless the DSR modem input line is high.
fTXContinueOnXoff
If this member is TRUE, transmission continues after the input buffer has come within XoffLim bytes of being full and the driver has transmitted the XoffChar character to stop receiving bytes. If this member is FALSE, transmission does not continue until the input buffer is within XonLim bytes of being empty and the driver has transmitted the XonChar character to resume reception.
fOutX
Indicates whether XON/XOFF flow control is used during transmission. If this member is TRUE, transmission stops when the XoffChar character is received and starts again when the XonChar character is received.
fInX
Indicates whether XON/XOFF flow control is used during reception. If this member is TRUE, the XoffChar character is sent when the input buffer comes within XoffLim bytes of being full, and the XonChar character is sent when the input buffer comes within XonLim bytes of being empty.
Из той же справки:UAVpilot писал(а):но есть сомнения, что это будет правильно работать вместе с этим
Я показал функцию, которой настраиваются параметры порта, а уж как с каждым параметром разбираться - Вы сами уж почитайтеfBinary
If this member is TRUE, binary mode is enabled. Windows does not support nonbinary mode transfers, so this member must be TRUE.
Похоже всё оказалось хуже... Судя по этому описанию нет возможности заставить чип/драйвер порта самостоятельно заниматься контролем потока, можно только в программе контролировать заполниение буфера приёма и "в рукопашную" дёргать управляющие сигналы...AndyBig писал(а):Из справки:
Ок, тут вроде всё нормально, если почитать описание параметра. Но напрашивается вопрос что курили программисты Microsoft, когда придумывали название этому параметру?..AndyBig писал(а):Из той же справки:
А зачем?UAVpilot писал(а):Судя по этому описанию нет возможности заставить чип/драйвер порта самостоятельно заниматься контролем потока
В основном цикле опрашивается входной буфер, новые данные оттуда копируются в свой буфер нужного размера, заодно по необходимости контролируется поток Буфер чипа или драйвера - это только промежуточный "перевалочный пункт" Я для этого шлю номер текущего исполняемого пакета, когда до него доходит очередь, и периодически шлю текущие координаты.AndyBig писал(а): Синхронизацию работы станка с отображением на компьютере можно добиться другими, более правильными способами
При правильной настройке этого режима и выделения буфера достаточного размера оно может нормально передавать данные через порт даже если ЦПУ перестанет реагировать на прерывания...AndyBig писал(а):А зачем?
Это общее падение уровня ПО, мелкософт уже не тот. Драйвер криво написан, вот и тупит.UAVpilot писал(а): Никогда не замечали как во время попыток обращения к сбойным секторам HDD система вообще перестаёт на что-либо реагировать? Это особенности архитектуры платформы x86...
Примерно такой способ мне и представлялсяКрафтер писал(а):Я для этого шлю номер текущего исполняемого пакета, когда до него доходит очередь, и периодически шлю текущие координаты.
Если ЦПУ перестанет реагировать на прерыывания, то никакой буфер уже не спасетUAVpilot писал(а):При правильной настройке этого режима и выделения буфера достаточного размера оно может нормально передавать данные через порт даже если ЦПУ перестанет реагировать на прерывания...
Это особенности реализации драйверовUAVpilot писал(а):во время попыток обращения к сбойным секторам HDD система вообще перестаёт на что-либо реагировать? Это особенности архитектуры платформы x86...
Недавно сделал устройство, которое работает по сети, и как дошло до программирования дополнительной утилиты по виндовс (для загрузки отчетов в 1С предприятие), так сразу начали всплывать косяки сетевого стека данной ОС, если в системе не одна а несколько сетевых интерфейсовAndyBig писал(а): UPD: Кроме того COM-порты с их аппаратным контролем потока начинают постепенно уходить в прошлое. Если разрабатывать что-то свое, с нуля, то лучше уже основываться на USB, а еще лучше в данном случае на Ethernet
И самое главное не страдает болячками USB интерфейсов, в плане качества, и длины соединительных проводов Что за косяки?selenur писал(а):косяки сетевого стека данной ОС, если в системе не одна а несколько сетевых интерфейсов
А то может это косяки организации сети, а не ОС Если интересно, узнаю у сотрудникаAndyBig писал(а):Что за косяки?selenur писал(а):косяки сетевого стека данной ОС, если в системе не одна а несколько сетевых интерфейсов
этой частью занимался он, и на вскидку уже не помню...