Communication with 3 cRIOs over WiFi with one host vi

[MP10]

Hi all,

I am starting a new project, where I want to communicate with 3 cRIOs. Each would communicate with host PC over wifi. Each cRIO would be running the same FPGA vi and the same RT vi. All the cRIOs should be able to be controlled from one host PC vi.

Few months ago I was able to communicate with just one cRIO from the PC vi. I did it using open application reference, open vi reference just as it is in cRIO development guide, as can be seen in figure oneCrioComm.PNG.

I was thinking to do it in a similar way, i.e. open 3 application references (one for each RT vi), then open vi reference (one for each RT vi), as in figure 3cRIOcomm.PNG (a pseudo code) and then communicate with each RT over shared variables and network streams.

Is this a proper way how to access each crio from just one host PC vi? Or do I need to do it in a different way?

Looking forward to any hints, comments, white papers, or any other sources of information. 🙂

cheers, MP

[edjones93]

Hi there!

I am an NI Instructor and have taught the Embedded Control and Monitoring course several times. However was quite surprised to hear this methodology being suggested in the developer guide, the intended methodology we outline in the course is that:

1. During the development stage, deploy VI's and run through the project explorer and communicate, as you mentioned from shared variables and network streams.

2. During the deployment stage - typically you would be deploying for long term usage/running. Create an executable, deploy this onto the machine and run as startup.

However I suppose there is nothing wrong with your methodology, whats the application and real world project?

Is this intended for long term application running?

Do you find your current methodology to not work? (Note: you could open the references in a For Loop and keep them as an array of references, it will make for cleaning code and easier to add more systems as and when you need (see attached).

Another methodology I have actually myself created in the past is very similar to your own. I created an example linked below:

https://forums.ni.com/t5/Example-Program-Drafts/Aynchronously-calling-VI-s-on-a-Remote-Machine/ta-p/...

This is essentially a network abstraction layer, which worked around a real world reason to have a security layer.

However the network abstraction layer shows having a controlled methodology of shutting down the VI's, I would think that if you close reference it is the same as aborting the VI. For Real Time Control and Monitoring applications this could be undesirable, for instance, the RT is a production line control system for a robotic arm, having it shutdown in undesirable states could create safety hazards.

Without seeing all your code I can't verify the methodologies used, do you have state used to tell the VI's to move into a shutdown state safely?

Thanks,

Ed

[MP10]

Thank you Ed for your reply. 

I tried the approach I described a few months ago and I thought I saw it in cRIO dev guide, but I might have seen it somewhere else, sorry for the incorrect reference.

However I suppose there is nothing wrong with your methodology, whats the application and real world project?

My project description:

There will be 3 vehicles, each equipped with one cRIO which would be controlled from one host PC VI. The cRIOs will be logging a data from the CAN bus and additional analog and digital channels. The cRIOs should be synchronized (need to solve later). The measurement of each cRIO should start and end by a command from a host PC vi and the PC and the cRIOs should be connected over WiFi. At the best the measurement starts at a specific time, which places a requirement on a time synchronization of the cRIOs. So it is not meant to be designed for long time operation.

Do you find your current methodology to not work?

I have not tried the approach of 3 cRIOs as described in my first post yet. Before deeper coding I wanted to know if that could be a doable way. However, with one cRIO it works just fine.

Without seeing all your code I can't verify the methodologies used, do you have state used to tell the VI's to move into a shutdown state safely?

I have always used a state machine in the RT part of the application whose one state is a shutdown state. This state machine comes to the shutdown state when it receives a command of the state from the PC vi through a network stream. However, I am not sure if this is a safe way of shutting down the vi and if it is resilient against any deadlock or application hanging. On the other hand, I have not had any problems with this method yet, never had a system with dangerous/unsafe state.

So if I understand it correctly, I can do it in a following way:

1. Create a project and put all cRIOs into the project.

2. Code FPGA vi, RT vi and place them into each target with modified network parameters.

3. In each target make the RT vi executable at the startup.

4. Code the PC vi that communicates with the targets over shared variables and network streams.

Is this a good way? 

Thank you for the help.

cheers, marek

[edjones93 · Accepted solution]

Hello Marek,

You are correct in the potential next methodology of using a project. Although coding re-work would need to be done, such as having the initialisation controlled by the PC via shared variables maybe?

Given your application and you mention vehicles, maybe you should check out VeriStand. It allows a completely configurable environment for CAN, Analog and Digital DAQ measurements and controls.

It is a deterministic environment and essentially removes all needs for coding (unless going outside the remit of what is currently possible - expand-ability). For synchronisation, do the cRIO's measurements need to be synchronised with one another?

Anyway, seems you have the method (project explorer with multiple targets). Or you could check out VeriStand and see whether it is applicable and more convenient for your needs:

http://www.ni.com/veristand/

http://www.ni.com/veristand/demos/

http://www.ni.com/veristand/applications/

Could you mark the solution so this post is closed off also?

Thanks,

Ed

[MP10]

Hello Ed,

thanks for the confirmation of the proposed approach. Veristand sounds like a nice option, but out of our budget (university project). So we need to work with what we got.

The crios should be gathering data from the vehicles that would be moving in front of each other and their ADAS systems would be validated, hence the synchronization of the crios is important for the validation. It would be nice if they share the same wall clock with tens or max hundreds of milliseconds offset, so that they start the measurement at a specific time, e.g. 3:00:00 pm. We do not have GPS module either, so this kind of solution is out of question.

Anyway, thank you for the help.

cheers, marek