JamesMc86

Hi Marcin, The only reference I can find to specific image processing benchmarks online are in http://www.ni.com/white-paper/2957/en#toc5. Unfortunately I have no more details than on there. I do believe a lot of effort goes into the performance of the library for example the algorithms are multicore optimised. If there are specific benchmarks you need post it here and I'm sure we could whip something up. James

Thanks for the validation Mads, seems I was misinformed, will have to try it first next time!

I asked a similar question about the new conditional indexing in 2012 and that is the same, it will preallocate and then cut down the array which saves writing that code over and over!

Which mod us library are you using? Is it the free one off ni.com? From a quick look at the commands you need to be using the register accesses for the data. With the free mod us library I believe you should then be able to send the addresses as the manual suggests, some other implementations require an offset depending on the data you are reading. Generally 3 for read only registers (or variables as the manual calls thru) or 4 for read/write registers so the address for a read only register at address 1 appears as 40001. the addresses appear to be detailed in section 6. Hopefully this is a starting point to decipher some of the data you are seeing. Let me know what library your using and I may. E able to be a little more specific.

Hi Ak, I would encourage you to think about. I guess for specific reasons you have listed them. It will get you to build good modular code through encapsulation and the simulation part of HAL can be very useful. The other thing I would add is that no one thinks they need a safety net, but you can never know what the future brings and a HAL does give you more of a safety net. I would also suggest if you are new to OO it is possibly good that you don't need any fancy design patterns. It can be a good project for you to get comfortable with the basics of implementation before getting stuck into a more complex design. My final argument would just be if you have objects in your system, might as well use OO rather than classes. EDIT: I mean clusters. You can probably tell I am pretty keen on OO now! Regards, James

I have never tried out the adapters so I can't comment on them but the red X actually means disconnected I.e. I have seen this device before but can't now so I suspect nothing has worked through the adapters. I thought the adapters are normally only designed to work with specific classes of devices e.g. Mass storage, at the very least you would need some sort of local software to have it emulate a standard USB hub.

What exactly do you see in distributed systems manager? If you see the variables then they are still deployed (and should be, even after a reboot). The next thing to look for is errors. Selecting a variable in DSM should show a status bottom right of the screen. Also do you have a way of checking if the nodes in your code are generating errors?

The highest values we have for AI is 300V rms so it looks like it may be just short but for reference, for low channel count that is the 9225. In terms of your other question always feel free to get in touch with your local branch if you need advice.

DIAdem can do elements, you probably won't be able make it identical but you can do axis layouts to what you show in the report layouts

If I follow your question correctly, in your subVI if you select the value in the enum that you want as default and then right-click>>Data Operations>>Make Current Value Default this means when you call this as a subVI without wiring anything that is the value that it will use.

That is a downside but an executable is also no good for sharing code on a forum, that's just not what they are for. The trade off that you are making is that the code is precompiled making it much quicker to load, build and having all the compiler optimizations active. The single file makes them easy for distributing plug ins for plugin architectures as well.

Hi Austin, I've had a quick look and have a few bits of feedback, this is not necessarily exhuastive but the main bits I notice at a quick glance: Functionality: Your east and westbound red lights don't appear to light properly, this would need fixing for the functionality section. Style: The style is OK but there are a few areas with room for improvement where wires are going backwards a little. Run VI Analyzer on it to pick these out. There are no major issues though. Style: For your display FGV you don't have the command enum type defined and I find it a bit odd having two command inputs to this, though I see where you were going with it. I would also expect command to be a required input or display what the default is on the terminal name. Documentation: You have all the VI documentation filled out which is good but it would probably be good to add a little more on the block diagram. There is none at all in the top level VI. Those are the things that leap out at me that you may want to look at but I would say it is quite a good start. I don't know exactly how they come up with the exact scores but I would think with those changes it should be in with a shot! Bear in mind that the style is worth as much as the functionality and documentation isn't far behind, (15,15,10 split).

That is because they are pre-compiled therefore you will only be able to use them on the same processor architecture and OS. Assuming you end up with a built executable this will not matter as you will run on the same runtime engine.

Thats the sort of performance we could do with in this case! However I don't think these will run. These give us the ability to run unbuffered to the hard disk on Windows. On RT I tried this option earlier and it threw the fantastic generic file IO error (and in Windows you can now do this in the native API now) I checked with a few people on the file size set. With this we will request a file of that size to be reserved by the OS, but we still can't guarantee that the OS wont fragment the file still.

I believe using Set File Size from the File IO palette should ensure this (though the documentation does not shout it out as it does for the equivalent TDMS function)

What are the final requirements for this? You metioned that you have images coming in at up to 100Hz. Is this a continuous process? Or is there downtime where we can catch up? It appears that even the good writes take 20ms which will only allow you to achieve 50Hz, even if we can remove these spikes, is this acceptable to your application? My concern is that at 100Hz you have over 50MB/s to disk which I'm not sure is going to be achievable with a traditional HDD on an RT system. Alternatives would be whether an SSD drive would be faster or squeezing it down gigabit ethernet to a system which supports RAID. I think preallocating would be good if you were streaming multiple times to the same file but as you are constantly opening new files I suspect you won't see much benefit.

So I have just had a bit of a play. First off it appears there is no cache even on PXI RT. I have just tried this and disabling buffering throws an error. I still can't understand the periodic jitter you see but I suspect you may be pushing the boundries of the HD write speeds. I have just tried a similar set up on an PXI-8106RT and the fastest I see is 12ms for the 512kB files as you are writing, based on what you said we need to hit 10ms. Of course newer targets may be able to achieve more.

It is just listed as handles. You can also view them in task manager. Each handle is a OS object and you would not expect this to be anywhere out of the 1000s. I know files would represent an object, network sockets beyond that I am not sure but I do know it is likely to be a reference leak if it is a handle leak. There is quite a detailed document at http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx but I can't say I've tried tried these myself before. I think Daklu's question is a good place to start as this is a pretty large rate of handle loss.

I just had a check for you. There is a CAR number for the file name issue in the flexmotion library (96799) but it has not been fixed yet so I am not sure why this no longer causes issues. Maybe some of the internal changes to the EXE structure have changed to cope with this? Seems unlikely though, would have to do some testing.

Another couple of ideas to add: You can run the desktop execution trace toolkit on an exe (with VI server enabled), though I suspect the sort of issues this would see would be consistent with the IDE or EXE. I would use perfmon to monitor the memory and handles. File, network connection etc. reference leaks will tend to show an increase in handle count. Bar that I think breaking it down is the good first step. Knowing the rate of the leak and your main data paths can sometimes point to specific sections of code as well, but normally only when you have a few big data sets that you are moving around.

Can you still browse to the variables when you select the SV nodes? I presume it is the whole project that you are taking over as is. The link is contained within the project so it doesn't matter if you haven't done anything in MAX with that cRIO. It would be interesting to know whether the two errors could be linked.