The updates to that module happen at around 7microseconds. Other digital modules that don't have individually addressable and directional pins update much faster, but that particular digital module is less expensive, flexible, and a bit slow. 7us is the speed you can accomplish if the FPGA updates the values with FPGA logic, or if the cpu updates a register on the FPGA map fast enough. I suspect that the layers of function calls and some value checking are what is adding the overhead you are seeing. You certainly know your way around LV, so feel free to drill down into the digital subVIs. Test each time you get to a new layer and you'll get a feel for where the overhead is. Please ask questions if something doesn't make sense or if you make some good discoveries.
You may also consider using the PWM I/O functions. I believe that will more easily produce the tones you want because it will be the FPGA doing the high speed switching.
I wanted to comment on one of the other posts.
Quote:
Originally Posted by daltore
Basically, there are just a lot of layers in the FRC control setup. LabView is an interpreted language running on firmware on the cRio itself. The firmware (an interpreter) reads the compiled LabView code and figures out what it wants the cRio to do. That interpretation takes time...
|
Some of the other things in the reply were essentially the same as Eric and I are saying, that it is SW layers adding overhead. But just to nip the interpreted thing in the bud, LV is a compiled language and has been for over twenty years. The LV diagram is turned into PPC instructions that are executed directly by the CPU. I believe the firmware you are referring to is the VxWorks OS, and it is not interpreted either. It is native code based on C/C++. In a LV app, there is no interpreting unless you write one.
You may have been thinking of the NXT execution system. I'll be happy to go into more details or answer any questions you may have.
Greg McKaskle