Detecting cRIO systems Only Supported by My Software

[TailOfGon]

First of all, I am developing a cRIO based system. Multiple systems will be installed in the customer's lab. We are providing a host software that will be installed to a customer's PC that controls the system.  Please bear with me. I may be a CLA but I have not developed any embedded systems for customers whatsoever.

One concern I have is that customers need to figure out the IP address of the cRIO in order to communicate with the system. MAX can be used for identifying the IP Address, but it does not sound right to open another application to do that. I would like more self resolving scheme. After I made some research, I learned that System Configuration API can be used to query all the available cRIO systems in the local subnet. Maybe I can use this API and populate the drop-down list control so customers can easily select from it. But if there are other cRIO systems from a different company is connected in the same lab, they will be detected too. I would like to filter those out when providing the list to customers.

One idea I have is at the manufacturing process of the system, we set a host name to have a specific format such as <company name>-<system type>-<serial number>.  Also, we put the serial number sticker on the system enclosure. This way the software can eliminate the cRIO devices not supported by our software. Also this solution helps customers to tell visually which system they are trying to connect to (if they have multiple systems in the lab).

To summarize, here are questions I would like to solve:

• How can a host software creates a list of IP/DNS Names that the software is supporting? Is there are standard way that I am not aware of?
• Is it a common practice to let customers to open MAX to figure out IP Address?

Thank you

[Alexander_Sobolev]

I would keep the list of pairs Serial (or name) - IP of your cRIOs in settings file

Display this list to customer, connect when he selects one. Scanning network may take time, no need to check full list every time. If customer wants to add a new system or locate old one - add by IP, by serial or scan local subnet and show full list. NI serial is one of the properties you can get from chassis while polling.

Customer network configuration can be different from what is set during manufacture, so cRIO may need to be reconfigured. Manual configuration of cRIO and opening MAX should be as an option for complex cases, but not on regular basis.

[rolfk · Accepted solution]

First step is to discover any cRIO that is present in the network. For this the NI System Configuration API comes in handy. This allows your host application to create a list of cRIO systems that are currently visible in the local subnet. Then your cRIO app should have some form of network API. I use my own variant of something along the lines of the CurrentValueTable with Simple Messeging (STM) extension. Being able to connect to your cRIO app on the intended port number is already a pretty good indication that it is one of your systems. To be fully sure you can implement some identification query in your TCP server which will give you enough information to securely identify your system.

[TailOfGon]

Alexander_Sobolev:

Thanks for the response. It's a good idea to keep the full list in the config file. I expect 99% of the time a customer will connect to the same target. Displaying the cached list and also providing 'Refresh' button makes sense to save time.

>> Customer network configuration can be different from what is set during manufacture, so cRIO may need to be reconfigured. Manual configuration of cRIO and opening MAX should be as an option for complex cases, but not on regular basis.

Good point. In rare cases, customer may want to change the hostname to something else. Only allowing to connect to target whose name is in the specific format will not work in this case.  I'll keep that in mind. I will still allow users to type in whatever the IP address or DNS name they want.

[TailOfGon]

rolfk:

>>Being able to connect to your cRIO app on the intended port number is already a pretty good indication that it is one of your systems. To be fully sure you can implement some identification query in your TCP server which will give you enough information to securely identify your system.

Thank you for advice! Creating a concurrent process to serve the system information to other computer sounds like a great idea!  It enables other users to retrieve the system information even when there is an existing network stream connection with other PC.