Best Architecture - Object Oriented Programming on a Desktop and Real-time Target. Best method of passing data between classes on both targets?

[Muelmann]

I'm planning to use an object oriented programming approach on both the desktop and real-time targets in a project that I'm working on.  (I understand that object oriented programming just became possible for real-time targets with LabVIEW 2009.) 

I'd like to use the same set of LabVIEW classes on both the desktop and real-time targets because the same set of data needs to be read, processed, and modified by both targets.  Because the data is common between the two targets, I need to ensure that the class data on both targets is kept the same and I also need to ensure that both targets do not modify the data simultaneously.  

Does anyone have any suggestions for passing and synchronizing the data between the classes on both targets?  I'm new to both LabVIEW RT and object oriented programming.  Thanks.

[George_P_Burdell]

Muelmann-

You are correct that we have just begun support on Object-Oriented Programming in Real-Time.  Because you are new to OOP, please take a look at the links below.  They are very detailed about how to get started with OOP and how it works in LabVIEW. 

NI Developer Zone: Graphical Object-Oriented Programming In LabVIEW
NI Developer Zone: LabVIEW Object-Oriented Programming FAQ
LabVIEW 2009 Help: Creating LabVIEW Classes

The classes can be the same on both the host and the target with LabVIEW OOP RT.  If you plan to use your host as a monitor for your target, you won’t have to do anything different.  If you plan on creating a vi on your host that modifies these classes, you will need to use shared variables or TCP/IP communication protocols to ensure proper communication.

[Muelmann]

Mike,

