ShaunR

Use the "Strings[]" propety instead of the value. The value is the numeric index.

You need to give the value a name.

Looks like your doing it the hard way

I think the UDC2500 uses modbus. You will need a modbus RTU driver. I don't know if Honeywell supply one with their product for Labview, you might have to write it yourself using this http://hpsweb.honeyw...44/51522566.pdf Or if your really lucky, someone else may have written one you could use (try the instrument driver network).

oooh. You should never ship products developed with beta environments. Beta stuff is for larking around with, seeing what new features will be available and seeing if they have fixed the other bugs from previous version....Oh, and help them debug too I personally wont develop customer software on anything unless it has been out in the field at least 6-12 months. Then there should be a few patches around to get rid of the show-stoppers. And don't forget, there is no such thing as support for Beta software. If you find a show-stopper, it won't get fixed until it is released, and that could be a couple of months.

I've had worse

I got stuck after I answered "No" to "Do you Purchase Resealable bags" on the first question since it seems to assume that everybody does.

Indeed. But the motherboard is a comapct PCI! You will note all the conversion chips and all the busses showing PIC 33/66. In fact only Ethernet to Ethernt goes through unadulterated. Howerver, you are going through the 6300ESB (PCIx to PCI controller) to get to the disk . Also, the SATA disk interface is is SATA 150 (equates to about 180MB/s) or IDE (100-133MB/s). Lots of things there to reduce your throughput.

Your absolute level is the mean of the previous (say 100) datapoints.

The same thing but in Arabic I can see this thread is going to get very silly, very fast...lol.

Good excuse to get an SSD too

This is the "clean" version of my contribution to this thread.

We had a similar problem with large images. Our solution was to view at different resolutions (i.e decimate) and load from disk only the sections of the image the user could see as he zoomed in rather than try to keep the whole image in memory. So in the whole picture we had reduced resolution but as he/she zoomed in it would reload at finer and finer granularity. You could do the same thing with a graph after all, when viewing the whole timeseries of lets say 1 week, can a user really visually resolve 1us? As he changes his axis, you could reload that section of data and at some point (where you decide) you no longer decimate but load raw data.

If you can define the trough as a rising, falling edge or it drops below a certain level, you can get the analogue card to trigger aquisition. Take a look at Acq&Graph Voltage-Int Clk-Analog Start w Hyst.vi in the examples and see if it will suffice.

I you go to the Tools>>Profile>>Show Bufffer Allocations. It should indicate where theallocations are.

Indeed. In fact you can have the best of both worlds (an "Inteliigent Global Daemon" if you like). If you make the Intelligent Global/Action Engine re-entrant and "share clone instances". You can have a boolean control that causes it either to continue running or exit immediately but it only has one dataspace. It means the first time you call it you set it false (runs as a daemon cos its connected to the conditional terminal) and you can still call it in other areas with the boolean set to "True" to retrieve/set the data. Used sparingly its very useful. Hmmm. That sort of solves the OPs problem really.

Whats the model number? Some older PC motherboards used a PCIe to PCI bridge effectively giving you the slots but not the bandwidth. The figure you are seeing reeks of PCI. PICe x1 cards are relatively rare in comparison to x8 and x16. I'm surprised you have them!

I think we are both arguing the same point As I said. The self configuring vi (and yes I can do the above in both DAQ and IMAQ as well as VISA) keeps the refs LOCAL to the vi. If it (the one that was launched) goes idle then yes the refs disappear and I wouldn't have it any other way. However, if the launching vi goes idle then the vi remains running unless the AutoDispose was set to false (as in the OPs case) in which case it no longer remains running and halts when the calling vi exists and bang goes your refs. If there were such a thing it would be a "Daemon" design pattern. For the OPs case, this self configuring daemon seems a bit awkward since he has no way to access the refs because he can't call it as a sub vi. That can easily be overcome with a global (oooh dare I say it ) or simply reading the ref control with a property node. However the general intent is NOT to make the refs global but encapsulate complexity to make an autonomous, fire-and-forget sub system.

Not if you set autodispose to true when you load the vi dynaimically.. Then the launched vi is responsible for closing its own refnum so the IMAQ refs remain until you close the launched vi. Perhaps I should have started with the IMAQ example instead of the VISA. I only chose visa because it was the first pallet item I came accross (visa autidispose is the first thing I set when installing LV by the way). As I pointed out, this technique keeps the ref local to the vi. If you want to access it outside the vi then you have to transfer it using a queue or global. If you need to do this then its not for you and the normal functional global is more appropriate.

Really? So I can't do this then

Ahh. IC. Been a long weekend I use self initialising vis for exactly this (usually, VISA and IMAQ). Not a million miles away from a functional global, but it keeps the reference local to the vi using it and is released when the vi is closed. something like this....

Set autodispose ref to true and don't close the ref in the calling vi. http://zone.ni.com/reference/en-XX/help/371361E-01/lvprop/vi_run_vi/

Aha. Sounds like you've reached the PCI bandwidth limitation, which is about 133MB/s max and about 110MB/s sustained. Not a lot you can do about that except change the motherboard for one that supports PCIe. PCI = 133MB/s Max. PCIe x1= 250MB/s Max. PCIe x4 = 1GB/s Max. PCIe x8 = 2GB/s Max. PCIe x16 = 4GB/s Max.

I'm a bit ambivelent about this article. I thought a "duct-tape programmer" was basically an un methodical script kiddy type. But he describes any programmer that applies KISS. After all if you have 2 weeks to write some code that puts a "widget" in a "doodah", why spend 2 weeks writing code to interface to other code (that you have still to write) that puts a "widget" in a "doodah". That seems to be the gist of the article rather than lauding seat-of-yer pants programming. From experience. there are (simplistcly) 4 phases to software projects. Design, Implemention, Fire-fighting and Delivery. KISS programmers do a lot less of the fire-fighting because they have less to go wrong.

Most modern adapters allow teaming with multiple ports (so you could team your servers adapters) http://www.intel.com...b/cs-009747.htm The old way used to be (under windows) creating bridged connections. Well, I say old way, you still can, but its more CPU intensive than allowing the adapters to handle the throuput. There is an overhead involved, but it is simple to implement and scalable. Sounds to me like you want 10GbE