LabVIEW Portal

Добрый день. Собираюсь использовать простейший способ обмена данными между сRio и ПК - через sv. Не могу уловить тонкостей, в каких случаях,какие виды SV лучше использовать. С буфером или без? Что такое single writer? (Меню properties, вкладка network). В каких случаях применим буфер rt fifo?
В моем случае, программа крутящая на сRio (не на fpga), служит для отпрвки и приема can посылок, точность не нужна, достаточно отправлять и принимать на хост последние данные.
И классически кнопка стоп, которая с компа через SV останавливает прогу на компакт Рио.
Так вот когда кнопка SV кнопки стоп с включенным буфером, тогда, даже инициализируя ее фолсом в начале программы на cRio, сидит где-то Тру с момента последнего запуска и программа останавливается. Если же настраиваю без включенного буфера, то все ок. Если я инициализирую фолсом,то фолс и все ок. Почему?
П.С. имею ввиду просто буфер, буфер rt fifo не использую, не совсем понимаю его назначение.
Спасибо за советы!

А зачем на кнопку Стоп давать буфер? В целом, прочитайте эту статью - http://www.ni.com/product-documentation/4679/en/, может часть вопросов прояснится...

На русском http://www.picad.com.ua/0306/pdf/uroki_Lab_3_06.pdf

Для заявленной задачи Network Stream API будет лучшим решением. Чтобы не изобретать велосипед, установите при помощи VIPM библиотеку NI Variant Reconnecting Stream. Что это такое можно посмотреть здесь:
https://forums.ni.com/t5/Example-Progra ... -p/3512693

SV - самый плохой способ коммуникации из всех возможных, используйте UDP.
SV - очень простой и удобный способ коммуникации, но он имеет множество недостатков, что хоть статью пиши на эту тему. Главный недостаток собранное приложение на ПК не будет работать на другом ПК, приложение каждый раз надо "пересобирать". А еще при недостаточном опыте и понимание устройства (закрытого механизма) SV можно сильно загрузить контроллер.
Stream - оптимальный вариант для передачи большого количества данных, для пост обработки или накопления.
TCP/IP у NI - тоже имеет недостатки - постоянно что-то опрашивает и "сорит" в сеть.

У вас простая задача, используйте UDP.

Как правильно работать с SV описано в Руководство разработчика CompactRIO.

Vasiliy Baev писал(а):SV - самый плохой способ коммуникации из всех возможных, используйте UDP.
SV - очень простой и удобный способ коммуникации, но он имеет множество недостатков, что хоть статью пиши на эту тему.

Слишком уж категорично.
А что на счёт того, что UDP не гарантирует доставку пакета?

Vasiliy Baev писал(а): Главный недостаток собранное приложение на ПК не будет работать на другом ПК, приложение каждый раз надо "пересобирать". А еще при недостаточном опыте и понимание устройства (закрытого механизма) SV можно сильно загрузить контроллер.

"Главный недостаток" у SV вовсе и не недостаток: пересобирать (Build) приложение не нужно, нужно лишь развернуть (Deploy) переменную. Для этого есть специальная вкладка в свойствах приложения (Shared Variable Deployment).
В общем, инструмент, как инструмент со своими преимуществами и недостатками

Stkn писал(а):А что на счёт того, что UDP не гарантирует доставку пакета?

Мы реально столкнулись с дропом пакетов UDP. И если при разработке таких проблем в принципе не было, то в сети предприятия настал тихий ужас. Пришлось срочно перелицовываться на TCP

Borjomy_1 писал(а):

Stkn писал(а):А что на счёт того, что UDP не гарантирует доставку пакета?

Мы реально столкнулись с дропом пакетов UDP. И если при разработке таких проблем в принципе не было, то в сети предприятия настал тихий ужас. Пришлось срочно перелицовываться на TCP

Ага, особенно интересно, когда не теряется пакет, а их очередность изменяется ))
Приходилось нумеровать пакеты.
Но нужно было именно UDP, т.к. была широковещательная рассылка (TCP - "точка-точка" нельзя было использовать).