LabVIEW Portal

Проблема с использованием инструментария Windows API для работы с файлами.
Изначально стояла задача использовать механизм PIPE (Именованный канал, труба - по сути файл с путем \\.\pipe\<имя_канала>) для быстрого межзадачного обмена в LabView,
так как стандартные кубики LabView по работе с файлами не умеют работать с путями типа "\\.\pipe\<имя_канала>" было решено использовать WinAPI, а точнее библиотеку kernel32.dll, для работы с такими файлами (вообще с именованными каналами работают простые функции типа CreateFile, WriteFile, ReadFile, CloseHandle а так же спец.функции типа CreateNamedPipe и т.д.).
Но работа встала на этапе попыток использования WinAPI для ПРОСТЫХ файлов (d:\123.txt), файл создается (createfile), но в него ничего не могу записать(writefile)/считать(readfile) - ошибка 1097 использования dll.
Описание использования CreateFile:
MSDN_createfile
Описание CreateFile на русском
MSDN_writefile
Описание WriteFile на русском
подробные настройки входов/выходов dll смотрите в probe2.vi
думаю, что ошибка в настройке входов у writefile - lpbuffer, по описанию функции имеет тип LPCVOID (Указатель на буфер, содержащий данные, которые будут записаны в файл.)
я настроил как array, u8, 1, array data pointer также перепробовал всевозможные варианты настройки этого и других параметров.
Основной вопрос в использовании функции WriteFile библиотеки kernel32.dll инструментария Windows API, кто пользовался, кто сталкивался?

Дополнение: версия LabView 8.6.1f1, такая же проблема и на LabView 2011

Читайте внимательно описание функции WriteFile. Вы забыли 2 параметра. Вот так работает:

для быстрого межзадачного обмена в LabView

И что, будет работать быстрее чем существующие механизмы обмена?

В моей практике win32 pipes самый низколатентный спсоб обмена информацией между и .net приложениями

mzu2006 писал(а):Читайте внимательно описание функции WriteFile. Вы забыли 2 параметра. Вот так работает:

Спасибо, помогло! только с pipe всё тоже самое не работает (путем замены пути на \\.\pipe\name) - ошибок нет, но и не пишет в канал..
для межзадачного обмена пока пользуюсь файлами на RAM диске, работает с циклом 1 мс. Стандартные механизмы типа shared variable более тормозные, а других и не знаю
(при условии, что нужен доступ не только из Labview-программ)

Проверьте handle на равенство INVALID_HANDLE + Соответствующий GetLastError. Кроме того, а pipe предварительно создана через CreateNamedPipe?

Доброго времени суток,

kernel32.dll не работает больше на win 10-64bit с LabVIEW-2015 32/64bit. Тот же код работает на др. машине с win 8.1-64bit с LabVIEW-2015 32/64bit.

Сталкивался уже кто нибудь с этой проблемой? Есть у кого идеи решения?

Большая просьба попробовать на др. версиях LabVIEW под win 10-64bit.

SubVI сохранил для LabVIEW 11.

Всё работает. Только пути в CLFN поменял.

Igor_G,

dadreamer писал(а):если используются стандартые системные библиотеки (kernel32, user32 и т.д.), то в CLFN нужно указывать не путь к ним, а только имя! Это обеспечит совместимость с любой версией ОС, где будет использоваться программа.

Спасибо за тест и советы,
с путём к dll был мой эксперимент. Извиняюсь что в этом виде отправил VI.

Похоже что проблема заключается все таки в другом.
Права доступа к файлу под Win 10 на др. рartition. (см. screenshot). Read-only на папку поставил Win10 Pro сам (возможно как default).
Первый вопрос: Какая разница? Это должно быть по идее все равно, или нет? Я ведь только читать файл хочу. Права на чтение имеют все, даже стандартный пользователь...

Хотелось бы сразу исключить дискуссии на тему кто виноват. Важно, что если это случилось у меня, то может случиться и у клиентов.
- Я работаю как администратор (см. screenshot права доступа) и несмотря на это LabVIEW-2015 через kernel32 не могла ПРОЧИТАТь файл!? - Точнее говоря, dll отрабатывают, как будто нормально (не выдавая ни какой ошибки), но в результате выдаёт фальшивый результат! Как такую ошибку у клиентов найти?

