Тест dll с использованием .NET (COM-порт)

[Eugen Graf]

Ах вот как. Ты значит делаешь DLL (как .NET объект) и встраиваешь в LabVIEW через .NET Node ? Сори, я не очень врубаюсь как ты это осуществил. Если не трудно расскажи немного об этом.

Если бы я делал, то я бы написал DLL и использовал бы Library Function Node для каждой функции имплементированой в DLL.

А если у тебя DLL, то при чём тут .NET?

[Konstantin Sumenko]

А при том, что написать обычную dll на С# нельзя, так как в "безопасном коде" нет ссылочных типов, а marshal'ить все подряд не очень хочется, к тому .NET'овская dll уже и называется по-другому: сборка. Она представляет собой отдельный объект как набор классов. Соотвественно, для работы с ней надо кидать на нее референс, объявлять используемое пространство имен и перед работой с соотвествующим классом использовать конструктор. Приемуществ много: в "безопасном коде" практически отсутствует утечка памяти, спасибо сборщику мусора, благодаря ему большая часть С# кода выполняется быстрее, чем аналогичный на C++, но не всегда, ведь сборщик мусора все-таки отбирает время, хоть и идет в отдельном потоке.

В LV для работы со сборками есть палитра .NET connectivity, со всеми нужными инструментами: конструктор, свойство, метод и закрытие объекта.

Насчет порта: отдельную сборку я решил писать, для нормальной обработки исключений, иначе error cluster выглядит неудовлетворительно. Позже я передумал и делаю парсинг ошибки в самой LV, а работу с com портом осуществляю через системную сборку System->System.IO.Ports- могу написать об этом небольой обзор

И наконец. Я решил проверить как быстро с портом общается VISA и LV приложение с использованием .NET. Про список портов уже понятно. Далее я использовал эмулятор (на микроконтроллере), который в ответ на команду шлет обратно ответ (Эхо). В цикле for с небольшой задержкой было 27 раз выполнено обращение с последующим чтением. Результат: Виза работала в 2 раза хуже: не успевала выхватить из буфера сообщение, перед приходом нового...

[Eugen Graf]

А при том, что написать обычную dll на С# нельзя, так как в "безопасном коде" нет ссылочных типов, а marshal'ить все подряд не очень хочется, к тому .NET'овская dll уже и называется по-другому: сборка. Она представляет собой отдельный объект как набор классов. Соотвественно, для работы с ней надо кидать на нее референс, объявлять используемое пространство имен и перед работой с соотвествующим классом использовать конструктор. Приемуществ много: в "безопасном коде" практически отсутствует утечка памяти, спасибо сборщику мусора, благодаря ему большая часть С# кода выполняется быстрее, чем аналогичный на C++, но не всегда, ведь сборщик мусора все-таки отбирает время, хоть и идет в отдельном потоке.

На C# я ничего ещё не писал, но звучит интерессно.

В LV для работы со сборками есть палитра .NET connectivity, со всеми нужными инструментами: конструктор, свойство, метод и закрытие объекта.

Это да, работает примерно так же как и ActiveX.

Насчет порта: отдельную сборку я решил писать, для нормальной обработки исключений, иначе error cluster выглядит неудовлетворительно. Позже я передумал и делаю парсинг ошибки в самой LV, а работу с com портом осуществляю через системную сборку System->System.IO.Ports- могу написать об этом небольой обзор

Что то я в списке .NET объектов такого не нашёл.

И наконец. Я решил проверить как быстро с портом общается VISA и LV приложение с использованием .NET. Про список портов уже понятно. Далее я использовал эмулятор (на микроконтроллере), который в ответ на команду шлет обратно ответ (Эхо). В цикле for с небольшой задержкой было 27 раз выполнено обращение с последующим чтением. Результат: Виза работала в 2 раза хуже: не успевала выхватить из буфера сообщение, перед приходом нового...

Хм, верится с трудом. Хотя понятно что VISA имеет через чур много оверхеда из за поддержки достаточно большого количества интерфейсов. А какие были сообщения и установленая скорость передачи данных?

[Konstantin Sumenko]

500000 скорость обмена. Сообщение вперед строка Info, назад название прибора.

Про System.IO.Ports: берешь Constructor node, в окне сборок (Assembly) ищешь System, внутри System.IO.Ports.

[Eugen Graf]

Ура!!! Нашёл, работает!!!

Так что, насколько ты уже продвинулся? В общем ты значит отказался от своей сборки (т.е. отдельной DLL) и работаешь с портом напрямую из LabVIEW?

Класс, я тоже займусь этим. Мне интерессно. Только чтобы мы одну и ту же работу не делали вдвоём надо бы синхронизироваться.

Давай замутим клёвую библиотеку работы с портом

[Konstantin Sumenko]

Ок, не вопрос, давай сделаем

[Eugen Graf]

Как ты наверное заметил, я сделал такой небольшой примерчик и разместил его в немецком и английском форумах. Решил узнать что об этом думают другие люди. Вот читай на ЛАВЕ:

http://forums.lavag.org/index.php?s=&sh ... st&p=52333

[Konstantin Sumenko]

Ответов пока немного, будем ждать отзывов.

[Eugen Graf]

Во такие вопросы появились. Crowbar, знаешь ответы?

1) Any idea how to specify the .NET version to use? Serial port in 3.0 - 3.5 has some serious issues.....

2) So, it looks like this vi would utilize polling. Any idea how to implement a callback and hook into the datareceived event?

[Konstantin Sumenko]

1) Напрямую в LV нельзя, в приложении на С# это задается через так называемый манифест. Однако вот, что интересно, когда мы подцепляем IO.Ports в LV, хорошо бы узнать как там организован аналог манифеста и есть ли он вобще.
2) В LV в палитре .NET connectivity есть же register for event callback