change ip on locked real time

[Adao]

Hello all,

I would like to know if it is possible to change the IP Address on a real time system that is locked?

Thanks,

Adam

[MikeS81]

Hi Adam,

what type of real time system do you mean? If you have a PXI or cRIO and you have locked your device from MAX, then you need a password to unlock it before you can change the IP.

Mike

[Adao]

Hi Mike,

I really did not explain myself well.

I am developping a real time based device that I want to sell to my clients locked because I don't want them to have access to the FTP.

However the communication with the device is made using TCP/IP and so I want them to have the possibility to change the IP Address. I have done this using the replication tools from LabView RT. The problem is that when I lock the RT system I am not able to change the IP - as expected.

So my question is: can I programatically change the IP address on a real time system the is locked?

Tks,

Adam 

[YannC]

Hi Adao,

I think It's possible, have a look to this KB  :

How Do I Programmatically Change The IP Address of My Real-Time Controller?

Changing FTP Server Password for FieldPoint or CompactRIO Real-Time Controller

I hope that will help you.

Regards

Message Edité par YannC le 02-10-2009 09:03 AM

[MikeS81]

Hi Yann,

your links don't work for me.

Mike

Message Edited by MikeS81 on 02-10-2009 04:02 PM

[YannC]

Sorry, 

Changing FTP Server Password for FieldPoint or CompactRIO Real-Time Controller

I search another way to solve your problem.

Regards

Message Edité par YannC le 02-10-2009 09:14 AM

[Adao]

Hi Yann,

On the link you supplied it only shows how to change the FTP Server Password on a Real-Time Controller on MAX.

I need to do this programatically on a locked real time controller. 

As a stated before I lock the real time controller using MAX but I want the end customer to be able to change the IP Address. Is this possible?

tks,

Adam

[YannC · Accepted solution]

Hi Adao,
A way to change IP address is to modifying the contents of the RT.ini files. The RT.ini file is located in the controller’s root directory.
You need to download the RT.ini file and change the IP_Address key in the TCP_STACK_CONFIG section.
You can use the configuration file Vis palette (Programming»File I/O»Configuration File Vis) to modifying the file.
After you finished modifying the ni-rt.ini file, you need to upload the file on the RT target.
The changes take effect when you reboot the controller.
To upload and download the file, the easiest way is to use the internet toolkit.
I hope it’s clear.
Regards

[robdevyogi]

There is also a VI for this purpose (LV 8.5.1 at least) called "Set IP Address.vi" in "System Replication.llb" (look for it on the help menu on the block diagram under User Libraries/RT System Replication).

From what I have encountered just changing the .ini file is not the same as using this VI. It may work in most cases, but not for a problem I was wrestling with when I was developing an application for automating replication.

The issue I had was not being able to read from the FP of the FPGA from the RT Host code. (For this project I did not embed the bitstream into the exe, which is default when building the executable for RT Host. I have the bitfile set to run automatically on power up. So this case may be unique.)

When I changed the IP address of the target system (compared to the image I had) then I was unable to read the FP I/O of the FPGA.  When I changed the IP back to original crio's IP, it was working again. On the other hand, when I used the Set IP Address.vi then the system worked fine even after applying a different IP. The difference I found between a working system and a non working syste (that had the same IP applied to them, but using different methods), was due to a change in system\config3.mxs file (this changes was done by LV in the background at some point). Somehow this file is updated if you use the Set IP Address.vi (everything works then).  I verified this by copying over one of two config3.mxs files that I had previously backed up and was able to observe that one file caused FPGA FP to be readable while the other didn't (all else equal).