Форум: Техническая поддержка

Антон, сообщите, решилась ли Ваша проблема с новой версией lgraph2.

Спасибо, вечером проверю.
Но я не думаю что это связано именно с Lgraph. Данное поведение я обнаружил программным путем, работая с lcomp. Позже убедился что Lgraph ведет себя так же.

Изменения есть: если после "по нажатию кнопки с трансляцией сигнала старт" изменить на "внешняя цифровая по переходу 0-1" - то эффект остался - первый прогон холостой.
Но! при этом заработал режим "внешняя цифровая по переходу 1-0" - ожидает кнопку сразу же, ведет себя ожидаемо.

Из переписки с Anton:

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

Это я понимаю и разумеется будет сигнал, но пока для теста используется кнопка. К моей проблеме эффект дребезга не совсем относится (старт по внешнему сигналу после смены режима).

Суть эксперимента по шагам:
1) в Lgraph крейтам выставляю синхронизация старта "по нажатию кнопки с трансляцией сигнала старт"
2) нажимаю кнопку старт в приложении
3) сбор данных начался, останавливаю
4) в Lgraph крейтам выставляю синхронизация старта "внешняя цифровая по переходу 0-1"
5) нажимаю кнопку старт в приложении
6) сбор данных начался !!!
7) останавливаю сбор данных, повторно нажимаю кнопку старт в приложении 
8) и теперь наконец крейты ожидают внешнюю команду, в моем случае "тумблер" после срабатывания которого начался сбор данных.

Собственно эффект дребезга на шаге 7 мне пока не интересен. Не понятно почему начался сбор данных на шаге 6. На шаге 1 если выбрать без трансляции - то ожидаемо работает.
Это я проверял на версии Lgraph 2.34.42

При этом данный эксперимент у меня полностью воспроизвелся и на версии 2.34.44. Но есть маленькое отличие: если на шаге 4 выставить по переходу 1-0, а не 0-1, то на шаге 6 сбор данных не начинается автоматически, а ждет "тумблера", то есть ожидаемое поведение. (в версии 2.34.42 - это все равно не работало)

Такое ощущение что какое-нибудь состояние/регистр не сбрасывается при смене режима.
PS это я снова продел уже с прошивкой "AVR ATmega 162  вер. 2.3 Jul  2 2014", к сожалению разницы не нашел

Еще одно уточнение, данное поведение было обнаружено программно при работе через lcomp. После чего убедился что в Lgraph поведение такое же.

Возможно, из-за какой-то особенности lcomp триггер старта (в FPGA  E20-10) не сбрасывается при инициализации модуля. Это попрошу проверить коллег.
Антон, а если в том же эксперименте полностью отсоединить кабельную часть цифрового разъёма,  сделать рестарт питания E20-10, а потом дойти до шага 6), то сбор данных также сразу запустится, несмотря на режим "внешняя цифровая по переходу 0-1"?

А как ведёт себя программа Synchro.exe при клике на радиокнопку 'Внешний по фронту' или 'Внешний по спаду'?

В Synchro.exe ведет себя ожидаемо, при смене на режим 'Внешний по фронту' или 'Внешний по спаду' останавливается сбор данных и ожидается внешний сигнал

Synchro.exe основана на библиотеке Lusbapi. Значит, проблема в Lcomp.

Можно отвлеченный вопрос, возможно глупый 
Как библиотека lcomp контролирует отбор данных пользователем (в lusbapi там через event ожидался асинхронный вызов)?

Имеется 3 модуля E2010, написал модуль сбора данных (за основу взял пример l7xx.tst). Но почему-то иногда крейт начинает мигать красной лампочкой. Я так понимаю, это переполнение буфера. 100% взаимосвязи я не нашел, бывает что все работает долго, а бывает через пол минуты уже горит красным.

Как с этим можно бороться? В чем заключается узкое место, на что обратить внимание?

1. А какая ревизия Ваших модулей?
2. Какая версия прошивки микроконтроллера модулей? 
Для получения информации можно воспользоваться штатной утилитой ModulesViewer:
                     www.lcard.ru/download/modulesviewer13.exe

E20-10 ревизия B, AVR ATegra 162 версия 2.3 от 2014 - не давно обновлял, стояла старая от 2008.

Сейчас повысил приоритет запускаемому процессу и пока вроде все работает нормально, но все-таки хочется понять в чем узкое место заключается.

нет, все-таки оно работает дольше, но все-равно  со временем начинает мигать красным... в LGraph при этом нормально

Прошу прощения за слабо информативный пост, это было в порыве отчаяния после напрасного переписывания кода в третий раз. 

Если кратко о проекте. У меня головное приложение пишется на C#. С lcomp работаю не на прямую, а через собственную dll на с++ (выступает в роли api). В этом api выделил метод для инициализации в котором подгружается библиотека lcomp (например init):

#ifdef WIN64
   CallCreateInstance("lcomp64.dll");
#else
   CallCreateInstance("lcomp.dll");
#endif

В C# точка входа выглядит примерно так:

static class Program
{
    /// <summary>
    /// The main entry point for the application.
    /// </summary>
    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.Run(new Form1());
    }
}

Внимание: Есть разница где вызывать метод загрузки (init)!
Я по началу дожидался события что форма загружена, загружал библиотеку и с ней начинал работал и получал стабильную работу не более 2х крейтов.
НО! Если загрузку выполнить в конструкторе формы - то у меня заработали и 3 крейта без намека на переполнения буфера.
Данное поведение я пока не могу объяснить, еще буду разбираться и проверять, но разница есть - это факт.
PS: хотел поделиться своими наблюдениями, вдруг будет полезно 

В модуле E20-10 (Rev.'B') при переполнении внутреннего аппаратного буфера светодиод  должен мигать не просто красным , а красно-зелёным цветом. Каким образом у Вас мигает светодиод: только красным или красно-зелёным цветом?

Да, имею ввиду красно-зеленое мигание.