The CAR that you referenced has been rejected since the RT replication VI's are being obsoleted by the new NI System Configuration VI's. I need to double check, but I don't believe the NI System Configuration Get/Set Image VIs have the issue that you mentioned in CAR 190786. To my knowledge the System Configuration VI's simply disable all secondary NICs to avoid any MAC corruption. However, we are currently evaluating some of the additional options that I listed above.
We are still working through migrating the RTAD from the RT replication VI's to the NI System Configuration VI's. More to come on that later.
It's nice that there is a new software on its way that will solve the issue, but there are lots of user's out there that might get in serious trouble when using the old software because the netconf.ini file gets corrupted.
How are they to find out about this unless that information gets easily accessible? With controllers comes higher requirements for reliability, not just on the OS and hardware, but to the whole chain of tools involved. You could say that the problem is not really in RTAD, but the underlying API so I'm barking up the wrong tree, but I'm not sure where else to go, especially when a similar CAR has been denied already (or does it not really cover the problem I'm describing?). By the end of the day it does not matter, it's all tools from NI.
I just re-checked the Known issues section on the RTAD page and it does not mention anything about corrupt netconf.ini files, just a minor issue of not transferring the NIC2 IP setup.
Actually, I think the known issue that is listed in the RTAD "Secondary NIC settings aren't applied with an image unless deploying to the exact same controller the image was created from." is trying to document the issue that you are seeing.
Now its possible we could update the wording to more accurately describe the symptoms you are seeing. We could simply stated that it will corrupts the netconf.ini, but I don't think that isn't correct since the file isn't actually corrupted (aka malformed). It just contains values that are irrelevant for the new system since they are tied to a specific MAC address that doesn't exist on the new system.
Yes, but it seems that if the file starts with a section named after a nin-existing MAC-address this will change the behaviour of the controller (it will no longer get online if booted with both ports connected to a non-routed network, if only port 1 is connected, or any of the two are on a routed network (or it could be the DHCP server there) then it will not come online. Delete that empty section from the netconf file, and voila - problem solved. That's why I use the term "corrupted" - but you I agree that the system itself should be able to handle that leftover section. It does if the section is at the end of the file, but not if it's at the start.
I am using the System Replication Toolkit, and I am running into problems because there are several VIs in this toolkit that are password protected. It is our internal policy not to include any password protected VIs in our source code. We have several reasons for this. The reasons that may also apply to code developed outside of our organization are:
1. If you are searching within the code for a particular function or comment, you will not be able to find it in any locked VIs. This could impair understanding of the code.
2. You cannot look at locked VIs to better understand how they interact with the rest of the code. This could also impair understanding.
3. It’s not great for morale to have source code locked up out of sight from and protected from your software engineers.
At http://www.ni.com/white-paper/3937/en#toc8, there are a few comments from other users requesting the password, but no replies.
I understand that there is a new toolkit called System Configuration which is intended to replace System Replication. But since I'm working in an environment with a large overhead for code changes (validation efforts), it will be some time before I can have the option of changing over to System Configuration.
Does anyone know the System Replication password?
I just wanted to send a brief notification that a major update to the Real-Time Application Deployment (RTAD) utility is now live.
There have been many significant changes. First of all, the utility has been renamed to the Replication and Deployment (RAD) utility. It is also now built using the System Configuration API which, in addition to improved performance and stability, provides new features like progress bars, blacklisting, simultaneous image deployment, and much more. Please feel free to post any questions or feedback regarding the new utility on this discussion.
Someone else may be able to reply with a password, but unfortunately I probably cannot help you there. A significant portion of the VIs installed by LabVIEW Toolkits and Drivers are password protected. Why is this toolkit an issue in particular?
I would highly recommend moving over to the System Configuration API if possible. The VIs you have linked are no longer actively under development. The System Configuration API is also password protected, but offers better performance and a much wider feature set.
If this isn't an option, and having the password is a necessity, my only other recommendation would be to contact NI Support. I don't think its likely they will be able to provide it either, but hopefully they can give you a definitive answer. I apologize I couldn't be of greater help, but I wanted to make sure you got a response.
Thanks for the response! This toolkit is apparantly one of the few that we are using that are password protected. We may move to the System Configuration API in the future.
The source code download contains an application build specification that lacks several items. You have to manually add the main VI, as well as dynamically called VIs like the progress bar.
It would be great if this was fixed so that future downloads do not require another modification of the build spec to get it right.
Thanks for pointing this out. This is the third time the build spec settings have simply disappeared and I haven't been able to figure out why. I will see about getting this fixed. In the meantime, I have attached a screenshot of all of the files that that require special settings. The Progress Popup folder should always be included as part of the main exe. The rad_config.ini file needs to be stored in the same directory as the exe. Finally, the Download Bitfile.vi and Set RIO Device Settings 2010.vi get added to the support directory or data folder. These two vis have a dependency on RIO, and only get called if a bitfile for flash deployment is detected. If you don't plan on ever using the FPGA Flash deployment feature, you could leave these two vis out of the build entirely.
Also just as an FYI, I believe the issue with the secondary NIC settings that you were running into with the previous version of the utility is resolved. Please let me know if this is not the case, and I look forward to any other feedback you may have.