Leaderboard

Run the executable as Administrator in Win7 to allow it to modify files in the "Program Files" folder. Create a shortcut to the executable and select properties. Select the "Advanced" button. Check the "Run as administrator" box.

I had this problem with Win7 but fixed it by unlocking the folder in the project "Build Specifications". Under "Source File Settings", select your destination folder below the "Program Files" folder and set the "File and Folder Attributes" to "[x] Unlock".

I recommend checking out the examples to see what can be done and to look at Vision Assistant. You're going to need to get a feel for what each routine does. Try out the routines and get some working code going. People here are very helpful when those asking for help have put in effort.

In general, Darren and I add comments to our diagrams when, during a buddy session, we actually have to explain what's going on to the other. That's our standard measure for when a comment is needed. If the buddy session proceeds without the other person getting lost as we walk through, then the code and the API documentation (i.e. the Context Help) likely suffices as it is. My instinct in this case would be to put a Diagram Disable structure down and put the other version that I had tried in the Disabled frame -- then I don't have to describe what I tried, people can look at it. Now, that is only true when the other version of the code is all prims or vi.lib VIs, things that don't cause my source code to have additional dependencies when distributing it. As much as possible, I would still prefer to include the graphical "here's what I tried" and avoid a text description of it. It is both more accurate to say "I tried this" and if someone else says, "But that other way really should, by rights, be faster..." they can benchmark it themselves easily and/or spot any errors I had in my implementation. And if the compiler takes advances, it's easy to flip in the other code.Now, having said all of that, I do tend to include "proof of correctness" comments with complex algorithms, along the lines of "This loop works because earlier in this VI we already guaranteed that there are no duplicates in the array". This is especially true when I'm relying on a less-than-obvious fact of one of the upstream functions. For example, I recently wrote a VI with the comment "This works because the Controls[ ] property of a Front Panel refnum guarantees that the controls are returned in tab order." Most people analyzing my code for correctness wouldn't know that fact, even if it was properly documented (it will be in LV 2012), so it was worthy, IMHO, of a comment.

Hi Hamid- I believe we (National Instruments) have already contacted you offline but we would like to help clarify some of the original statements you posted that were provided to you by your Agilent sales rep. 1. bandwidth: The NI PXIe-1075 is capable of 4 GB/s of system bandwidth, not 2.5 GB/s. 2. timing performance: The phase noise of the PXIe-1075 TCXO, from which the 10 and 100 MHz backplane clocks are derived, is better than the one on the Agilent M9018A by 30 dB (1000x), when free running. 3. cooling: In order to achieve 42W of cooling for a single slot, the M9018A requires allowance of a 15 deg C temp rise for PXI module components as well as either 1U of rack space below chassis or that two air inlet modules be placed in two of the peripheral slots. The NI PXIe-1075 can cool 38.25W in all slots requiring the standard 10 deg C temp rise in module components and 1U of rack space above the chassis. We want to keep this conversation objective and unbiased, so I am purposely not going to add any additional value statements or propositions. We simply felt that some of the original statements that were provided to you were either inaccurate or incomplete. I hope that this information is helpful to you and the participants on this thread. Regards, David Nosbusch NI Product Manager - PXI Chassis