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)

I guess the PackType parameter is refering to the member aligment (how the structures are packed into memory, 1byte, 2, 4, 8 or 16 bytes).

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)

I guess the PackType parameter is refering to the member aligment (how the structures are packed into memory, 1byte, 2, 4, 8 or 16 bytes).

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)

PS - I have two references that are worth looking at. David Harel's (The Weismann Institute of Science) paper, "Statecharts: A Visual Formalism for Complex Systems," and "State Machines and Statecharts by Bruce Powel Douglass, PhD. (i-Logix). I think Stan or Paul Sullivan gave me these.

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)

When it comes down to it, a State Machine IS nothing more than a hard-wired Event Structure. Your data flow still flows to a decision maker which dictates what the next STATE (EVENT) will be.

Verbage appears to be the only hurdle here as to what it is called, an event or a state. The two really are the same albeit handled a bit differently.

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)

hviewlabs, you'd better remove the email address from your post.

Ton

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 found it here: <http://forums.lavag.org/index.php?act=atta...ost&id=2056>

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