Программа без фронт-панели

[Boris_K]

Как сделать прогу без фронт-панели, чтобы она вообще не взаимодействовала напрямую с юзером? Когда компилирую в .exe, в настройках всегда недоступен чекбокс "remove front panel" (независимо от того что в чекбоксе над ним). В справке глухо.

[dadreamer]

Когда компилирую в .exe, в настройках всегда недоступен чекбокс "remove front panel" (независимо от того что в чекбоксе над ним). В справке глухо.

Это потому что компилируете Main (Inclusion Type = Startup ). по умолчанию удаляет панели только у SubVI и только у них разрешает пользователю менять эту опцию. Почему так - причин много, но основная - исторически так сложилось, что основной не может быть запущен без панели. Поэтому вам придётся оформить ваш блок кода как SubVI.

Либо делайте в другой IDE как службу/процесс без всяких намёков на GUI (в LV, к сожалению, такое не провернуть) и подключайте к LV.

[Boris_K]

Впервые я, недавний нуб в , столкнулся с тем, чего оно не может Получается, и в этом посте http://labviewportal.org/viewtopic.php?p=70408#p70408 AndreyDmitriev имел в виду что делал сервис не на ?

[Boris_K]

А разве не получится через start asynchronous call? Чтобы основной вызвал subVI без панели и забыл про него, а сам сразу же завершился?

[dadreamer]

Получается, и в этом посте http://labviewportal.org/viewtopic.php?p=70408#p70408 AndreyDmitriev имел в виду что делал сервис не на ?

Ну, это лучше у него спросить Может, как DLL оформлял - тоже вариант. Но лично я бы писал сервис на традиционном языке типа C/C++, C#, Delphi, т.к. там заморочек с этим меньше, плюс ран-тайм отдельный не нужен и экзешник грузится в память в разы быстрее, нежели lvrt.

А разве не получится через start asynchronous call? Чтобы основной вызвал subVI без панели и забыл про него, а сам сразу же завершился?

Да, должно получиться. SubVI останется в памяти и будет работать. Единственное - стоит подумать, как наладить с ним связь и как им управлять (старт/стоп/пауза/...).

[Boris_K]

Единственное - стоит подумать, как наладить с ним связь и как им управлять (старт/стоп/пауза/...).

На этот счёт уже есть отработанный вариант - pipes. Работает мгновенно.

[Blackman]

Running a LabVIEW Application as a Windows NT/2000/XP/Server 2008/7 User-Defined Service
http://digital.ni.com/public.nsf/allkb/ ... B4004DF99B

[dadreamer]

На этот счёт уже есть отработанный вариант - pipes. Работает мгновенно.

Это да, в принципе, тропинка проложенная, всё просто. Надо как-нибудь для расширения кругозора попробовать Shared Memory, ну и времена приёма/передачи замерить, по идее должно быть ничуть не хуже Pipes. Ещё вот AndreyDmitriev писал, что SV можно подключить во внешнем коде, было бы любопытно посмотреть примерчик, типа тестовой пары "сервер" - "клиент".

Running a LabVIEW Application as a Windows NT/2000/XP/Server 2008/7 User-Defined Service
http://digital.ni.com/public.nsf/allkb/ ... B4004DF99B

Тоже как вариант. Хотя, может, кому-то и не захочется прописывать свой сервис в Службы Windows. Плюс, если память мне не изменяет, службы запускаются от system, с этим могут быть некоторые нюансы. Но попробовать стоит.

[Boris_K]

SV не хочется потому что штука эта тяжеловесная и неповоротливая. В Pipes (в реализации биб-ки для ) смущает малый размер буфера (1 кБ), но вроде это поправимо.

Blackman спасибо за решение.

[dadreamer]

В Pipes (в реализации биб-ки для ) смущает малый размер буфера (1 кБ), но вроде это поправимо.

Надо исходники библиотеки править и компилить:

/* There is no server to connect to, so create our own server */
handle = CreateNamedPipe(
name, //unique pipe name
dwMode, //open mode: from client to server / from server to client / bi-directional
PIPE_TYPE_BYTE | PIPE_READMODE_BYTE | PIPE_WAIT, //pipe mode: Data is written to the pipe as a stream of bytes + Data is read from the pipe as a stream of bytes + Blocking mode is enabled (synchronous I/O)
PIPE_UNLIMITED_INSTANCES, //maximum number of instances that can be created for this pipe: unlimited
1024, //number of bytes to reserve for the output buffer: 1024 bytes
1024, //number of bytes to reserve for the input buffer: 1024 bytes
NMPWAIT_USE_DEFAULT_WAIT, //default time-out value, in milliseconds (NMPWAIT_USE_DEFAULT_WAIT = 0); value of zero will result in a default time-out of 50 milliseconds
NULL //pointer to a SECURITY_ATTRIBUTES structure
);

Every time a named pipe is created, the system creates the inbound and/or outbound buffers using nonpaged pool, which is the physical memory used by the kernel. The number of pipe instances (as well as objects such as threads and processes) that you can create is limited by the available nonpaged pool. Each read or write request requires space in the buffer for the read or write data, plus additional space for the internal data structures.

