Меню
+7 (495) 785-95-25
sale@lcard.ru
sale@lcard.ru
Страницы 1
|
||||
|
Вопрос по L502Добрый день. Пробовал через X502_Recv (с меньшей частотой сбора ), но при любой задержке в потоке (1 мс и более, когда нужно обработать принятые данные) функции сразу выпадают в ошибку X502_ERR_PROC_INVALID_CH_NUM (Неверный номер канала в обрабатываемом потоке синхронного ввода). |
|||
|
||||
|
Re: Вопрос по L502Во-первых если работа идет из ОС общего назначения (Windows/Linux), то сама ОС имеет права вносить ненормированные случайные задержки, которые вполне могут быть в единицах мс. Во-вторых функции асинхронного ввода-вывода при остановленном сборе выполняют запуск сбора, прием данных, и потом останов сбора, т.е. дополнительно уходит время на запуск и останов, поэтому они не очень подходят для приема с минимальным интервалом между кадрами. Если требуется добиться минимальных временных интервалов, то нужно использовать именно синхронный потоковый режим, при этом и интервал между моментами получения отсчетов на уровне устройства обеспечивается аппаратным образом и будет строго фиксированный, а уже задержка передачи от устройства до программы может варьироваться за счет задержек ОС. При этом можно настроить частоту АЦП максимальной, чтобы отсчеты разных каналов были как можно ближе друг к другу по времени, а частоту кадра настроить например на 1 КГц, тогда модуль аппаратно будет собирать раз в 1 мс по одному отсчету с каждого канала с частотой 2 МГц и пересылать их в ПК. Про ошибки X502_ERR_PROC_INVALID_CH_NUM, то при корректной обработке, когда передаются только действительные отсчеты от Recv в ProcessData и они передаются все без исключения в порядке приема, такой ошибки быть не должно. Проверяете ли Вы реальный размер данных, принятых из X502_Recv, т.к. если он меньше запрошенного, то оставшиеся отсчеты в массиве будут без полезных данных и если размер не скорректировать перед передачей в Recv, то в ProcessData обработает мусор, что и приведет к ошибкам. И если Вам не нужен постоянный поток, а нужны данные только в определенные моменты, то отбрасывать ненужные данные нужно уже после ProcessData, чтобы ProcessData все равно обрабатывала все приходящие данные. С моей стороны проще в синхронном режиме организовать сбор так: рассчитать количество отсчетов, которое должны принимать за интервал и делать Recv на этот размер но с заведомо большим таймаутом, чтобы перекрыть возможные задержки ОС. Функция все равно будет возвращать управление, как только наберет нужные данные, не дожидаясь конца интервала, т.е. с той скоростью, которой позволит ОС. При этом размер тогда должен быть всегда равен запрошенному и несовпадение можно считать ошибкой. Время выполнения Recv можно замерить внешним образом таймером с высоким разрешением, при этом если отдельный вызов может быть быстрее/медленнее за счет задержек ОС, то среднее время выполнения должно соответствовать интервалу, иначе Вы будете получать данные с меньшей скоростью, чем они приходить от устройство и задержка будет нарастать и приведет в конце концов к переполнению буфера приема данных от устройства. При этом также нужно не забыть настроить шаг прерывания с помощью X502_SetStreamStep() на этот самый размер отсчетов за интервал приема, чтобы передача между L502 и буфером библиотеки тоже шла такими же порциями, т.к. иначе могут быть дополнительные задержки за счет разных размеров. |
|||
|
||||
|
Re: Вопрос по L502Добрый день. На синхронном режиме почему то начинают не всегда корректно считываться импульсы цифровых входов (кол-во плавает: на вход подается 1000, в программе у себя считываю от 950 до 1020), поэтому пришлось вернуть работу на асинхронный режим (с ним проблем нет). |
|||
|
||||
|
Re: Вопрос по L502Дополню свой вопрос - может по факту цифровые входа и правильно считываются, но я не совсем правильно их принимаю в своей программе. Если мне при синхронном вводе с плат нужно получить текущее значение цифровых входов, то мне необходимо брать последнее слово из массива, который передается для заполнения в X502_ProcessData? И если так, то и с аналоговыми данными так же (и если одна из плат считывает еще и цифровые входа, то как мне получить все последние данные с 32 каналов (у второй платы просто считываю с начала массива и все корректно, как в примере))? Ради эксперимента сделал следующий пример - два потока постоянно выкачиваю через X502_Recv / X502_ProcessData данные в свои буферы (частоты и значение READ_BLOCK_SIZE подобрал так, чтоб стабильно было в районе 3000 считываний в секунду). Третий поток по сигналу с цифрового входа (с одной из плат) собирает данные в общий буфер (т.е. есть жесткая привязка данных с двух плат на входной цифровой сигнал). При такой работе мое значение кол-ва импульсов цифрового входа как раз и скачет, при том что на вход подается ровно 1000. И ладно бы, если входное кол-во всегда постоянно, но в моей текущей задаче оно может меняться от 50 до 2000 в секунду, и нельзя их пропустить |
|||
|
||||
|
Re: Вопрос по L502А какое значение шага прерывания стоит изначально с завода? Если я буду менять через X502_SetStreamStep(), то потом чтоб при проблемах вернуть назад |
|||
|
||||
|
Re: Вопрос по L502Если Вы хотите фиксировать все импульсы, то Вы должны настроить сбор с DIN на частоту, для которой период между отсчетами был бы строго меньше (желательно с запасом) минимального времени длительности импульса и минимального времени паузы между импульсами. После этого в зависимости от интервала обработки Вы смотрите, сколько отсчетов соответствует этому интервалу и постоянно принимаете данные соответствующими порциями, настроив также шаг прерывания, после чего передаете все принятые данные в ProcessData и по получившемуся на выходе массиву значений din проходите весь массив и ищете нужный перепад (0->1 и 1->0) с учетом состояния перепада предыдущего блока (чтобы поймать перепад, если он будет в первом отсчете принятого блока). Если Вы что-то откидываете из принятого массива, то Вы можете пропустить собственно изменение состояния импульса. Шаг прерывания настраивается каждый раз перед сбором и действителен только на время выполнения этого сбора от запуска до его останова (это не какая-то сохраняемая настройка). Поэтому по сути его возвращать назад специально не нужно. Если в программе он не задан явно, то по умолчанию он выбирается в зависимости от частоты сбора, равным количеству отсчетов на 50 мс. |
|||
|
||||
|
Re: Вопрос по L502Реализовал синхронный сбор данных с каждой платы отдельным потоком. Настроил шаг прерывания равный кол-ву считываемых отсчетов - импульсы с цифровых данных теперь всегда соответствуют исходному (импульсы выдает промышленный контроллер). Но появилась другая проблема: периодически появляется ошибка -11 (X502_ERR_STREAM_OVERFLOW). При чем ошибка может появится как через 5-10 мин после запуска, так и через несколько часов. Пока что сделал перезапуск потоков сбора при ее появлении. В потоках программы, которые вызывают X502_Recv() / X502_ProcessData() никаких остановок нет (Sleep и прочие функции). Нагрузка на ПК минимальна (программа сбора забирает 1-2% ЦП, ничего остальное не включено, ОС Windows, ЦП i5). |
Страницы 1
Адрес: 117105, Москва, Варшавское шоссе, д. 5, корп. 4, стр. 2
Многоканальный телефон:
+7 (495) 785-95-25
Отдел продаж: sale@lcard.ru
Техническая поддержка: support@lcard.ru
Время работы: с 9-00 до 19-00 мск