Зависает программа передачи данных
Зависает программа передачи данных
Доброго времени, коллеги.
Потребовалось для отладки транслировать данные (одна посылка 4...5 байт) от ПК во внешнее устройство с адаптером на FT2232H (плата MorphIC -II). Режим работы - синхронное FIFO.
Накропал простенькую программку (вложение) с применением функций D2XX от производителя.
Проблема возникла на ровном месте - после 3..5 циклов зависает Labview и приходится закрывать диспетчером задач, отключать плату, загружать в нее конфигурацию.
Помогите советом, из-за чего может виснуть именно передача (прием данных на другом vi работает) и как победить это зависание?
Может у кого-то имеется переходник на этой микросхеме, и Вам будет несложно проверить на зависание.
Потребовалось для отладки транслировать данные (одна посылка 4...5 байт) от ПК во внешнее устройство с адаптером на FT2232H (плата MorphIC -II). Режим работы - синхронное FIFO.
Накропал простенькую программку (вложение) с применением функций D2XX от производителя.
Проблема возникла на ровном месте - после 3..5 циклов зависает Labview и приходится закрывать диспетчером задач, отключать плату, загружать в нее конфигурацию.
Помогите советом, из-за чего может виснуть именно передача (прием данных на другом vi работает) и как победить это зависание?
Может у кого-то имеется переходник на этой микросхеме, и Вам будет несложно проверить на зависание.
- Вложения
-
- FT2232Translate.vi
- Программка в LV8.5
- (92.87 КБ) 197 скачиваний
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 126 раз
- Контактная информация:
Re: Зависает программа передачи данных
Может, цикл отправки данных выполняется с маленькой частотой и приёмник не успевает читать, таким образом буфер переполняется. Это лишь догадка. Попробуйте сделать отправку данных по команде (например, при нажатии на кнопку).Meteor писал(а):Помогите советом, из-за чего может виснуть именно передача (прием данных на другом vi работает) и как победить это зависание?
Re: Зависает программа передачи данных
Буфер в приемнике составляет 512 Б, посылал данные со скоростью 5 Б/с. Но программа зависает уже на 3-4 итерации(не могу даже за это время переключиться на "контроль" аппаратной части и посмотреть реакцию на посылку).
Так что думаю переполнения буфера не происходит. Опять же, буфер передающей части (данные идут от компа к железу) по логике не должен копить в себе данные - цикл опроса шины USB 1 мс, с учетом приоритетов всяко за секунду должны отправиться.
Так что думаю переполнения буфера не происходит. Опять же, буфер передающей части (данные идут от компа к железу) по логике не должен копить в себе данные - цикл опроса шины USB 1 мс, с учетом приоритетов всяко за секунду должны отправиться.
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 126 раз
- Контактная информация:
Re: Зависает программа передачи данных
А на каком происходит зависание? В что-то можно сделать, или он не отвечает? И ещё вопрос: времякритичный цикл там обязателен?
Re: Зависает программа передачи данных
Немного предыстории.
В общем проект предполагался состоящим из двух параллельных циклов: цикл приема данных(данные поступают от платы в ПК), цикл передачи команд управления(запуск, остановка и еще несколько второстепенных отсылаются ПК в плату).
Первый цикл (приемный) "очень времякритичный", период опроса шины составляет 2 мс и его надо выдержать для исключения потерь данных.
Второй (передающий) не так сильно критичен, в нем команды из 4-5 байт могут передаваться очень редко, но откладывать его тоже не хорошо.
Почти о главном.
Изначально я разделил задачи по приему данных и посылке команд на два азных vi. Это сделано сознательно чтобы можно было отработать отдельно прием данных (правильность формирования пакетов, расчета контрольной суммы, обнаружение потерь данных и т.д.) и передачу команд (циклическое формирование одной из команд для того, чтоб посмотреть как данные поступают в железо, насколько правильно они декодируются и т.д.).
Подприбор приема данных работает как ему положено и в нем зависаний не происходит.
Недавно назрела необходимость отлаживать в железе именно команды, был сделан vi (первый пост) который:
1) сканирует и выводит пользователю (мне то есть) список подключенных узлов
2) ожидает мой выбор с каким узлом работать и как часто отсылать команду и после выбора настраивает на режим синхронного FIFO
3) с заданным периодом считывает содержимое строки и отправляет ее на передачу в шину USB, пока пользователь не нажмет кнопку стоп
4) по завершению цикла, закрывает узел.
Вот этот самый узел и виснет, отсылает несколько (от одной до пяти) команд и после этого LabView можно закрыть либо диспетчером, либо если повезет грубо нажав крестик в правом углу. Кнопка стоп на нажатие не реагирует. После закрытия зависшей программы приходится выдергивать устройство(ибо оно остается активным), запускать лабвью, загружать конфигурацию по новой в плату. В общем одни мучения.
В общем проект предполагался состоящим из двух параллельных циклов: цикл приема данных(данные поступают от платы в ПК), цикл передачи команд управления(запуск, остановка и еще несколько второстепенных отсылаются ПК в плату).
Первый цикл (приемный) "очень времякритичный", период опроса шины составляет 2 мс и его надо выдержать для исключения потерь данных.
Второй (передающий) не так сильно критичен, в нем команды из 4-5 байт могут передаваться очень редко, но откладывать его тоже не хорошо.
Почти о главном.
Изначально я разделил задачи по приему данных и посылке команд на два азных vi. Это сделано сознательно чтобы можно было отработать отдельно прием данных (правильность формирования пакетов, расчета контрольной суммы, обнаружение потерь данных и т.д.) и передачу команд (циклическое формирование одной из команд для того, чтоб посмотреть как данные поступают в железо, насколько правильно они декодируются и т.д.).
Подприбор приема данных работает как ему положено и в нем зависаний не происходит.
Недавно назрела необходимость отлаживать в железе именно команды, был сделан vi (первый пост) который:
1) сканирует и выводит пользователю (мне то есть) список подключенных узлов
2) ожидает мой выбор с каким узлом работать и как часто отсылать команду и после выбора настраивает на режим синхронного FIFO
3) с заданным периодом считывает содержимое строки и отправляет ее на передачу в шину USB, пока пользователь не нажмет кнопку стоп
4) по завершению цикла, закрывает узел.
Вот этот самый узел и виснет, отсылает несколько (от одной до пяти) команд и после этого LabView можно закрыть либо диспетчером, либо если повезет грубо нажав крестик в правом углу. Кнопка стоп на нажатие не реагирует. После закрытия зависшей программы приходится выдергивать устройство(ибо оно остается активным), запускать лабвью, загружать конфигурацию по новой в плату. В общем одни мучения.
-
- doctor
- Сообщения: 2210
- Зарегистрирован: 28 июн 2012, 09:32
- Награды: 3
- Версия LabVIEW: 2009..2020
- Откуда: город семи холмов
- Благодарил (а): 27 раз
- Поблагодарили: 26 раз
Re: Зависает программа передачи данных
У вас несколько vi работают с одним Com-портом? Попробуйте работу с портом вынести в одну мультифункциональную VI, с тем, чтобы исключить одновременные вызовы функций чтения и записи в порт из разных потоков (тогда VI со стандартными настройками будет вызываться строго последовательно, пока не закончит работу, следующий поток будет ждать). Либо управляйте последовательностью работы с помощью семафоров.
Re: Зависает программа передачи данных
Нет, сейчас я не работаю с одним устройством через разные vi - всегда запускаю только один из двух либо приемный либо передающий.Borjomy_1 писал(а):У вас несколько vi работают с одним Com-портом?
Нечто похожее задумывалось в конечной программе, там существовали параллельно три времякритичных цикла с приоритетом, два из которых нужны для обслуживания приема, а третий должен посылать команды.Borjomy_1 писал(а): Попробуйте работу с портом вынести в одну мультифункциональную VI, с тем, чтобы исключить одновременные вызовы функций чтения и записи в порт из разных потоков (тогда VI со стандартными настройками будет вызываться строго последовательно, пока не закончит работу, следующий поток будет ждать). Либо управляйте последовательностью работы с помощью семафоров.
Когда при отсылке команд стала виснуть лабвью, я отделил передающий в отдельный vi чтоб не валить все в одну кучу и отладить процесс, но он тоже зависает, хотя никаких команд на чтение данных из USB в нем нет и в помине.
-
- doctor
- Сообщения: 2210
- Зарегистрирован: 28 июн 2012, 09:32
- Награды: 3
- Версия LabVIEW: 2009..2020
- Откуда: город семи холмов
- Благодарил (а): 27 раз
- Поблагодарили: 26 раз
Re: Зависает программа передачи данных
У меня была подобная фигня с USB-COM адаптером. Тоже тогда намучился. Если я правильно помню, надо менять драйвер (по-моему, даже от другого производителя, но на такой-же микросхеме), иначе ничего не помогает, причем заменить его достаточно сложно - все время пытался встать старый.
-
- developer
- Сообщения: 257
- Зарегистрирован: 03 янв 2014, 19:37
- Версия LabVIEW: 2016
- Откуда: Украина, Киев
- Контактная информация:
Re: Зависает программа передачи данных
странно, у меня с примерами от FTDI никаких проблем не было. Но так как примеры эти не очень были удобными лично для меня, я написал себе коротенькую программку, смотрите ниже.
*приметка - файл в версии 8,5, так как у ТС такая версия указана в профиле.
Драйвера у вас тоже от FTDI стоят? у меня USB-UART 4 штуки к компьютеру подключены, на каждый дрова FTDI, всё в порядке.
*приметка - файл в версии 8,5, так как у ТС такая версия указана в профиле.
Драйвера у вас тоже от FTDI стоят? у меня USB-UART 4 штуки к компьютеру подключены, на каждый дрова FTDI, всё в порядке.
- Вложения
-
- lockerpcbconnect.vi
- (24.85 КБ) 217 скачиваний
Последний раз редактировалось AlexanderKonoval 24 июл 2014, 17:14, всего редактировалось 1 раз.
колдооооовствооооо! (С)
Re: Зависает программа передачи данных
Склоняюсь что это похоже на косяк с функциями от производителя. Драйвера они ставят свои(в смысле FTDI). Траблы начались при работе в режиме синхронного фифо, а всякие медленные rs232 не глючат.
Поправил
Поправил
Re: Зависает программа передачи данных
Драйвера от ftdi. Аналогично, работаю с программатором он на ftшке сделан - проблем нет.AlexanderKonoval писал(а):Драйвера у вас тоже от FTDI стоят? у меня USB-UART 4 штуки к компьютеру подключены, на каждый дрова FTDI, всё в порядке.
Вы используете простой последовательный порт.
У меня задача получить поток данных 4-8 МБ/с, там с этим медленным портом делать нечего. А быстрый почему-то зависает.
-
- developer
- Сообщения: 257
- Зарегистрирован: 03 янв 2014, 19:37
- Версия LabVIEW: 2016
- Откуда: Украина, Киев
- Контактная информация:
Re: Зависает программа передачи данных
посмотрел вашу программу. Я не вижу там двух вещей: указания настроек порта (скорость передачи, к примеру) и вы не мониторите FT_Status. Посмотрите, что этот самый статус выдаёт перед зависанием. Так, как программа зависает полностью, как я понимаю, поставте записывание куда-то, посмотрите.
Оговорюсь, мне до профессионала далеко, вполне вероятно, что мой ход мысли не совсем верный
Оговорюсь, мне до профессионала далеко, вполне вероятно, что мой ход мысли не совсем верный
колдооооовствооооо! (С)
Re: Зависает программа передачи данных
Статус согласен, надо помониторить.
Что касается настроек порта.
Используется ft2232h в режиме синхронного фифо. Производитель заявляет о скоростях передачи до 40МБ/с (320мегабит/с).
В этом режиме, скорость не задается - она определяется частотой обращения к узлу (период в моей программе) и дальше рулежка идет на уровне железа.
То есть в понимании устройства - это не переходничек UART-USB, это почти честный высокоскоростной USB2.0.
Что касается настроек порта.
Используется ft2232h в режиме синхронного фифо. Производитель заявляет о скоростях передачи до 40МБ/с (320мегабит/с).
В этом режиме, скорость не задается - она определяется частотой обращения к узлу (период в моей программе) и дальше рулежка идет на уровне железа.
То есть в понимании устройства - это не переходничек UART-USB, это почти честный высокоскоростной USB2.0.
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 126 раз
- Контактная информация:
Re: Зависает программа передачи данных
А структура у вас в обоих такая же как в FT2232Translate.vi? То есть, каждый раз выполняется открытие устройства, инициализация, приём/передача данных, де-инициализация, закрытие?.. Если так, то лучше сделать инициализацию и открытие один раз и использовать для приёма/передачи (во всех VI) один и тот же хэндл (FT_HANDLE ftHandle), ну и соответственно де-инициализацию и закрытие сделать тоже один раз. Также попался на глаза сброс платы в Morph-IC Loader.vi (Reset в Event'е), можно попробовать его выполнять перед открытием платы, вдруг поможет.Meteor писал(а):Нет, сейчас я не работаю с одним устройством через разные vi - всегда запускаю только один из двух либо приемный либо передающий.
Описание функций в \MorphIC-II Package\MorphIC-II Package\Altera Loaders\Altera Programmer DLL\MORPHPROG API Function Specification.docInitMorphICDevice
MP_STATUS InitMorphICDevice(MP_HANDLE mpHandle)
This function initialises the MorphIC device, by carrying out the following in the following order:
- ● reset MorphIC device USB buffer
- ● enable MorphIC device MPSSE
- ● reset MorphIC device USB buffer
- ● synchronize the MorphIC device MPSSE
- ● check that MorphIC device has been previously programmed
- ● reset MorphIC device
Выведите также сообщение об ошибках (Get_Error_Code_Explanation.vi / GetMorphICErrorCodeString или FT_W32_GetLastError / FT_W32_ClearCommError), может, там какая-то инфа будет отображена.
Re: Зависает программа передачи данных
Структура одинаковая.
На начальном шаге - поиск устройств, затем ожидание выбора, затем инициализация в режим синхронного фифо.
Далее для приемника два времякритичных цикла в одном из которых считывается содержимое и помещается в очередь, второй вытаскивает из очереди и переносит в массив, для передатчика времякритичный цикл в котором данные должны отправляться в устройство.
Работа циклов останавливается нажатием кнопки, в тот момент, когда "надоело" общаться с устройством.
После этого деинициализация, закрытие соединения с устройством, обработка накопленных данных, вывод на показометры, остановка работы подприбора.
Когда работать начнет(я верю в это!), то естественно хэндл будет один, назначенный в процессе открытия соединения.
Запускать работу двух vi одновременно невозможно по сути - хендл назначается и до закрытия соединения повторно его просто не получить.
Насчет сброса морфика, он выполняется после загрузки конфигурации. К сожалению пример лодыря под лабвью - слишком тормозно работает и его в программу я не включаю (терпения моего не хватит).
На начальном шаге - поиск устройств, затем ожидание выбора, затем инициализация в режим синхронного фифо.
Далее для приемника два времякритичных цикла в одном из которых считывается содержимое и помещается в очередь, второй вытаскивает из очереди и переносит в массив, для передатчика времякритичный цикл в котором данные должны отправляться в устройство.
Работа циклов останавливается нажатием кнопки, в тот момент, когда "надоело" общаться с устройством.
После этого деинициализация, закрытие соединения с устройством, обработка накопленных данных, вывод на показометры, остановка работы подприбора.
Когда работать начнет(я верю в это!), то естественно хэндл будет один, назначенный в процессе открытия соединения.
Запускать работу двух vi одновременно невозможно по сути - хендл назначается и до закрытия соединения повторно его просто не получить.
Насчет сброса морфика, он выполняется после загрузки конфигурации. К сожалению пример лодыря под лабвью - слишком тормозно работает и его в программу я не включаю (терпения моего не хватит).
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение
-
- 3 Ответы
- 4132 Просмотры
-
Последнее сообщение rsv
-
- 3 Ответы
- 855 Просмотры
-
Последнее сообщение IvanLis
-
- 13 Ответы
- 1191 Просмотры
-
Последнее сообщение Boxa
-
- 0 Ответы
- 486 Просмотры
-
Последнее сообщение Juri
-
- 3 Ответы
- 263 Просмотры
-
Последнее сообщение AndreyDmitriev