Phil Duncan

Thanks for your replies. I have since re-structured the XControl and now it performs as I would like although there are still a few bugs. I will review your submissions in detail as I am sure they will shed some light. Cheers & Beers (particularly cold ones given the current heatwave in Adelaide )

Greetings All, I have been working on a relatively simple XControl for a project we have atm. Right now it is a simple single ended Bar graph with some alert features. The user can specify the upper and lower limits of the range, a warning threshold, an alarm threshold and a warning time. This is version 0.1 of the final XControl which will have a lot more functionality including double ended (bi-directional fill) display options. Operation: If the data value is in the warning range, the BG colour of the bar chart turns orange If the data value is in the alarm range, the BG colour of the bar chart turns red along with the BG colour of the numeric indicator under the graph. If the data value is in the warning range for more than the warning time limit (default = 2sec), the BG colour of the numeric indicator turns red. After setting up all the panel resize and scaling issues I have finally implemented some of the operating logic. Because the XControl involves some timing functionality (essentially a stopwatch), I decided to use VI Server to call a dynamic (stopwatch) VI. I tested the XControl and it works exactly as expected, until..... I added a second bar graph XControl to my tester app "PLAYTEST Bar Chart.vi" only to find that each XControl is messing with the same stopwatch VI. I have tried all combinations of re-entrancy settings and read plenty of posts about re-entrant VI and data spaces etc, frankly I am more confused now than I was before. What I need is to have each instance of the XControl talk to it's own stopwatch VI. Is this possible? Cheers & Beers, PS Attached code is in LV 2009. Dynamic Bar Chart.zip

Name: Multistate Boolean LED Indicator Submitter: Phil Duncan Submitted: 04 Jul 2009 Category: X-Controls LabVIEW Version: 8.5 Version: 1.0.0 License Type: BSD (Most common) Make this available on the VI Package Network?: Undecided Multistate Boolean LED Indicator V1.0.0 Copyright © 2008, Phillip Duncan All rights reserved. Author: Phillip Duncan --see readme file for contact information Background: I have had many people ask for an LED type indicator for their project. During development, I often get asked to have this Boolean (ie 2 state) indicator display one of (more than 2) colours. Whilst that in itself is not difficult, more often than not I am then asked to make the Boolean LED flash as well to highlight certain states. For example a single LED will often need to indicate the following states: OFF (green, red or grey) ON (Green, red or grey) Flashing (green, red, any other colour) I have had so much demand for this functionality, that I decided to develop this XControl and share it with the LabVIEW Community. Many thanks must go to Aristos Queue and his inspiring "Scrolling LED XControl" example. Description: This XControl is a typical Boolean LED indicator that can also be configured to flash between two user defined colours. The flashing interval can also be modified. When not flashing, the XControl behaves as a normal Boolean LED. This XControl is an indicator only is is not intended to be used as a control. Dependancies: There are no OpenG dependencies for this XCtonrol Known Issues: If you save this code for version 8.0/8.2, you may encounter issues trying to assign multiple properties in one property node. This is a bug in LabVIEW 8.0/8.2 Change Log: 1.0.0 Initial release Click here to download this file

