hviewlabs

More advanced state machine patterns: EDQSM: http://forums.lavag.org/index.php?s=&s...ost&p=19231 LabHSM: http://labhsm.com

"Preferred Exec System" is a standard (not even hidden) property of the "VI" VI Server class. 1. Put a property node (located on the Application Control pallette) on the block diagram. 2. Right-click on it and in the pop-up menu select: Select Class/VI Server/VI/VI. 3. Left click on the "property" word on this property node (which is now for VI class). In the pop-up menu select: Execution/Preferred Exec System You don't need to wire the reference input. When not wired the calling VI is assumed to be the VI for which properties are set/read.

As Rolf pointed out, if you use "LabVIEW" instead of "LabVIEW.exe" as the value for the "Library Name or Path" control in the Call Library Function dialog, then the code will work in the built app as well as in the development environment. Apparently, using "LabVIEW" there opens a way to a lot of LabVIEW functionality. However, except for the ones documented in the "Using External Code in LabVIEW" manual, where can we get the description/prototypes for those functions, I wonder?

The node apparently uses GetValueByPointer function from the LabVIEW 8.5\resource\lvimptsl.dll. There other 2 functions there: SetLVRTModule and SetStrDefaultValue.

So, can 8.5 call the functions from the library like below or not (HRESULT=long)? typedef struct tagPoogleMsgS { BYTE deviceID; BYTE priority; BYTE protocolID; WORD payloadLen; BYTE *pPayload; } PoogleMsgS; __declspec(dllexport) HRESULT SendMessage(PoogleMsgS sMsg); __declspec(dllexport) HRESULT OpenUsbPort(void); __declspec(dllexport) HRESULT CheckUSB(void); __declspec(dllexport) HRESULT RemoveConnectionlessMsg(PoogleMsgS* pMsg); __declspec(dllexport) HRESULT RemoveMessage(PoogleMsgS* pMsg); __declspec(dllexport) HRESULT CheckCOM(void); __declspec(dllexport) HRESULT OpenComPort(int nCom, DWORD dwBaud); The DLL Wizard does claim it finished successfully, but for the SendMessage it creates a node where instead of one input for the structure separate inputs are created for all the individual components of the structure plus some "dummy_controls", and pPayload is just U32 passed by value!

NI has a LabVIEW Modbus library: http://sine.ni.com/devzone/cda/epd/p/id/4756 As you can see, people reported it had problems in 8 (and above?) but since the file name is currently ni_modbus8_2.exe, I would assume they have been corrected. As for the arcitecture, of course, I will not miss this chance to suggest mine: I found that if we keep separate notions for state, action, and event, think (and treat) the code in the cases of the consumer loop as actions rather than states, maintain separate queues for events and actions, not only it allows creating a more flexible and powerful architecture, but, most importantly, developing code on a higher level of abstraction (when in this state and this event happens I need to do this, this and this action and switch to that state). Please see the following for further discussion and a more advanced architecture: Despite the pattern discussed there doesn't support hierarchical states (for those implemented see labhsm.com) I found it much more powerful and flexible (yet producing uniformly looking and easily modifiable/maintainable code) than the more primitive producer consumer single queue QSM patterns.

NI has a LabVIEW Modbus library: http://sine.ni.com/devzone/cda/epd/p/id/4756 As you can see, people reported it had problems in 8 (and above?) but since the file name is currently ni_modbus8_2.exe, I would assume they have been corrected. As for the arcitecture, of course, I will not miss this chance to suggest mine: I found that if we keep separate notions for state, action, and event, think (and treat) the code in the cases of the consumer loop as actions rather than states, maintain separate queues for events and actions, not only it allows creating a more flexible and powerful architecture, but, most importantly, developing code on a higher level of abstraction (when in this state and this event happens I need to do this, this and this action and switch to that state). Please see the following for further discussion and a more advanced architecture: Despite the pattern discussed there doesn't support hierarchical states (for those implemented see labhsm.com) I found it much more powerful and flexible (yet producing uniformly looking and easily modifiable/maintainable code) than the more primitive producer consumer single queue QSM patterns.

QUOTE(cosmin @ Nov 22 2007, 12:43 AM) And the correct value is determined by what? Say, if we dereference the pointer to a location to which a dll function has written something and we have the definition of the data structure for that pointer in the .h file, how exactly do we choose the PackType? Does it depend on OS, language/compiler used to make the dll, some options set in the compiler?

QUOTE(cosmin @ Nov 22 2007, 12:43 AM) And the correct value is determined by what? Say, if we dereference the pointer to a location to which a dll function has written something and we have the definition of the data structure for that pointer in the .h file, how exactly do we choose the PackType? Does it depend on OS, language/compiler used to make the dll, some options set in the compiler?

Maybe, pointer functions newly available in 8.5 (and DLL Wizard that uses them in wrappers) can help: http://forums.lavag.org/index.php?showtopi...ost&p=38888

Maybe, pointer functions newly available in 8.5 (and DLL Wizard that uses them in wrappers) can help: http://forums.lavag.org/index.php?showtopi...ost&p=38888

Maybe, pointer functions newly available in 8.5 can help: http://forums.lavag.org/index.php?showtopi...ost&p=38888

8.5 now has (exposes) means to work with pointers directly specifically to address the problems in interfacing with C dlls: http://forums.lavag.org/index.php?showtopi...ost&p=38888 These are inserted into wrapper VIs by DLL Wizard, so we can (are allowed) to use them too, I guess.

8.5 now has (exposes) means to work with pointers directly specifically to address the problems in interfacing with C dlls: http://forums.lavag.org/index.php?showtopi...ost&p=38888 These are inserted into wrapper VIs by DLL Wizard, so we can (are allowed) to use them too, I guess.

So, 8.5 can now handle (wrap) dll functions which require as parameters, say, a pointer to a structure, one of elements of which is a pointer to a variable length data. Great! For this purpose the following library is utilised by the DLL Import Wizard (that's how I discovred it): \vi.lib\Utility\importsl It has DSNewPtr.vi to create a pointer (and allocate memory I would assume), DSDisposePtr.vi to (you guessed!) dispose of the pointer (and deallocate memory), InitStr.vi to write data to the memory to which the pointer points and, the GetValueByPointer.xnode (located in the GetValueByPointer subfolder, can be dragged onto BD from explorer, just like a VI, but you can't even open its FP) to retreive the data from the memory location the pointer points to. No documentation though, even in the context help for those top level VIs. So, Anybody has any idea what PackType parameter of the GetValueByPointer.xnode is? Well, what I said would be especially beneficial if on its output wire GetValueByPointer.xnode really has the reference to (address of) the data, not to a copy it creates. They apparently can be used to ensure that passing of (large) data is done by reference (only the pointer is passed around without moving/copying the data itself) not only betweeen LabVIEW code and dll code but also between any of your VI's as well. Well, what I said would be especially beneficial if on its output wire GetValueByPointer.xnode really has the reference to (address of) the data, not to a copy it creates. Interesting: the default string for the InitStr.vi is "Import Shared Library Tool in Jupiter." I wonder what "Jupiter" is/was. My guess is it was the code name for one of the LabVIEW versions.