Отправлено: 11.09.19 18:05. Заголовок: Ввод данных через СOM порт

На вход TCP контролера приходит команда вида \хNN\xNN\xNN
в дебагере вижу то же самое \хNN\xNN\xNN.
На СOM порт приходит команда \хNN\xNN\xNN.
В дебагере

\xNN
\xNN
\xNN
Как получить непрерывную строку с ком порта, как с ТСР?
Пробую разные порты, но везде одно и тоже

 Отправлено: 11.09.19 20:13. Заголовок: Pavel777, проверить ..

Pavel777, проверить соответствие скорости потока и прочих настроек COM-порта автора строки настройкам порта контроллера Crestron. Если соответствуют, при возможности снизить на обеих сторонах до 9600. Если не поможет, еще снизить. Если не поможет, я бы задумался о программной сборке строки на основании протокола. Например, зная начальный и конечный символ строки, ловим её куски и собираем воедино. Или использовать аппаратный шлюз Ethernet <-> RS232, установив оный около контроллера.

 Отправлено: 11.09.19 22:50. Заголовок: Используйте BUFFER_I..

Используйте BUFFER_INPUT в модуле Simpl+
или символ Serial Gather (если есть признак окончания команды и команды не длиннее 255 символов)

Вот такой модуль Simpl+ может помочь, но это грубоватое решение при отсутствии признака-разделителя (delimiter) и обработки параметра длины команды скачать тут

 Отправлено: 12.09.19 09:05. Заголовок: Ничего криминального..

Ничего криминального в построчном отображении символов нет.
Так показывает строку Toolbox,
Лишних символов, интерпретируемых как перевод строки там нет.
Для Парсинга используйте привычные методики.
Из предложенных выше, присоединяюсь к использованию Serial Gather (Simpl), или gather (S+), что даст только лишь более привычное, сплошное отображение строки.

 Отправлено: 12.09.19 14:44. Заголовок: Думал, что вопрос в ..

Думал, что вопрос в каких-то "секретных" настройках СОМ-порта, с помощью которых сходу можно решить вопрос, но оказалось это проблема. Притом, она не безобидная, символы Substring и serial to analog , работающие с приходящей строкой не работают как надо.
Cимвол Gather решает проблему, но оказалось, у меня проблема с разделителем. Помог символ, предложенный Вячеславом, за что ему отдельное спасибо.

 Отправлено: 13.09.19 08:14. Заголовок: Выбранная вами скоро..

Выбранная вами скорость COM-порта достаточно низкая, чтобы контроллер успел обрабатывать (и соответственно отображать в тулбоксе) поступающую информацию побайтово. В случае с TCP отображается содержимое пакета.
Попробуйте увеличить скорость COM-порта и байты начнут слипаться.

 Отправлено: 17.09.19 10:21. Заголовок: В любом случае - на ..

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

1) складывать все данные в единый буфер, используя BUFFER_INPUT (или STRING_INPUT и собственный буфер в виде переменной внутри модуля - но этот способ не имеет смысла при наличии первого)

2) не забывать про Threadsafe на событие чтения и обработки BUFFER_INPUT

3) в событии чтения организовать бесконечный цикл, в котором последовательно вычленять из входящего буфера команды по мере их появления. Если в протоколе есть разделитель - то Gather() все делает за вас.
Если разделителя нет, то бывает признак начала команды и длина команды, анализируя которые, можно дождаться, когда команда пришла целиком, и вырезать её из буфера. Это чуть сложнее, требует всяких проверок (и тут нельзя бесконечный цикл).
Если все команды одной длины, можно попробовать использовать GatherByLength() но один левый байт мусора, и все пойдет враскоряку. Придется навешивать всякие проверки и очистки буфера.
Если протокол ваш собственный - то карты в руки.

Кстати, в TCP и UDP расчитывать на целостосность посылки можно с большими оговорками. На мой взгляд - это "читерство", и надо применять все те же техники, что и КОМ-портом.
Ибо это такой же поток и никто не гарантирует вам 1 пакет = 1 событие CHANGE.
Например, прилетит 2 пакета, пока Logic Engine занят чем-то важным и сложным. Драйвер сложит данные в буфер чтения ethernet адаптера, а Logic Engine, когда освободится, возьмет и вызовет один CHANGE, и вы получите их все разом.

Возможно я ошибаюсь, тогда пусть разработчики ядра и драйверов меня поправят :)

 Отправлено: 17.09.19 13:38. Заголовок: Viacheslav Alekseev ..

Viacheslav Alekseev пишет:

цитата:

Возможно я ошибаюсь, тогда пусть разработчики ядра и драйверов меня поправят

Расчитывать на порядочность разработчиков чего бы то ни было, ИМХО, в любом случае не стоит. Сегодня чит работает, а послезавтра выйдет обновление и кирдык :)

 Отправлено: 23.09.19 07:39. Заголовок: Причет тут "поря..

Причет тут "порядочность"? Нужно оставаться в рамках публично описанного и гарантированного, а все остальное это на свой страх и риск.

Viacheslav Alekseev все правильно написал выше. Опираясь на "Семиуровневую модель OSI", целостность сообщения на совести следующего уровня, поверх TCP/UDP или любого стриминга.