Phil Duncan

I think this is an excellent idea. Some thoughts... You want ALL shared code to go to the repository and all submitted code will be evaluated against the LAVAcr standards. I understand the reasons for evaluation, but as you mentioned the evaluation process is administered by volunteers. My point ? Some of the code submitted in response to questions is just a "quick & dirty" explanation of how to achieve a desired result and would probably not pass the LAVAcr review process. In these instances I would not wish to waste the code reviewers' time and hence would no submit the code to LAVAcr. Should we then only e-mail the quick and dirty code to the user and maybe provide a screen shot for the forum or is there a more appropriate process we should follow? Cheers & Beers :thumbup: & :beer:

Thanks Chris. I checked this out and I think I have convinced the client to update the card. It looks like we can use the afformentioned adaptors, provided the pin maping is as you suggest. Cheers & Beers :thumbup: & :beer:

Hi ann, welcome to LAVA. I have run into similar problems before and have read other threads about this as well. The first thing I noticed is that you were not closing the VISA reference after executing your code, this leaves an open reference to the COM port and may result in an error when you try to run your program next time as the VISA resource may still be considered "open" from the previous execution of your code. Some serial instruments have some intelligent handshaking codes to verify when a command has ben executed, others don't. I have found that if you can't determine when the instrument has executed a command, insert a short delay between writing and reading to/from the COM port. It's not elegant but it works 90% of the time. I have attached an image of a suggested solution to try. Without the instrument attached it is a bit difficult to test though. Cheers & Beers :thumbup: & :beer:

Hi Rayc welcome to LAVA. I have attached a sample VI that might give you some ideas. It is a simple way to display information that is triggered off the mouse enter and mouse leave event for the indicator in question. I tried using the tip strip property of the indicator but the value does no update while the tip strip is visible. For more advanced options, you may want to have a look at the examples for dynamic events that ship with LabVIEW. Hope this helps. Cheers & Beers :thumbup: & :beer: Download File:post-4848-1150864749.vi

Thanks for all your replies. The DAQCard-700 has 50 pin outs, the 6024E has 68 pinouts. Unfortunately the client has some existing hardware interfacing the 700. I am afraid that all time savings achieved by using the new card will be lost in re-designing the interface. I guess I have to wait and see if the client will go the updated hardware option as we suggested. Long term support will be a nightmare if I have to roll back the DAQ drivers every time the client wants to add features etc. I think the separate development PC is a good idea but I am not sure how this will pan out. Cheers & Beers :thumbup: :beer: Phil Duncan

Hi all, I have a client that requires support for a DAQCard-700 PCMCIA device. We are running LV 7.x and 8.x. I have read the forums and guides on ni.com regarding retro installation of traditional DAQ drivers for devices that are not supported in LV 7 onwards. This card requires NI DAQ 6.9.3 !! The good guides recommend uninstalling my current drivers and installing the older ones (6.9.3). I am a little reluctant to do this because I still have to support other clients with modern drivers. I am considering this roll back option for development of the application but I am concerned that in the future if the client wishes to modify their application or add features that I will have to go through the whole roll back mess again. They are very reluctant to update to a 6024E because the interfacing hardware is equally old but reliable. My question: Is there a "neat" way to support legacy devices requireing NI DAQ 6.9.3 (for example) and still maintain a current (up to date) installation of LV 8.x with associated drivers? Cheers & Beers Phil

Well here's a teaser for your troubles..

I agree. I was particularly impressed with the realistic space dogfighting. No more banking your spacecraft to turn etc.

LOX BBQ's will never take off in Aus. The whole point of a BBQ is to slow cook the meat so that you have plenty of time for PLENTY of :beer:

Thanks for the responses. The data log file refnum makes sense as the best choice now. I did a little investigation (3 mins worth) and the data log file refnum is the only one I found that requires/allows a type cast when created, much like a cluster or array container. Done and done! ... and done and done and done...

Hello fellow LVers. I have been reading a lot about GOOP and it's many implementations from llb's to dqGOOP and Endevo's GOOP wizard that incorporates inheritance. Before I embrace GOOP with gusto I want to understand it completely so that I can implement OOP techniques intelligently and appropriately. During my investigations I noticed that most GOOP techniques use a typedef enum control dropped into a data log file reference to form the class (object) reference. I am just wondering why use a datalog file ref? What makes it the preferred option over any other reference type? Beers and Cheers. Phil :beer:

It's not so different here. As an aeronautical engineer, we have to calculate lift in Newtons, altitude in feet, rate of descent in feet/min, take-off and landing distances in metres and use density in SLUGS!! :headbang: Confused Aussie in Aus!!