VISA_TCPIP: не выполняется повторная VISA Write, где грабли?

[_Mickey_]

Коллеги, здравствуйте!

Помогите, пожалуйста, разобраться с ситуацией:
1) Есть некое устройство с IP адресом, с возможностью управления текстовыми командами через telnet.
2) Мною была написана subvi, см. вложение для управления данным устройством, что-то вроде драйвера.
3) Задача драйвера: связаться с устройством, опросить его, получить начальный ответ, подтверждающий, что устройство готово для общения, затем драйвер посылает команду с паролем для деблокирования устройства, а затем посылает нужную команду, которая придет из главной vi.

Проблема в следующем: связь устанавливается, первичная запись в порт проходит, получаем нужный ответ от устройства, все хорошо, записываем команду с паролем (на диаграмме помечена как VISA Write Password) для деблокирования..... и обнаруживаем, что в порт записано 0 байт со всеми дальнейшими вытекающими, что отклик от устройства неверный (его просто нет, раз ничего не записали) и т.д и т.п. Почему не проходит вторая запись, не понимаю.
Проверил телнетом, все ок.

[IvanLis]

Проблема в следующем: связь устанавливается, первичная запись в порт проходит, получаем нужный ответ от устройства, все хорошо, записываем команду с паролем (на диаграмме помечена как VISA Write Password) для деблокирования..... и обнаруживаем, что в порт записано 0 байт со всеми дальнейшими вытекающими, что отклик от устройства неверный (его просто нет, раз ничего не записали) и т.д и т.п. Почему не проходит вторая запись, не понимаю.
Проверил телнетом, все ок.

1. В профиле указана одна версия LabVIEW, а файл другой, поправьте пожалуйста.
2. Возникают ли при этом ошибки? Посмотрите в режиме отладки, возможно, что на первом этапе - соединения возникает ошибка и на Case-структуру подается False. В этом случае запись в порт и не будет производиться.

[dadreamer]

Может быть, для поиска подстроки в строке использовать не Match Pattern, а Search/Split String? И ещё, у вас в кейсе "Sending command to device here" задержка стоит параллельно основному коду, т.е. фактически две операции Visa Write могут быть выполнены с малым промежутком, и потом будет сделана задержка. Может, это не так критично, но лучше тогда так:

Чтение данных можно было бы сделать в цикле While: считывать не 255 байт, а до тех пор, пока не будет получена строка, содержащая нужные данные (или пока не будет получена команда "стоп"). Но это всё рекомендации, ошибку вылавливать придётся вам.

[_Mickey_]

Проблема в следующем: связь устанавливается, первичная запись в порт проходит, получаем нужный ответ от устройства, все хорошо, записываем команду с паролем (на диаграмме помечена как VISA Write Password) для деблокирования..... и обнаруживаем, что в порт записано 0 байт со всеми дальнейшими вытекающими, что отклик от устройства неверный (его просто нет, раз ничего не записали) и т.д и т.п. Почему не проходит вторая запись, не понимаю.
Проверил телнетом, все ок.

1. В профиле указана одна версия LabVIEW, а файл другой, поправьте пожалуйста.
2. Возникают ли при этом ошибки? Посмотрите в режиме отладки, возможно, что на первом этапе - соединения возникает ошибка и на Case-структуру подается False. В этом случае запись в порт и не будет производиться.

1. Поправил, извините.
2. Да, уже на самой первой VISA Read возникает timeout чтения, но я не придавал этому значения , т.к. данные все равно верно считываются и на первую case структуру приходит TRUE, а вот запись не проходит, это видно и по return count 2 и по режиму отладки, счетчик записанных байт остается равным нулю и дальше все происходит как я описывал выше, на вторую case структуру уже приходит FALSE.

[_Mickey_]

Может быть, для поиска подстроки в строке использовать не Match Pattern, а Search/Split String? И ещё, у вас в кейсе "Sending command to device here" задержка стоит параллельно основному коду, т.е. фактически две операции Visa Write могут быть выполнены с малым промежутком, и потом будет сделана задержка. Может, это не так критично, но лучше тогда так:

2014-05-31_13-13-25.jpg

Чтение данных можно было бы сделать в цикле While: считывать не 255 байт, а до тех пор, пока не будет получена строка, содержащая нужные данные (или пока не будет получена команда "стоп"). Но это всё рекомендации, ошибку вылавливать придётся вам.

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

Вот, нашел, как здесь:

[_Mickey_]

Решил ситуацию путем игнорирования timeout через case структуру. Всем спасибо.