Traditional NI-DAQ Compatibility VIs

[Paul_C.]

Hi Tom,

In regards to the first error -200428, have you tried including the AI buffer read vi as a dynamic VI when you build the executable as suggested by Travis in an earlier post to this thread.  Let me know if this doesn't eliminate the problem.

In regards to the card being "slow", could you describe what you mean by slow performance?  Are you not able to sample at the full rates?  If you are referring to the loop rates you are seeing in LabVIEW, this might be due to other system issues such as the operating system, CPU speed, other programs running, etc.  The DAQ card will sample at the rate you specify but may be slow due to the fact that your DAQmx read or AI read functions aren't grabbing the data from the buffer at a fast rate (ie your loop rate in LabVIEW).   Another consideration might be the bus speed.  The PCI bus is a shared bus.  This means that if you are using several PCI cards at the same time they will share the bandwith of the PCI bus (133MB/s max). 

The -10401 error is due to the fact that this vi is used with Traditional NI DAQ and isn't supported by the 6251 which uses the NI DAQmx driver.  If you would like to do a simple counter operation with the 6251 using DAQmx vi's you can use the DAQ assistant or use low level DAQmx vi's to accomplish the same thing.  The DAQ assistant will essentially create a simple counter task and execute it.  The lower level DAQmx vi's allow a little more functionality and can be seen in our example programs.  By going to Help » Find Examples, you can look at various counter examples.  If you doing simple event counting, I would take a look at the example called Count Digital Events.vi (This can be found under Hardware Input and Output » DAQmx » Counter Measurements » Count Digital Events).

I hope this helps,
Paul C.

[Tom_@_RTC]

hello,

i will once again try to resolve this issue the way you and others have stated.

When i say the card is slow im getting the little hour glass nxt to my mouse when my card is data acquisitioning, i do however have a pci-6040E and a pci -6251 but they are never used simultaneously unless NI drivers do it anyway?!

Any help with this would be very appreciated as timing is a critical issue with this piece of software!

Cheers

Tom

[Tom_@_RTC]

I have made some video samples of the workings of the program to show what i mean by fast and slow:

on each video study the backlog time (bottom right) and the general time it takes to complete a cycle when the same data is applied using a function generator. Even tho they are both jerky (due to the recording session) it is obvious that the speeds are very different. As far as i can tell when using the DAQmx stuff it all works fine so what are the compat VI's doing and why only with the 6251 and not on the 6221 or 6220?

The Videos:

Slow:

Link: http://s152.photobucket.com/albums/s179/tomhorsfall/?action=view&current=slowdaq.flv

Fast:

Link: http://s152.photobucket.com/albums/s179/tomhorsfall/?action=view&current=fast.flv

Any help here would be great!

Message Edited by Tom @ RTC on 11-28-2007 02:20 AM

[Tom_@_RTC]

after a serious amount of messing about i have found the source of the problem........ LABVIEW 8.5! i have rolled back to 8.2 and supprise supprise it runs far better! I am going to try to roll back as far as i can and see if the performance improves more as the VI's i know were designed for 7.1 and 7 so i guess the closer i move towards them the better chance im going to have of a working system. But am still getting problems building it so still stuck there!
Thanx Tom

[Paul_C.]

Hi Tom,

It looks like the slow behavior you're describing is the update rate of the graph.  If you're updating the graph in a loop, have you tried using tick counters to count how many millisecond ticks your loop is iterating at?  This would help you verify the actual update rates of the graphs in LabVIEW 8.2 and 8.5 to verify your results.  It would also help you determine how you might improve these loops rates.  I've included a picture of a simple example of what I'm describing. 



I hope this helps,
Paul C.


Message Edited by Paul C. on 11-28-2007 12:11 PM

[Tom_@_RTC]

Hi Paul,

I have implemented the design that you gave me (above this post) on all of the versions of labview that i have tried. I have the following results:

Labview 8.5:

Average Loop Time: 70ms

Min Loop Time: 67ms

Max Loop Time: 120ms

Backlog: 1 second increase per 1 actual second

Labview 8.2:

Average Loop Time: 40ms

Min Loop Time: 39ms

Max Loop Time: 42ms

Backlog: 0.25 second increase per 1 actual second

Labview 7.1:

Average Loop Time: 25ms

Min Loop Time: 23ms

Max Loop Time: 27ms

Backlog: N/A, Didnt go slow enough to enter

These results are backing up what i said before in regards to the further i roll back the softwarer to write it the quicker the program is running!

I have also took a screen dump taken from the 8.5 distrubuted exe showing the error that i am getting, also it shows that the loop times are dramatically reduced, reduced enough to allow the system to work well enough if it will work in distrubuted mode! The image is below:

I really recommend that you download the compatibility files and try to drive a m series card with the compatibility VI's mixed with the traditional VI's. Once you have a working model in dev mode try to build it and see if you are getting any of the same sort of errors as me.

Hope this helps you

Tom

[Paul_C.]

Hi Tom,

I have a few questions and a suggestion that might be able to resolve some of the performance and linking problems.  The compatibility vi's (version 1.3) were written specifically for labVIEW 7.0 and 7.1.  Did you install these or copy the install locations to LabVIEW 8.2 and 8.5 Folder locations.  I believe the the two compatibility vi .lib files are placed in the <labVIEW 7.0 or 7.1 directory>\vi.lib\daq folder.  If you copied this daq folder to LabVIEW 8.2 and 8.5, I would highly suggest mass compiling this folder.  This can be done by going to Tools » Advanced » Mass Compile and navigating to the vi.lib\daq folder.  This might also increase some of the performance problems that you are seeing.  If you haven't copied these folders to the newer versions of labVIEW, I would suggest giving it a try.  This will also require that Traditional DAQ folders be installed on all the versions of LabVIEW.  Traditional DAQ only installs to the latest version of LabVIEW found on the computer during the time of the install.  There is a great article, found here, that talks about what folders you need to copy to gain traditional daq on multiple version of LabVIEW.  Once you have fully moved the folders to the newer version of labVIEW (if you copy the vi.lib\daq folder where the compatibility vi's were installed, they will be copied too) you will need to mass compile all of the folders that you changed (see the article linked above).  I would suggest trying this out and letting me know if you are still having the difficulty.

Regards,
Paul C.

[Tom_@_RTC]

hello paul,

The link that is within that doesnt seem to go anywhere 😞 i keep getting the std ie error.

i have done the mass compiling on the VI's but have not made sure i have been installing the traditional DAQ properly, if you could re submit that link again i can make sure that my system complies with the methods stated in that.

Despite this i have installed trad daq to my current version of labview and then put the compat vi's on and then mass compiled with it making no difference to the system.

This is a real brain buster! If you can repost that link ill see if i can progress from that

Cheers Tom

[Paul_C.]

Hi Tom,

Sorry about that.  Here is the correct link.  Let me know if it doesn't fix the problem.

Regards,
Paul C.

[Tom_@_RTC]

hello paul,

have tried this method before, it was the only way i could make the program i made work backwards onto the 7.1 version on Labview. Unfortunately this hasnt fixed the issue with the crashing while in the executeable mode. I have now got contacts within NI UK support team that are trouling through the code to find the source of a proiblem that even they are seeing as puzzling! It is looking like i am going to have to visit the NI team at their HQ to resolve this problem unless we hit a solution before christmas. If we cannot and i find the solution at NI with their engineers i will come back on here and post the solution and advise the team at NI UK to submit a page to the NI website about it as i think this is a very serious issue!
Cheers Tom