Search the Community
Showing results for tags 'calibration'.
Found 3 results
Hi I have a camera set to observe an inside of a pipe. Because I know the angle of the camera and where is it situated inside the pipe, I can produce an array of points that correspond to specific pixels. Because the camera can move up and down and change the angle, I have to do it dynamically, so I can't load any calibration template because the calibration is changing on the spot. So I've managed to create the calibration points and pixel points, but after using them in Learn Perspective Calibration.vi image doesn't change. See .zip attached What am I missing? Please help caltest.zip
I am using LabVIEW Vision Express for lens calibration (Distortion model grid) of a telecentric lens arrangement and I am using edmund optics multi-frequency grid for calibration. After generating a calibration template, whenever I try to reuse the calibrated template for calibration of newly acquired images, I am not able to edit the template after loading it. The "Edit Template" option remains disabled after importing an existing template. I am using LabVIEW 2016(32 bit) version. I have tried the same process on LabVIEW 2015 version and it seems to work perfectly on that version. Could anyone please help me with this.
Hello again LAVAG, I'm currently feeling the pain of propagating changes to multiple, slightly different configuration files, and am searching for a way to make things a bit more palatable. To give some background, my application is configuration driven in that it exists to control a machine which has many subsystems, each of which can be configured in different ways to produce different results. Some of these subsystems include: DAQ, Actuator Control, Safety Limit Monitoring, CAN communication, and Calculation/Calibration. The current configuration scheme is that I have one main configuration file, and several sub-system configuration files. The main file is essentially an array of classes flattened to binary, while the sub-system files are human readable (INI) files that can be loaded/saved from the main file editor UI. It is important to note that this scheme is not dynamic; or to put it another way, the main file does not update automatically from the sub-files, so any changes to sub-files must be manually reloaded in the main file editor UI. The problem in this comes from the fact that we periodically update calibration values in one sub-config file, and we maintain safety limits for each DUT (device under test) in another sub-file. This means that we have many configurations, all of which must me updated when a calibration changes. I am currently brainstorming ways to ease this burden, while making sure that the latest calibration values get propagated to each configuration, and was hoping that someone on LAVAG had experience with this type of calibration management. My current idea has several steps: Rework the main configuration file to be human readable. Store file paths to sub-files in the main file instead of storing the sub-file data. Load the sub-file data when the main file is loaded. Develop a set of default sub-files which contain basic configurations and calibration data. Set up the main file loading routine to pull from the default sub-files unless a unique sub-file is not specified. Store only the parameters that differ from the default values in the unique subfile. Load the default values first, then overwrite only the unique values. This would work similarly to the way that LabVIEW.ini works. If you do not specify a key, LabVIEW uses its internal default. This has two advantages: Allows calibration and other base configuration changes to easily propagate through to other configs. Allows the user to quickly identify configuration differences. Steps 4 and 5 are really the crux of making life easier, since they allow global changes to all configurations. One thing to note here is that these configurations are stored in an SVN repository to allow versioning and recovery if something breaks. So my questions to LAVAG are: Has anyone ever encountered a need to propagate configuration changes like this? How did you handle it? Does the proposal above seem feasible? What gotchas have I missed that will make my life miserable in the future? Thanks in advance everyone! Drew