09-29-2016 01:29 PM
But you can set the ip from the RAD interface of discovered targets?! (Unless that only works after it has been configured once already? I've not set a cRIO to 0.0.0.0 / factory default in awhile.)
I'm trying to nail down a possible new bug/problem where the workaround is also a 'do it twice' .. but I have not proven the steps to reproduce it yet.. so ignore me. 😉
09-29-2016 01:33 PM
Yes, if RAD can see the target, you can select the Configure wrench icon under the Target table and set an IP address.
I was feeling especially paranoid when I thought to try resetting the IP. But it was to reproduce the issues a tech would face with a brand new cRIO.
09-29-2016 02:14 PM - edited 09-29-2016 02:20 PM
Yeah, I hear you. For a long while, I had a dirt simple cRIO tool that seemed to work better than MAX and RAD combined for some obscure reason.. All it did really was 'find all targets' and allow the tech to set ip configurations on a(ny) target found, compiled as an LV exe, but a lot of that went away when "System API" was introduced as the legacy functions that worked so well got relegated to obscurity. 🙂 (Edit: it did or attempted to do most actions by using the MAC address, not the ip, as a first choice of contact.)
It's incredibly frustrating that years down the road, proper and well behaved tools for creation, management and deployment of images on RT targets remain so .. elusive. <shrugs>.
10-03-2016 10:20 AM
Summary of my recent lessons learned on NI RAD / cRIO image creation and image deployments:
1) Do NOT blacklist, delete, change anything in your c:\tmp folder! Depending on your NI software modules (and target), contents in the c:\tmp folder is NOT optional, and in fact critical to proper module functions. If you delete the tmp folder (or black-list it), several modules (including most/all of the Web interface modules) will no longer work, and RAD can/will give errors on retrieval and/or deployment. This behavior is now documented and known by NI, but no plans to 'fix' it exists. This issue is confirmed on (older) vxWorks targets. (It may not affect LinuxRT targets as they use a different folder structure entirely.)
2) Do NOT create an image of a target while you are logged on (via Web Interface)! Doing so makes RAD error out on deployment of image with an NI Auth. related error. no functional issues other than the deployment error seems to occur, so this is mainly a deployment training issue.. still.. best avoid being logged in period.
12-30-2016 05:04 AM
It would be nice if the location for settings was changed to somewhere with write-access/according to the OS recommendations. Currently RAD, when built as an application, will try to store settings in the same directory as the executable. That's not allowed in Program Files on Windows. The user's local appdata folder would work better for example.
01-31-2017 08:42 AM - edited 01-31-2017 08:44 AM
I had one funny problem after building an application of a slightly edited source code: I had changed the location of configurations to a folder under APPDATA, when deployments stopped working (in the built app only).
As it turns out this was because when NumInBatch is read from the rad_config.ini by rad_ReadTargetConfigOptions.vi the read is done without specifying a default value. The default then became 0, which in turn is accepted by the rest of the code, and cause the deployment to run forever (as the number of units to deploy to in parallell is Zero 🙂 ). So if you do change the config location as pe rmy previous suggestion - please also make sure the config reads have valid defaults and/or that the parts using those configurations do a sanity check on them...
Oh well...
05-03-2017 04:35 PM
I use the precompiled RAD exe. I have a feature request. Can you change the application icon? I don't really care what you change it to. Just something other than the default LabVIEW icon so that I can tell which icon in my taskbar is RAD.
05-04-2017 01:26 AM
Yes, but you need to rebuild the exe-file then. Create a build specification for an application (exe), in the properties window select "Icon" as Category, and select a new icon => Build 🙂
06-09-2017 11:47 AM
The source code for the Replication and Deployment utility is now available on GitHub at https://github.com/ni/rad
08-03-2017 09:38 AM
Hi folks,
It has been a while, but I am hoping that some of you have seen my issue and have already found a solution.
In about 4 cases now I have reports of RAD being deployed to various images we use and not working. Twice, it takes about 30 minutes for the refresh to complete and show the cRIO that is on the network. In the other two cases, refresh completes quickly but the cRIO on the network is not shown in the list of targets. In all of these cases, the cRIO responds to a ping and is accesable from other machines on the network. (The solution has been so far to take a machine from which RAD does work and perform the install from there.)
I suspect there is something about the image. In our deployments, we use hard drive images or in some cass virtual machines to run our applications. This is obvioulsy for quality control. We make sure the computer is exactly like we want it to run our applications on site. But what would do this?
Has anyone else run into RAD failing to find cRIOs or taking a long time to find them?
Thanks!