ShaunR

Well. Yes and no. It uses .NET so its a bit like saying a vi creates Word documents when, in fact, it is an automation interface to Microsoft Word and Word creates the document. No word, no document. No .NET, no messages.

Well. What can I say. It'd take me a week to figure out whats going on in that spaghetti. I would suggest thet you keep the diagram open while running and when it no longer responds, click the "Highlight Execution" button (the lightbulb). That will show you where it is currently executing. That will at least narrow it down.

Be even better if we could catch windows messages in the event structure!

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.