Thanks for the links.  Both the vi on the desktop host target and the vi on the RT target need to be able to modify the class data.  If I use shared variables, how can I ensure that the desktop target and RT target do not try to modify the data at the same time.  (p.s. If I copy the classes to both targets, I'm a little fuzzy on where the data is actually being stored.  Is it on the RT target or desktop target?).

Do you know of any examples of using OOP on RT targets that I could take a look at?

Thanks,

Muelmann 

[jkurtw]

Hi Muelmann,

I don't know of an example to point to that accomplishes what you are asking.

" I'm a little fuzzy on where the data is actually being stored.  Is it on the RT target or desktop target?"

You make this decision by hosting your shared variables on one target or the other. If your host machine is always going to be online and connected to the RT target, then you should be fine hosting them there. However, if the host may become disconnected from the RT target at anytime and the RT target needs access to the variables at all times, then you may want to host them there on the target.

CPU power is another consideration. Is your RT target a PXI/PC target or cRIO?  

For considerations on where to host your shared variables, check out the shared variable white paper and see the section called Recommendations for Shared Variable Hosting Location.

If you are using shared variables you don't need to worry about your host and target VI modifying the object at the same time. The shared variable engine will handle multiple requests without a problem. 

Kurt 

[jkurtw]

Hi Muelmann,

I started to mock up an example for you and then quickly realized that this is more complicated than I thought.

The objects you create will be in local memory on the RT target or on the host, depending on where you have the LabVIEW Class in your project window (if its under the target, it will deploy there and if its under the host it will deploy to the host.)

Therefore, you cannot call properties and methods of an object on the target that it does not reside on.

I am guessing this is exactly what you were asking in your first post 🙂

Attempting to "reflect" these objects on both targets and then synch. the data between them will be pretty difficult. You would need to build in a mutex for when the shared data is accessed and this would prevent your RT target from being "real-time" since you have Windows putting mutexes on your data.

A simpler way to architect this would be to put the classes/objects on the target that will be the primary accessor of the objects and then provide some commands that can be sent to that targets for accessing object data.

For example, if you put the objects on RT, then you could create some commands from Windows such as "Get object data" or "Set object data", where you send an object name or ID along with some data to set. This way you avoid the architecture challenge.

Do both targets need first class access to your objects?

Kurt  

[Muelmann]

Kurt,

My real-time system is cRIO with a 9012 controller and 9112 chassis.

The project I'm working on is a Hardware in the Loop Simulator.  The majority of data modification would need to take place on the cRIO setup as it will be taking measurements from the outside world, doing some processing, and then simulating additional signals based on the previous measurements. 

For the most part, the host PC just needs to monitor and display to the user what the cRIO setup is doing, but in some cases the user would need to be able to manually set the output from the cRIO or change the way the cRIO responds to stimuli.

Based on what you've told me, it sounds like I should host the objects on the cRIO setup since that is where the majority of the processing is taking place.

Based on what Mike mentioned above, it sounds like I could monitor the data in these classes from the PC host without much difficulty.  How is this accomplished?  Is it handled automatically?  

Kurt, for the case where I need to modify the data on the cRIO device from the PC host you mentioned the following: "create some commands from Windows such as "Get object data" or "Set object data", where you send an object name or ID along with some data to set".  Would you do this with shared variables or some other means?

Also, an additional question:  I noticed that it is possible to copy the same class to both the my computer target and the RT target.  If this is done, how does the system respond, would each target have it's own unique data?

Thank you very much for your help,

Muelmann

[jkurtw]

Hi Muelmann,

Here are some thoughts...

"Based on what you've told me, it sounds like I should host the objects on the cRIO setup since that is where the majority of the processing is taking place. "

I agree 

"Based on what Mike mentioned above, it sounds like I could monitor the data in these classes from the PC host without much difficulty.  How is this accomplished?  Is it handled automatically?" 

This will not be automatic, since the objects are in local memory on your cRIO controller. You will need to extract the data and put it into a shared variable, whose type is a custom control that matches the data contained in the object. You can do this on demand when the host requests the information. 

"Kurt, for the case where I need to modify the data on the cRIO device from the PC host you mentioned the following: "create some commands from Windows such as "Get object data" or "Set object data", where you send an object name or ID along with some data to set".  Would you do this with shared variables or some other means?"

 Yes you can use shared variables. 

Check out section two of the CompactRIO Developer's Guide 

http://www.ni.com/compactriodevguide/

See Chapter 4 » Communication Using Network Published with Shared Variables » Using Network Published Variables to Send Commands

"Also, an additional question:  I noticed that it is possible to copy the same class to both the my computer target and the RT target.  If this is done, how does the system respond, would each target have it's own unique data?" 

In short, don't do that 🙂

When you put the class under a target it is just defining the class properties and methods for that target. Then, when you instantiate an object on the diagram, that object is just data on a wire like any other data in LabVIEW. So, it is not shared to other targets and if you instantiated objects of the same type on different targets they would have their own unique data, just as if you created array constants on two different targets.

"Thank you very much for your help" 

You are welcome!

Keep the questions coming.

Kurt 

[jkurtw]

Any progress?

[Muelmann]

Kurt,

Thanks for checking in.  Here is what I'm trying currently:

I'm using a shared variable to pass a cluster consisting of a command and variant data from the desktop target to a queue on the RT target.  The RT target reads each element in the queue and executes a particular case of a state machine depending on the command from the desktop target.  The cases call methods of the classes hosted on the RT target and set the data to match the variant data recieved in the shared variable.

I'm planning to use the same architecture in reverse to pass data from the RT target to the desktop target using a separate shared variable and queue. 

I'm also looking into the possibility of copying objects from the RT target to the desktop target since the majority of data needs to be duplicated on both targets.  I now know that the data will be unique (not linked) between the two targets (thanks!), but I'm planning to use the shared variable, queues, and state machines mentioned above to keep the data in synch.  I'm trying to do this because the data structure is nearly a duplicate between the RT target and desktop target and I didn't want to have to recreate all of this structure for both targets. 

Having separate data structures on each target for the same data could prove to be especially cumbersome if I had to modify the code in the future.

What do you think of this method?

Thanks,

Muelmann

[viScience]

You could create NSV bindings between your RT target and windows and the data types could be type def'd in the project.