Configurable Discovery #1
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…initializing. Otherwise, it looks like it is frozen for a few seconds.
…14.0 when finished.
…et once the user provides a valid IP Address. Adding a progress dialog so the user can tell RAD is connecting to the target after pressing Get Info. Otherwise, it looks like it is frozen for a few seconds.
… from the network
…ll contain the settings related to how targets are discovered from the network and will be loaded from a configuration file. -Added extra code in the rad_Load Config VI to load from the configuration file rad_config.ini the settings related to how targets are discovered in the network. -Added extra code in the rad_Save Config VI to save to the configuration file rad_config.ini the settings related to how targets are discovered in the network.
…scovered from the network. The name of this state is “Configure Discovery” and it is called from the “Init – Load Config” state. For now, it is only called when RAD starts. -The user can select from 4 different options: a. Automatically discover targets in my local network. This is the normal default behavior from RAD. It tries to discover all the available targets on the local network. b. Discover targets defined in a configuration file. It will only try to connect and list the targets defined in a file. The expected format for this file is 1 target per line, listed by IP Address. c. Only add 1 target that is connected over USB. This only applies for Linux RT targets that can be connected through USB with the IP Address 172.22.11.2. d. Do not discover targets. I will add my targets manually 1 by 1. No targets will be searched from the network. The user can add them manually 1 by 1 later. This is implemented in the rad_Configure Discovery Settings.vi by modifying the User Added Targets and Target Types parameters in the main state cluster.
…when needed while the utility is running and not only when it launches.
…tly showing up as disconnected. With this we limit the possibility of trying a retrieve or deploy.
…covery configuration at launch.
…d tested deploy/retrive of images for LinuxRT, Pharlap and VxWorks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[x] This contribution adheres to CONTRIBUTING.md.
TODO: Check the above box with an 'x' indicating you've read and followed CONTRIBUTING.md.
What does this Pull Request accomplish?
The user is now capable of choosing how targets are discovered from the network. User can select from the next options:
Why should this Pull Request be merged?
Some users complain that RAD takes a long time to discover targets on the network. A big part of them are not needing to automatically discover targets from the network since they already know their IP Addresses. With this feature, users can save time by configuring how RAD adds targets.
What testing has been done?