11-13-2008 09:35 AM - edited 11-13-2008 09:37 AM
Hello NI Developers!
I use LabView 7.1 under Windows XP
I have a programm console application which accesses through Jungo Windriver PCI-E board.
This program works fine - and performs DMA data transfer between PC and Board's memory.
In order to implement this console application work together with LabView I did following:
1) Added this function inside the source:
_declspec(dllexport) void LVMainFunction(uInt32 *IntValue);
_declspec(dllexport) void LVMainFunction(uInt32 *IntValue)
{
AllocConsole(); //Open new console window
SetConsoleTitle(L"Debug Window"); //Set a title for console window
freopen("CONOUT$","a+",stdout); //redirec standard output stream to current window so
// so we are able to see "printf" outputs
freopen("CONIN$","a+",stdin); //redirec standard input stream to current window so
// so we are able pass inputs from keyboard
main(); //Call applications main function which does all the work
}
2) Compiled this new source as DLL library
3) Call LVMainFunction(...) function from LabView using Call Library Node
In the result: Executing VI - opens new console window, shows debug outputs and receives keyboard inputs.
It works fine till the last function, which perform DMA data transfer - and reboots PC.
1) Why does this happen?
2) I understand that opening console from Call Library Node, attaches together this console window and running VI. So If I close one of them - both windows closes.
So does LabView have somekind of restrictions of accessing Hardware's functions?
I can read Board's resource information and view size of memory on board, interrupt functions and other information about device, but when I try to reach
DMA my system reboots. And I understand that this should be some kind of LabView problem, cause I tried different implementations, even without use of
console window - and the result is the same.
3) Should I split the program in to two separate processes and perform data exchange using Sockets or Pipes techology?
Thank you in advance!
ACiDUser
11-13-2008
11:13 AM
- last edited on
06-18-2025
06:00 PM
by
Content Cleaner
Hello!
At LAST!!!
I solved this problem!
From the beginning I was following National Instruments manual on how to build DLL with external IDE:
http://zone.ni.com/reference/en-XX/help/371361A-01/lvhowto/building_library_project/
11-13-2008 11:45 AM
Hi, ACiDuser,
you wrote:
>So could someone explain why this happened? and If it is a bad tip, so it's better to remove from manual.
Please take a look to this topic:
http://forums.ni.com/ni/board/message?board.id=170&message.id=363889#M363889
Here explained why and where alignment should be set to 1 byte
another example with good explanation:
http://forums.lavag.org/LV-to-DLL-endian-conversion-question-t12229.html&p=53440#entry53440
best regards,
Andrey.
11-20-2008 10:49 AM
Hi!
I have read those topics, but It is still unclear for me.
I did not use any arrays in my code. The VC++ parameter Struct Member alignment was set to 1. It is a recommendation from NI manual.
In those topics were described situataions, when User forgot to set Struct Member alignment to 1 and recommended to use #pragma pack(1) before and #pragma pack()
after declaration of LabView typedefs. I think my case is different.
Thank you.
11-20-2008 11:16 AM
Hi, ACiDuser,
As you can see, alignment to 1 byte boundary required when you need to pass structures from DLL to LabVIEW (refer to LV memory organization). So, such alignment required not for every DLL. I guess, that NI wrote "Set the Struct member alignment control to 1 Byte" for some kind of "safety" - so this guaranteed that all structures will be passed correctly. But this alignment may affect other parts of code, of course (what exactly happened in your case).
Personally I always using "local" alignment changes with #pragma pack instead of "global" changes with compiler settings.
Andrey.