The input and output buffer sizes are advisory. The actual buffer size reserved for each end of the named pipe is either the system default, the system minimum or maximum, or the specified size rounded up to the next allocation boundary. The buffer size specified should be small enough that your process will not run out of nonpaged pool, but large enough to accommodate typical requests.

Whenever a pipe write operation occurs, the system first tries to charge the memory against the pipe write quota. If the remaining pipe write quota is enough to fulfill the request, the write operation completes immediately. If the remaining pipe write quota is too small to fulfill the request, the system will try to expand the buffers to accommodate the data using nonpaged pool reserved for the process. The write operation will block until the data is read from the pipe so that the additional buffer quota can be released. Therefore, if your specified buffer size is too small, the system will grow the buffer as needed, but the downside is that the operation will block. If the operation is overlapped, a system thread is blocked; otherwise, the application thread is blocked.

Либо реализуете всё на чистом через CLFN, тогда не будет надобности каждый раз править сорцы и компилировать + будет поддержка и 64-битных , при правильной реализации. Ну, или попробуйте работать с тем, что есть: делите данные по блокам 1 КБ и отсылайте в "трубу". Попробуйте также запихнуть туда больше данных, чем размер буфера - ОС должна расширить буфер согласно примечаниям.
И вот ещё такая статейка: Pushing the Limits of Windows: Paged and Nonpaged Pool. Там есть данные по максимальной границе невыгружаемого пула (nonpaged pool) в разных системах. Конечно, это больше для расширения кругозора, т.к. вряд ли вы станете создавать "трубу" с размером буфера 32 МБ (макс. размер пула на XP 32-bit с оперативкой до 1.2 ГБ). Да и передавать данные пачками по мегабайту и более тоже не стоит.

[Boris_K]

Я тестировал, как работает OpenG pipes, когда размер записываемой порции больше буфера (1024 байт): если непрочитанных байт больше 1024 (независимо от кол-ва считываемых байт за 1 раз), то новая операция write не выполняется (приостанавливает поток), пока не будет прочитана новая порция. При этом ошибки на выходе (во всём этом процессе) не возникает, а данные при считывании не теряются. Но думаю, лучше не лезть в пучину, и просто бить свои данные на порции по 1024 байт, или меньше.

[Boris_K]

Возвращаясь к основной теме. Попробовал сделать через start asynchronous call. Требуемого поведения добиться не удалось. Если у вызывающего , после асинхронного вызова, вызвать для This VI метод FP.close, то завершается весь процесс, в том числе и тот , что был запущен асинхронно. Пробовал также через свойство FP.State - результат тот же. Тестировал готовый .exe. Проект приложил.

Остаётся пробовать регистрировать сервис

[dadreamer]

Я тестировал, как работает OpenG pipes, когда размер записываемой порции больше буфера (1024 байт): если непрочитанных байт больше 1024 (независимо от кол-ва считываемых байт за 1 раз), то новая операция write не выполняется (приостанавливает поток), пока не будет прочитана новая порция. При этом ошибки на выходе (во всём этом процессе) не возникает, а данные при считывании не теряются. Но думаю, лучше не лезть в пучину, и просто бить свои данные на порции по 1024 байт, или меньше.

Это потому что канал открывается в блокирующем режиме. Я писал уже об этом здесь. Кроме того, это написано в той цитате, что я привёл выше:

If the remaining pipe write quota is too small to fulfill the request, the system will try to expand the buffers to accommodate the data using nonpaged pool reserved for the process. The write operation will block until the data is read from the pipe so that the additional buffer quota can be released. Therefore, if your specified buffer size is too small, the system will grow the buffer as needed, but the downside is that the operation will block.

Но тут также написано, что в процессе подобной операции (впихнуть то, что не впихивается) буфер будет расширен и таким и останется. Вот это и стоило бы проверить. Если клиент читает данные чаще, чем ему отправляет сервер, то он достанет из канала весь посланный объём, а дальше ему можно будет слать большие пачки. Так в теории.

Если у вызывающего , после асинхронного вызова, вызвать для This VI метод FP.close, то завершается весь процесс, в том числе и тот , что был запущен асинхронно. Пробовал также через свойство FP.State - результат тот же.

Надо ставить FP.State = Hidden в конце работы основного . А также следует добавить строчку HideRootWindow = True в ini-файл, лежащий рядом с экзешником, это скроет свёрнутое окно с панели задач полностью. Проверил только что, всё работает как часы. Ну, и не обращайтесь к скрытой панели через Property/Invoke Nodes, иначе возможны разного рода казусы.

[Boris_K]

FP.State = Hidden

Это тоже пробовал, но на панели задач оставалась кнопка, поэтому исключил вариант из рассмотрения. А вот за совет с ini-файлом - спасибо!

[Boris_K]

Вот ещё полезные вещи, что нашлись по запросу HideRootWindow:

http://digital.ni.com/public.nsf/allkb/ ... F3006E258B
http://digital.ni.com/public.nsf/allkb/ ... 6000569FA9