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.

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 LV 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.

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 LV 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.

QUOTE(mross @ Nov 16 2007, 11:52 PM) Yep. I did. I have them on the following page, as well as the link to Dr. Samek's excellent book that was my inspiration for LabHSM: http://labhsm.com/links.htm

QUOTE(EJW @ Nov 14 2007, 05:03 AM) Actually, keeping notions for state, event and action separate helps creating more flexible yet uniform architectures: http://forums.lavag.org/Simple-Event-Drive...imer-t4687.html The above architecture/pattern doesn't support hierarchical states though. LabHSM does (made 4 years before NI's Statecharts "module", mind you)

My design of universal event-driven state machine (EDQSM) which is capable of asynchronous communications with other such modules: http://forums.lavag.org/Simple-Event-Drive...imer-t4687.html This doesn't support hierarchical states though. For that see LabHSM.com

QUOTE(tcplomp @ Nov 5 2007, 04:13 AM) Done. But maybe I shouldn't have. Then some spam bot would pick this email address up and very soon the guy would have got a lot of spam. Wouldn't that be great?

Unbeleivable! I got this crap as a LAVA personal message! Have anybody else got this too or it's only me who is so lucky? Michael, is there a way for these scammers/spammers to mass maile these or did they really have to manually register and then manually send it? In the latter case I hope it won't become much of a problem here. From Prinscar Sango...... Avenue 16 Rue 13 Treichville Abidjan Ivory coast Email contact:(prinscarsango_web001@yahoo.fr) My Dearast One. Greetings to you, i hope this mail will find you well & healthy and i hope we can established a relationship since we are meeting for the first time,i have gone through a profile that speaks good of you and it interests me to contact you for an assistance to help me transfer the Sum of 2 .5 Million USA dollars my father deposited in a bank here in Cote d'Ivoire before he was assasinated. I like honesty,trust,love,truth,caring,& respect,i have all this qulities in me and i believe you have all this qualities too, that is why i decided to contact you for this transaction,ihope to read from you as soon as possible.so please kindly reply me through this email address ( prinscarsango_web001@yahoo.fr) for Ugrent Mail Thanks and hoping to hear from you soonest. Regards, Prinscar Sango...

QUOTE(labviewman @ Feb 14 2007, 08:10 AM) I just tried it in 8.20 (Windows) and it works. Have you put it into <LabVIEW>\project directory?

Please note that the latest version of my PMS Assistant has the private properties and methods of 7.1 and 8.0 hardcoded, so it doesn't depend on the ini settings and still allows you to select those properties and methods in LV 8.2 as well - I just checked this yesterday. Moreover, if you know (or somehow have figured out) private properties and methods new in 8.2 names (or old but not included in my lists) you can just type them in and see if LabVIEW accepts them!

Thank you, everybody who tried to help! I am sorry if some links were inaccessible. Here is what happened yesterday: The valiant and brave effort by Sen. John Cornyn to bring the High Skilled Immigrant Interim Relief Act of 2006 to a vote on the Senate floor has been stymied because of the stubborn opposition of a few anti-immigration senators. All of them had been finally convinced except senator Sessions from Alabama, who has blocked this measure. Highlights of the High-Skilled Immigrant Interim Relief Act of 2006 * Recapture H-1B visas that have been already approved by Congress. Even though there is a limit on the number of H-1B visas that can be issued every year, Congress has in past years authorized a significant number of H-1B visas that have never been used. These unused H-1B visas are needed now, and should be made available immediately. * Assist EB Green Card Petitioners in America Stuck in the Backlogs. The final stage of the green card process provides green card applicants with the ability to live and work in the U.S. without needing to extend a temporary visa. Green card applicants waiting in line for a green card to become available should be given the option, in exchange for the payment of a supplemental fee of $500, of entering this last stage of the process rather than having to continually try to extend their temporary visas. * Exempt Certain High-Skilled Workers from the Green Card Cap. Highly-educated workers who have graduated from U.S. universities with an advanced degree should be able to work in the United States without being subject to green card backlogs. In addition, highly-educated workers who graduated abroad and who have earned master's degrees in shortage fields (like science, technology, engineering, or math) and who have been working in the U.S. for at least 3 years should be exempt from the green card limit. * Recapture Unused Green Cards. As it has with H-1Bs, Congress in the past has authorized a number of high-skilled green cards that have never been used. These are needed now and should be made available immediately to nurses and physical therapists. * Retain Student Talent in America. Retaining student talent educated in U.S. universities is critical to our competitiveness. By creating a new visa (F-4) for foreign students who have been accepted and plan to attend an accredited program to earn a U.S. master