Real Time Project Common Code Organization

[stevem181]

Hi Folks,

I am working on a RT project using multiple cRIO chassis.

I have common RT code that I want to use with the different cRIOs.

What is a good way to organize the common code in the project?

For example. I have folder called "RT Common".

It seems that I have to place folder this folder under a particular cRIO in order for the vis to be recognized as RT.

Are there any other options?

Thanks,

steve

[df86 · Accepted solution]

No.

They will all point to the same VI and location but since each CRIO has it's own compiler you need to place the code under each cRIO.

But if you make a change to the VI under any of the cRIO it will update for the rest also.

[GregFreeman]

---

@df86 wrote:

No.

They will all point to the same VI and location but since each CRIO has it's own compiler you need to place the code under each cRIO.

But if you make a change to the VI under any of the cRIO it will update for the rest also.

---

This isn't necessarily true. It should automatically get put into the dependencies on a per target basis, if it is referenced in a VI that is on a specific target. For organizational purposes, however, you may find it best to have the folder itself under every target.

[nathand]

You can place the same code under multiple targets, which is how I would handle this.

However, if your common code uses OOP, be aware that loading a class in more than one instance causes the class to be locked, meaning you can't edit it.

[GregFreeman]

---

nathand wrote:

However, if your common code uses OOP, be aware that loading a class in more than one instance causes the class to be locked, meaning you can't edit it.

---

*headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang*

 *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang*

 *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* 

*headbang* *headbang* *headbang* *headbang* *headbang* *headbang* *headbang* 

[nathand]

A bit off-topic, but Greg, that's exactly how I'm feeling at the moment. I'm working on a project that will run on a steadily-growing number of sbRIOs spread around our labs, and instead of adding new targets to my project, I'm instead stuck with a single target for which I constantly change the IP address, with the accompanying risk that I'll accidentally load a new version onto the wrong target.

One of the reasons I went with classes in the first place was so I could easily replace the FPGA with a simulation (all communication to the FPGA is routed through a class), then run it on my desktop - but guess what, I can't do it without breaking editing of the parent class!

[GregFreeman]

Yes, hopefully not derailing too much, but my issue normally comes about because I have a reusable network messenger, and whenever I process incoming messages I need to unflatten them. That creates a static dependency in the receiver. There is obviously already a static dependency in the sender, so there are now dependencies both on the "my computer" target and the "remote" target. This keeps me from having the ability to edit the contents of a message if need-be. This also happens when I have a "config" class on the host, and want to use that same class on the RT to load and store the config content that was configured on the host. You try to add something to the config and you can't. So, I feel your pain.

[stevem181]

Thanks Dan and others.

I didn't realize I could just put the folder under each of the cRIOs .

That's exactly what I needed.

steve