обнуление данных

[Artem.spb]

сразу предусловия: программа тестируется у заказчика, поэтому быстро проверить не получится.

итак, ситуация: программа опрашивает 4 порта.
сам опрос осуществляется такой функцией:

ф-ия реентрантная, чтоб копии не мешали друг другу - в рпоге просто 4 клона рядом параллельно нарисованы (не в цикле)
читаем 5 байт - рисуем число и так по кругу.
если байты не получены / недополучены, то рисуем NAN, чтоб было понятно, что именно не так.
всё идёт норм, но в какой-то момент данные обнуляются - в логе идут сплошные нули.
после перезапуска программы данные "воскресают"
причём, странно обнуляются:

log.png (9.55 КБ) 4795 просмотров

эдакое переполнение U16, хотя, такого типа нет в проге, а сами числа по факту идут простой строкой.
при проверке каким-нибудь простым терминалом такая картина не наблюдается, всё идёт норм.
такая картина наблюдается при "медленном" опросе, если частота достаточно большая, нули не вылезают, но там иногда проскакивают NAN-ы, т.е. опрос слишком шустрый, данные не успевают дойти.
но если я не все данные вытаскиваю, почему лезут нули?
подскажите, что тут можно подправить?
сколько работаю с визой, таких странностей не наблюдал.
да, в настройках визы стоит таймаут =0. попробую поставить побольше.
но даже если это решит проблему, останется любопытным вопрос - почему идут нули?

[mzu2006]

запишите в ваш лог ещё код ошибки, действительно пришедшее количество байт и сами байты в hex виде.

[rbl]

сразу предусловия: программа тестируется у заказчика, поэтому быстро проверить не получится.
но даже если это решит проблему, останется любопытным вопрос - почему идут нули?

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

[Artem.spb]

Смотрите в hex.

уже в процессе, но пока нет результата

[rbl]

Смотрите в hex.

уже в процессе, но пока нет результата

У Вас настолько медленный обмен? :)

[Artem.spb]

у меня:

сразу предусловия: программа тестируется у заказчика, поэтому быстро проверить не получится.

[rbl]

у меня:

сразу предусловия: программа тестируется у заказчика, поэтому быстро проверить не получится.

Исходные данные читал. Просто процессом привык считать именно работу, а не время ожидания допуска к объекту контроля ;)

[IvanLis]

А каким образом определяется начало (конец) пакета, или данные принимаются потоком - аля RAW ?

У Вас данные я так понимаю передаются постоянно, т.е. Вы их просто читаете без всяких запросов.
Если "терминатор" не определен, а чтение данных выполняется по числу бит, то возможна банальная рассинхронизация.

Снимок экрана от 2014-12-11 22-17-56.png (4.88 КБ) 4724 просмотра

первая строка, когда прием нормальный
вторая - рассинхронизация

В этом случае как раз и возможны чудесные преобразования данных.

[Artem.spb]

Данные идут потоком - я их не запрашиваю и никак не регулирую, прут себе и прут.
Инициализация визы с параметрами по умолчанию "Enable Termination Char (T)".
А в связи с чем может произойти сдвиг? и почему другой, "менее умный" софт такого не выдаёт? или же иначе, как избежать этого сдвига у меня?

[IvanLis]

Данные идут потоком - я их не запрашиваю и никак не регулирую, прут себе и прут.
Инициализация визы с параметрами по умолчанию "Enable Termination Char (T)".
А в связи с чем может произойти сдвиг? и почему другой, "менее умный" софт такого не выдаёт? или же иначе, как избежать этого сдвига у меня?

Ничто в нашем мире не идеально и возможны ошибки.

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

К стати, Вы принимаете пакеты по размеру, попробуйте отключить терминатор (Enable Termination Char = false). Возможно, что в последовательности он появляется и принимается не 5, а меньшее число бит, что приводит к сдвигу и неверной конвертации в дальнейшем.