"Решение проблемы" - ручками разрешил авторизованному пользователю полный доступ к папке. После этого все заработало нормально.
Второй вопрос: Почему? Система и администратор имеют права полного доступа. Я работаю, как админ. Как понятно это на самом деле не решение проблемы. Ждать пока Microsoft или NI решат это проблему тоже не выход. Третий вопрос: Что делать?

(1) Идеальное решение было бы - (а) проверка файла/папки на read-only. (б) снять read-only с файла/папки на время доступа LabVIEW и/или программы написанной на LabVIEW. (в) вернуть установки на файл/папку после завершения доступа или закрытия программы.
(2) - (а) проверка файла/папки на read-only. (б) выдача сообщения пользователю о активном read-only.
P.S.: К сожалению пользователь работает обычно без прав админа. Поэтому он не сможет изменить доступ к файлу/папке. Т.е. будет знать почему не работает и не больше. :о(

Есть идеи?

Нашел в нете, что ,то что я только на win-10 встретил было у других и на win-8.1.

Так можно сбросить read-only с помощью "get Permissions" l;о) Тут источник и объяснение (на нем.).
http://www.labviewforum.de/Thread-Schreibschutz-auf-Datei-aufheben

SubVI сохранил для LabVIEW 11.

Igor_G писал(а):Первый вопрос: Какая разница? Это должно быть по идее все равно, или нет? Я ведь только читать файл хочу. Права на чтение имеют все, даже стандартный пользователь...

Без разницы. Если собираетесь только читать файл, то можете хоть какой атрибут ставить. Если не задано специальных политик для ограничения доступа к файлу, то юзер из-под ограниченной учётки спокойно сможет прочитать файл, хоть где, хоть даже в системном каталоге Windows.

Igor_G писал(а):- Я работаю как администратор (см. screenshot права доступа) и несмотря на это LabVIEW-2015 через kernel32 не могла ПРОЧИТАТь файл!?

А вы внимательно посмотрите на свой код и сверьте его с тем, что опубликован в статьях по работе с CreateFile / Read/WriteFile / CloseHandle. Во-первых, вы выставили параметр dwDesiredAccess в GENERIC_ALL (0x10000000L), то есть на чтение и на запись одновременно. А файл у вас только для чтения. После вызова CreateFile как всякая порядочная функция сообщает вам об ошибке INVALID_HANDLE_VALUE (0xFFFFFFFF = -1d). Далее, по-хорошему, нужно было бы проверить результат и при возникновении ошибки выполнить GetLastError и проанализировать ошибку. У вас же хэндл файла без всякого анализа отправляется дальше на прочие функции, даже если он -1. Потому и ReadFile, например, ничего не сможет прочитать по такому хэндлу.
Вот, даже в этом топике mzu2006 написал:

mzu2006 писал(а):Проверьте handle на равенство INVALID_HANDLE + Соответствующий GetLastError.

Igor_G писал(а):"Решение проблемы" - ручками разрешил авторизованному пользователю полный доступ к папке. После этого все заработало нормально.
Второй вопрос: Почему? Система и администратор имеют права полного доступа. Я работаю, как админ.

Вероятно, что поменялись атрибуты файла, и снялся флажок "только для чтения". Но суть в том, что права юзера сейчас не трогаем, если юзер ограниченный, то читать-то он всё равно может, даже если не является владельцем файла/папки. Системные папки, у которых владелец - система/system, не трогаем также.

Igor_G писал(а):Есть идеи?

1) поменять параметр dwDesiredAccess на GENERIC_READ (0x80000000L);
2) сделать хотя бы простейший анализ хэндла, возвращаемого CreateFile (равно или не равно -1);
3) выставьте все параметры-хэндлы как Signed Pointer-Sized Integer, иначе у вас на 64-битном будет через раз работать или вовсе не будет;
4) все эти функции не обязательно исполнять в UI-потоке, они потокобезопасны.

Кроме того, в чём смысл использования WinAPI для работы с файлами, когда стандартный функционал с успехом делает то же самое, причём внутренне вызывая те же функции WinAPI (CreateFile / Read/WriteFile / CloseHandle)?