Hi all, I have recently installed Perforce on our server (P42008.2) and Perforce Client (P4V/NTX86/2008.2/188141) on our developers PCs. I then configured LV SCC, telling it to use Perforce Command Line and told LV where to find the server etc. I then moved an existing LV Project to my workspace folder and opend it in LV, right clicked on the top level VI and selected "Add to Source Control...". A window popped up showing me all the dependencies of the top level VI and clicking OK displayed a window telling me that each file had been added to the depot as " - opened for add". I click OK and LV does not indicate the files are in SCC. I then switch to the P4V client window and submit the changelist (adding the VI and it's dependants to Perforce). I repeat this process for the .lvproj file and voila!, the project is in Perforce. Back in LV however there is no indication the project has been added to SCC (no check in/check out glyphs on project icons) and when I right click on the project, I only have the option to "Add to Source Control..." again????. Of course trying to add the project to SCC again thows up erros about existing files etc. What am I doing wrong?? PS I am using LV 8.5.1, all PCs are win XP Cheers & Beers :thumbup: :beer:

There is an alternative (quick and dirty) way to achieve this without delving into OOP. You could customise a control (boolean, dial etc), set the disabled property to 1 to prevent anything happening when the user clicks on it then simply change the control's position on the screen according to your needs. I have included a simple VI to demonstrate what I mean. I used a ring control so that you can even rotate the car to head in the direction it is traveling !! This may be too simple for what you need, but it certainly is quick to implement. Cheers & Beers :thumbup: :beer:

QUOTE Thanks folks for your advice, very useful as always. I have not locked into a hardware solution yet but I think that I will try the DAQmx read properties to continuously acquire and maintain 16 circular buffers and trigger in software. It won't be pretty but I think it is the best approach. Thanks once again for the great advice. Cheers & Beers :thumbup: :beer:

Hi all, I have a tricky DAQmx problem, at least I think it's tricky (it is getting rather late). I need to acquire analog (voltage) data from 16 channels. The start trigger for the acquisition needs to be either an analog rising edge or falling edge on ANY of the 16 channels. I am currently using a simulated M series PCI 6250 to try this out but I can't seem to set up the triggering. It seems that a DAQmx task can only have one single trigger. I could try to set up 16 tasks, each with their own trigger then try to acquire data on all tasks if any task triggers but this seems ludicrous. Has anyone dealt with this issue before? Oh and to really complicate things, the acquisition duration is around 30ms, so around 20kS/s/channel minimum and the input voltage range is 0V-14V (I know the 6250 is only +/- 10V I am just using it for prototyping a concept). So if anyone can recommend suitable DAQ hardware I am willing to listen, the only option I have found that allows >10V is an SCXI 1104. Cheers & Beers :thumbup: :beer:

I must say that Pink Floyd and Dire Straits (Brothers in Arms = Best Album EVER produced) are fine choices but for long sessions on the computer(s) I always cue up several 2 hour mixes of A State Of Trance, hosted by Armin Van Buuren (voted 2007 worlds number 1 DJ). There's something to be said about my mind state when coding and preferred music genre...trance!

QUOTE (crelf @ Aug 29 2008, 03:01 AM) GRRRRRRRRRR I can't believe I missed that in my checks. Thanks guys, sorry for wasting your time. All is good again. Looks like I'll meet that timeline after all Cheers & Beers :thumbup: :beer:

QUOTE (crelf @ Aug 29 2008, 12:25 AM) Why yes! I get a very helpful explanation. The full text reads like this: "An error occurred loading VI "Real Inverse Matrix (LU).vi". LabVIEW load error code 21: An external subroutine required for execution could not be found. :headbang: I get the same message for 4 other missing vi's that are all from the linear algebra palette. After clicking "OK" for each error message, I get a nice summary of all the missing VI's. There is no mention of unregistered or missing DLL's. This is not the same as DAQ files that must be loaded on the target machine separately, all the troublesome VI's are included in the VI settings tab of the App Builder, so LV knows they are required for the exe. As far as I know these files call the lvanlys.dll, but it is not included in the build and I cannot force it into the build. The lvanlys.dll was put in c:\NI\Shared\LabVIEW Run-Time\7.1 directory on the target PC after installation of the executable (via installer files). QUOTE (crelf @ Aug 29 2008, 12:25 AM) You're, of course, not right at the end of the project, right? You've subscribed to the "build early, build often" mantra, right? So this isn't a major timeline issue yet, right? Yes, sort of, and no. Cheers

Hi all, I have been happily developing an application in LV 7.1 (not my preferred version) that needs to be compiled into an executable. I am familiar with the app builder and the executable runs fine on the development machine. It fails to run on another PC that does not have LV installed. I built an installer to ensure the LV71 run-time engine was included. When I run the app I get "An error occured loading VI 'Real Inverse Matrix (LU).vi'. LabVIEW load error code 21.... I get the same message for a bunch of other linear algebra functions that are in the program. I am aware of many other "code 21" posts but they all seem to be related to missing items like DAQ, IMAQ etc. I have checked here and verified that there are no (listed) special requirements for linear algebra functions like the ones I am using. I have tried copying lvanlys.dll, adding the missing VI's as dynamic VI's and support files. No good. I have noted that all the "missing" VI's are in fact included in the VI Settings tab of the app builder as shown below. Is there a magic post that explains a very obvious solution, is there a trick that I have missed or is there some obscure reference to a work around for including linear algebra functions? Your help is, as always, very much appreciated. Cheers & Beers :thumbup: :beer:

QUOTE (Justin Goeres @ Jul 12 2008, 07:43 AM) That result is to be expected. You have not taken into account the quantum nature of chocolate chips in dough. There is a real, though very small, probability that ALL the chips could end up in one loaf, even if they were all mixed into the dough for the other loaf. You should be lucky you didn't find an elephant in there as well!!

Thanks for the responses. I agree the 4472 is a better solution for the client unfortunately they are using an SCXI system that has been there for years and they are hesitant to pay for a replacement system, particularly when the 1531 module is the second SCXI module they have tried to use (initially they were trying to use a 1520 which does not incorporate IEPE excitation). My only concern is that the local distributor for PCB informed that these sensors only measure a change in applied force as Dan mentioned. He stated they would not measure a static load. So even if we went with the 4472 option and applied DC coupling we may not be any better off. Which leads me back to another aspect of the original problem. The acquired signal levels are very low and applying the calibration factors from the OEM does not help. I am waiting to hear from a senior technical guru from PCB about the sensor, just to confirm we are using it correctly. Thanks again for your help Cheers & Beers :thumbup: :beer:

Hi all, I am having difficulty getting meaningful data from a PCB 208C model dynamic force sensor. I am trying to acquire the maximum force applied during a dynamic event. This device is an ICP device, so we are using an SCXI 1531 module to excite the sensor. I have some issues with the data values we are seeing and I am not sure of the source of the problem. We have calibration data from the OEM which states the sensor returns about 10.33mV per pound-force (lbf). My first problem is that this sensor is a DYNAMIC force sensor that only measures CHANGES in applied force. If you apply a static load, you get a zero reading. This leads me to believe the output from the sensor is actually in V/lbf/sec. I have integrated the input signal then applied the calibration value to determine the maximum force applied during the dynamic event in lbf. The results are REALLY low. The range of the sensor (from the calibration data) is 0-5V (0-500lbf approx). I have applied a known force on the sensor using a force gauge and examined the signal in MAX test panels and simple DAQ assisstant Vi's. Applying a force of around 150lbf we see values of 0.3V max which equates to around 30lbf according to the cal data. Not coming from an electronics background, I am unsure whether there are issues with AC coupling for this particular sensor or if there is anything particularly unusual about this combination of sensor and SCXI 1531 module. If anyone has used this type of sensor successfully, I would appreciate any advice. Cheers & Beers :thumbup: :beer: