LabVIEW Portal

Здравствуйте!

Помогите, пожалуйста, разобраться со следующей проблемой.

Разрабатываю ПО для управления испытательным стендом. На cRio будут подключены как приборы для измерения параметров так и управляющие устройства. Необходимо отделить измерительную часть от управляющей, для аттестации в последующем измерительной части.
Вопрос: могут ли на контроллере работать сразу 2 exe-шника - один для передачи данных от измерительных устройств, другой для работы с управляющими устройствами?

Заранее спасибо!

Сразу вопрос: как ПЛИС работает? если в scan mode, то шансов больше, если у каждого ехе свой бинарник, то сразу нет.

Дальше, прямо так не тестировал, но была у меня сложность со впихиванием большой программы в слабый FP (предыдущее поколение RT).
Решил так: стартует один ехе, смотрит состояние переключателя на морде контроллера, и в зависимости от его значения запускает одну из двух рабочих программ.
Да и в целом не вижу препятствий для параллельной работы, но.
Зачем так извращаться? Эти части же не будут работать в вакууме? они должны взаимодействовать, а значит, вы усложняете себе жизнь.
Нет никакой проблемы в аттестации функции, или измерительного канала.
Я делал системы, где в составе ПО был режим аттестации (как бы он ни назывался), когда мы можем подавать на измерительную часть эталонные сигналы, смотреть, что считывает система, и при необходимости вычислять калибровочные коэффициенты.

Спасибо за ответ.

ПЛИС будет работать в режиме scan mode.

"Зачем так извращаться? " Отвечаю. Согласно ТЗ ПО на систему измерения должна быть аттестована по ГОСТ Р 8.654. И чтобы не ограничивать себя в плане корректировки ПО, я и хотела в отдельный exe-шник выделить съем данных с датчиков, аттестовать эту часть и спокойно отлаживать управляющую часть. А если систему измерения не удастся выделить, то после каждой даже незначительной корректировки придется аттестовать все ПО.

Возможно мой вариант не очень удачный. Есть другие предложения?

Если посмотреть на реализацию подобных систем у других исполнителей, то все они стараются отделить метрологически значимую часть ПО от остальной и тем самым решают кучу потенциальных проблем. Вы стремитесь к тому же, но деление у вас крупнее. Обычно это не отдельный exe, а всего лишь библиотека (dll) у которой входы - исходные сигналы напряжения или тока, а на выходе физические единицы. Подобная библиотека создается, по ГОСТ формируется описание алгоритмов преобразования, она компилируется и рассчитывается ее контрольная сумма для внесения в реестр при аттестации. После этого вам нельзя изменять саму библиотеку, но можно менять как измерительную, так и управляющую часть основной программы. Например, в вашем случае если добавить или убрать один канал, то это изменения в программе и потребуется снова проводить всю процедуру аттестации так как изменится контрольная сумма. Если же у вас метрология вынесена в dll, то можете добавлять и удалять каналы сколько хотите, главное, чтобы они были однотипными и для пересчета использовалась аттестованная dll.

Andrew Lunev писал(а):Если посмотреть на реализацию подобных систем у других исполнителей, то все они стараются отделить метрологически значимую часть ПО от остальной и тем самым решают кучу потенциальных проблем. Вы стремитесь к тому же, но деление у вас крупнее. Обычно это не отдельный exe, а всего лишь библиотека (dll) у которой входы - исходные сигналы напряжения или тока, а на выходе физические единицы. Подобная библиотека создается, по ГОСТ формируется описание алгоритмов преобразования, она компилируется и рассчитывается ее контрольная сумма для внесения в реестр при аттестации. После этого вам нельзя изменять саму библиотеку, но можно менять как измерительную, так и управляющую часть основной программы. Например, в вашем случае если добавить или убрать один канал, то это изменения в программе и потребуется снова проводить всю процедуру аттестации так как изменится контрольная сумма. Если же у вас метрология вынесена в dll, то можете добавлять и удалять каналы сколько хотите, главное, чтобы они были однотипными и для пересчета использовалась аттестованная dll.

Спасибо за совет

Надо подумать.
А если у меня измерения идут в цифре через RS-485, HART и CAnOpen, то в dll входным параметром будет ответ датчика, а в самой dll алгоритм расшифровки данного ответа?

