ShaunR

Can you post an example that demonstrates the problem?

Same here. Watch this space.

Indeed. From the usage point of view it look on the face of it to be nice and easy to access from within the code and you certainly have created a sleek interface. I'm not sure how time consuming it would be to create 5 translations for 300-400 controls though. Also, what if (as in my case) the developer is not the translator?

That'll be the next problem You must be in an earlier timezone from me...lol.

The loop that the release queue comes after never terminates because the boolean is set False. Works for me. After 3 secs I get a flash of the boolean.

Sorry. I've just shown the label and named it "boolean"

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.