Process Spawning Design Pattern

[Jim Kring]

Hello, all. Michael Aivaliotis gave a good NI Week presentation on process spawning. One factor to consider is the apparent limitation of LabVIEW in that it cannot instantiate new VIs when the root loop hangs (please the bug posting here for more info).

Do any of you out there use this (Process Spawning) design pattern?

[hmqi]

Do you have the ppt file about his topic?

[Jim Kring]

Do you have the ppt file about his topic?

3033[/snapback]

Michael Aivaliotis gave the presentation. Send him a request.

[Michael Aivaliotis]

Michael Aivaliotis gave the presentation.  Send him a request.

3039[/snapback]

Here:

Process Spawning

[hmqi]

Here:

Process Spawning

3043[/snapback]

Thank you very much! It's a great topic!

[bariman8]

Jim,

On a recent project I designed a CAN "server" that would actually spawn new engines for each CAN card configured using a configuration tool. Each engine would be initialized with User event references to hook into any main program. The engine would then take care of sending/receiving event driven messages or periodic messaging.

I have to say that Michael Aivaliotis' NI week presentation opened up my eyes to this new idea in coding style. I think my next foray will be into the wonderful world of GOOP

:beer:

Derek Lewis

[Jim Kring]

Jim,

On a recent project I designed a CAN "server" that would actually spawn new engines for each CAN card configured using a configuration tool.  Each engine would be initialized with User event references to hook into any main program.  The engine would then take care of sending/receiving event driven messages or periodic messaging. 

I have to say that Michael Aivaliotis' NI week presentation opened up my eyes to this new idea in coding style.  I think my next foray will be into the wonderful world of GOOP

:beer: 

Derek Lewis

3432[/snapback]

GOOP and Process Spawning are can be used together very nicely. For example, when spawning multiple processes (multiple instances of the same process), it is often a good idea to create a new instance of a GOOP object associated with it for managing the instance's data. Usually, I accomplish this, by doing the process spawning inside of the GOOP object's constructor. I pass the process a reference to the GOOP instance, and then the process can access the instance's data store, using that reference. I store the spawned VI's reference inside of the GOOP data store, so that a call to the GOOP destructor can kill (Abort) the spawned VI, if it can't stop it using some form of messaging.

[bariman8]

Very Interesting Jim,

I definitely need to look into GOOP design. Do you know of any good websites out there that explain GOOP and its functionality? I downloaded the OpenG GOOP toolkit but a lot of it doesn't make sense to me.

Thanks,

Derek Lewis

[tetrarch]

Very Interesting Jim,

I definitely need to look into GOOP design.  Do you know of any good websites out there that explain GOOP and its functionality?  I downloaded the OpenG GOOP toolkit but a lot of it doesn't make sense to me.

Thanks,

Derek Lewis

3439[/snapback]

Plenty of links here. Some of them might even still work... you might want to read up about OO design methodologies and UML notation, if any of it is unfamiliar.

[Jim Kring]

Very Interesting Jim,

I definitely need to look into GOOP design.  Do you know of any good websites out there that explain GOOP and its functionality?  I downloaded the OpenG GOOP toolkit but a lot of it doesn't make sense to me.

Thanks,

Derek Lewis

3439[/snapback]

Here is a page at OpenG.org which is dedicated to GOOP information:

http://openg.org/tiki/tiki-index.php?page=GOOP