Тут надо уточнить у метрологов, но мое мнение такое. Если по цифре идет значение уже в нужной физической величине, например с цифрового термометра идет измеренная температура в градусах Цельсия, то вся ваша программа является индикатором и логером и не требует никакой аттестации, если датчик в реестре. Так как измеряемая величина никак не преобразуется и не меняет свою точность. Если же надо выводить в градусах Фаренгейта, а датчик по цифре передает в градусах Цельсия, то требуется преобразование и оно будет так же внутри этой dll, то есть у нее одна из функций будет преобразование из Фаренгейта в Цельсия. Если датчик цифровой, то все метрологические преобразования находятся в алгоритмах внутри датчика. Мы же при переводе сигнала например из протокола RS-485 в Ethernet не требуем метрологическую аттестацию преобразованных данных. Да в внутри всякие уровни протокола так же не требуют аттестации, иначе на каждый коммутатор, шлюз и роутер требовались бы метрологические сертификаты.
С другой стороны, преобразование из кода, переданного по цифровому протоколу, в физическую величину проводит автор алгоритма и может ошибиться и тогда преобразование будет неверным. Вот здесь и надо уточнить у тех, кто будет проводить вашу аттестацию.

Спасибо за разъяснение

В число имплементации (без создания именно dll), можете использовать плагин-архитектуру. Измеритальная часть - отдельный плагин, управляющая - другой (или просто основная программа). Тогда плагин измерения можно тестировать и модифицировать отдельно от остального приложения...

Kosist, DLL чем хороша, так это тем, что её можно подключить в любой другой среде, тогда как плагины (те же lvlibp) можно использовать только внутри .

Для задачи аттестации важно иметь именно отдельный файл, который должен иметь имя, версию, контрольную сумму. Именно эти параметры заносятся при аттестации в документацию и при их изменении требуется повторить процедуру заново, а это долго и дорого. Какой именно это будет файл - не важно. Но если это будет плагин, то он должен быть как-то отделен от остальной части программы, то есть обязательно должен быть отдельным файлом и именно этот файл должен использоваться в основной программе для расчета метрологии. То есть этот файл должны использовать и VI и exe. Мне в голову приходит только dll, но могут быть и какие-то другие варианты.

Для задачи аттестации важно иметь именно отдельный файл, который должен иметь имя, версию, контрольную сумму. Именно эти параметры заносятся при аттестации в документацию и при их изменении требуется повторить процедуру заново, а это долго и дорого. Какой именно это будет файл - не важно. Но если это будет плагин, то он должен быть как-то отделен от остальной части программы, то есть обязательно должен быть отдельным файлом и именно этот файл должен использоваться в основной программе для расчета метрологии.

как насчет llb? вроде, условиям удовлетворяет

Borjomy_1, если у компании ничего кроме LabVIEW нет и менять вектор развития не планируется, то можно и llb, и плагины LabVIEW-шные, и отдельно палитру с subVI аттестовать. Но это всё будут LabVIEW-шные штучки, которые юзабельны только в LabVIEW.
.dll - наиболее универсальное средство с точки зрения использования в других средах разработки. Если трудности с созданием .dll на тех же плюсах, то можно сделать .dll в LabVIEW и вызывать её в LabVIEW. Год назад похожая тема была, если интересно:
http://labviewportal.org/viewtopic.php? ... lit#p76904

Vitekkz88, я, может, не в теме, но что-то сомнительно, чтобы cRIO на арм процессоре и на ОСРВ поддерживал DLL, скопилированный для процессоров Intel и среды Windows

Borjomy_1 писал(а):Vitekkz88, я, может, не в теме, но что-то сомнительно, чтобы cRIO на арм процессоре и на ОСРВ поддерживал DLL, скопилированный для процессоров Intel и среды Windows

Смотря, какая ОСь стоит на контроллере. Elen не озвучила модель cRIO. VxWorks и PharLap ETS поддерживают подмножество Win32 с рядом ограничений, так что DLL без жёсткой привязки к WinAPI может запуститься.
Real-Time Controllers and Real-Time Operating System Compatibility
Verify Your DLL Is Executable in LabVIEW Real-Time on NI PharLap ETS
Если ОСь NI Linux, то ясен пень смысла в создании DLL нет (теоретически, .SO-шник, скомпиленный на Linux, мог бы пойти, но я не проводил подобные эксперименты).

Borjomy_1, ОСВР это будет или нет - без разницы, если ОС одного семейства. Если под линукс - то rpm(например) использовать. Тип устройства(контроллер это будет или процессор Intel) - не важен до тех пор, пока мы не касаемся самого ядра и ассемблера. Не так давно Вы работали с Raspberry Pi. У меня под рукой такой железки нет, но можете попробовать и убедиться, что .dll, собранная в ОС на ARM будет работать и на Intel-кристале, в рамках одной ОС.