JamesMc86

Hmm not sure exactly the reasoning for this but I would probably suggest probably reducing what you are using shared variables for and maybe look at TCP or network streams for command elements. A couple of considerations would be that the rate at which the variable engine can run is going to depend on the RIO. If your progra is using most of the CPU that will impact the performance of the engine. Also ensure your shared variables are sequenced, they each have to wait for access to the engine, it is a shared resource. Hope it gives a few things to look at. Cheers, James (null)

Commonly this would require you breaking your transfer down into chunks. You can then easily time each chunk as you would benchmark any VI (check the example finder) and knowing the size get to the bytes/second This chunking is going to happen in the tpc stack anyway so don't think it would add much overhead. Not aware of a way to time it whilst in the TCP write function. Cheers, James (null)

Don't think you'll have any luck with GPS. I am not certain but modules outside of data acquisition on cDAQ is very rare. There are modules designed For reading from accelerometers but again not with anything built in. What you could do is get the module development kit and put a standard gps unit powered from the backplane but then run a serial cable out the front. (null)

Hi Monti, The biggest barrier for most people to the modbus IO server is that you have to have the DSC module. But if you do have it the it makes modbus much simpler and you get the features such as alarming. The best thing I'd suggest is give it a go. If you don't have it already download a trial of DSC and follow some of the examples. Cheers, James

Hi All, Here in the UK we have just completed our annual NIDays conference where we were lucky enough to get the first public preview of something R&D have been working on. There is an app for iPad and Android tablets to allow you to monitor shared variables and web services on a configurable graphical display. This is currently in internal beta but you can see the preview by going to the National Instruments channel on IET.tv and looking for the future technologies in LabVIEW video.

Hi, I am not too sure about this but I think you will have a hard time getting this to work. LabVIEW RT has some quite specific hardware requirements on CPU, Network chipset etc . There is a list available on NI.com but I think virtual is likely to not be possible. Cheers, James

Hi Pat, I am no expert on this topic but I would expect that at the best this will be very hard and at worst impossible. First you need an XPe box with a USB slave interface (I don't think you can use the standard USB ports for this) and then you need to figure out the software side. I would be suprised if XPe has the hooks for this. Take this with a pinch of salt as I am not familiar with these topics just my 2p. The reason I post is to suggest that if your XPe box has the serial port then can you just provide it with a USB-232 converter on the socket. They are pretty cheap and will be much easier to program with the simple serial VISA VIs. Cheers, James Mc

Hey Guys, I have just been trying this out and I think it is working correctly if a little strangely. Windows names my monitors 1 and 2 and specifies one as my main display. Therefore putting in 1 or 2 to the property node will move my screen to either 1 or 2. Putting in 0 will move it to whichever display is my main display as set in windows e.g. this could be either 1 or 2. Try switching your primary display from monitor 1 to monitor 2 and you will probably see what I mean. Cheers, Mac

Have you considered web services with the new UI builder? Check out ni.com/uibuilder. I used to find that web services still needed quite some work around them but for me for basic display of data and control this works really nicely and means that your client needs nothing other than a browser with silverlight. Other than that I tend to go with basic TCP to transfer a lot of data and have a loop to act as the server that will wait on a connection externally and act accordingly when the client is present. Cheers, James Mac

Hi mje, LabVIEW is large address aware but that is only a benefit on 64 bit OS. On a 32 bit OS LabVIEW is limited to 2GB which can be increased to 3GB with an flag in the boot.ini file for the OS. Large address aware means if you run 32 bit LabVIEW on a 64 bit OS then it can access 4GB. A way that I have tried to control allocations on large data sets in the past is using data value references in LabVIEW. I was building large 2D maps for robotics but without knowing what size I needed (and also not always wanting square arrays) I built a 2D array of references to 2D arrays. What this meant is that each element had an address to the reference and then an address within that array but this allowed me to allocate parts of the array as and when I needed then and so maintain a bit more control over my memory. I posted the idea at the time at http://decibel.ni.com/content/people/JamesMcN/blog/2010/02/23/using-referencing-to-make-weird-shaped-grids which talks in a bit more detail. Cheers, Mac

Hey Dvido, I would try verifying the FPGA code seperately. I think the issue probably lies in the host VI. The looping structure is doing a lot and running the FPGA code each time that I think may be causing undesired behaviour. Try a host first which is just a signal generator passing data into the FIFO and benchmark it to make sure its keeping up. The other think to do is then benchmark the FPGA code. Put in some code to measure the loop rate and see what its achieving. If its too low then try benchmarking just the FIFO code and make sure it is reading fast enough, if not you could add another FIFO so you can perform some reads in parallel. Finally if it is your host code that is the problem then try simplifiying it. Off the top of my head you can read only part of the TDMS file using the offset and length inputs on the top of the read so you don't have to load the whole file in. You could use single files again, open and close out of the loop and open a set length on each iteration. Then increment the offset with the iteration counter. Will be interested to hear how it goes. Regards, Mac

Hi Onno, As the others have said a VI doesn't have to copy data into a subVI so if you have written your subVI to be inplace and not make copies then your job is already done! The inplace subVIs do something slightly different. It means the subVI is their symbolically for you but the code from the subVI is placed directly into the calling VI. It means that what little overhead is required in calling subVIs is eliminated (at the cost of some features such as debugging) so it shouldn't impact your memory copies. Cheers, Mac