Phil Duncan

Sure, but there are relatively inexpensive 50 <-> 68 pin interfaces, and I'm pretty sure they map between devices - check out the documentation...

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

I'm not sure if I remember correctly, but I think that we didn't even have to change any of the wiring - I think the pinouts of the 700 (or was it a 1200?) mapped the same as the 6024E (with respect to the lines we were using - a handful of AI, DIO and some sync).

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

I'd do anything for a Tooheys Old right now...

Well here's a teaser for your troubles..

...and you're right - the new series is IMHO the best sci-fi series ever made. Yes, I know that's a big claim, but jpdrolet's right - it's serious, realistic and a great drama. In fact, we don't have cable in our apartment, and I actually get off my fat arse and go to the gym just to watch it Can't say much about number six though - I'm more of a (new) Starbuck fan myself...

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

Mmmmm - I like my sausages crispy, but not vaporized...

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.

The enum dropped into the datalog file ref gives us a really easy way of creating our own reference types.

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.

Please have a schooey or two for me (I know you'll comply )

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:

:laugh: you win!

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!!