ShaunR

I only see a huge CPU jump when not decimating, so its more like 333 points (or 333 redraws/sec). If you think 20% is bad, wait until you've tried the vision stuff

If you had followed the link on the page that Asbo gave you you would have found

Nahh. Both demonstrate the same point, but yours is neater

lol. Only 3 mins difference this time That'll teach me to watch TV whilst posting

If you are asking what I think you are asking then you have missed the fact that shift registers are "growable". You can select a shift register and "drag" out more nodes.

I'd choose an in-door court But then I plan for failure I don't think there are many companies that would expect you to produce code without the tools to do it. Which had me wondering why the OP is being put in this position in the first place. Or indeed, why the question has even arisen. It's like asking a chauffeur to drive you to the ball with no car But it's not a case of "stealing" or won't invest. It's a case of not investing until you absolutely have too (different budgets, different invoice dates, cash flow). And unfortunately, its the bean counters' that run companies now-a-days and an accountant doesn't give 2 hoots if you have to make an aeroplane with a fork and a piece of bamboo, Just as long as you do and his figures add up at the end of it.

This can backfire quite spectacularly. My experience has been that a companies( generally) won't spend any money unless they really, really have to. If there is a legitimate way to use labview without paying (either long-term or short term) then it is usually argued by the bean counters' that it is not a necessity to buy now and once you have used the goodwill, then the evaluation...they will consider it again (you only make it easier for them to delay). I've always found it far better to argue that the project cannot proceed at all and is at risk unless a licence is bought, and, although an evaluation is available, it has already been used during the feasibility phase. It can put you in an uncomfortable position where the NI rep is pressing you for an order, but the accounts dept are dragging their feet (you are after all only one of many requirements for monies) and you are piggy in the middle.

Indeed. But our topologies (and philosophies) are entirely different. Ahhh. I see what your getting at now. Yes. they will be different because you have to redraw more data, more of the control and more often.. It's well known that redraws are expensive (put a control over your graph or make them all twice as large and see what happens). And it is not just Labview. The major difference is in what and how much has to be updated. If you (for example) turn off the scaling (visibility) and keep the data-window the same size, you will see that the CPU use drops a little when it is scrolling. Presumably this is because it is no longer has to redraw the entire control; only the data window (just guessing). You are much better off updating a graphical display in "chunks" so you need to refresh less often. After all, its only to give the user something to look at whilst drinking coffee Humans can only process so much graphical data (and only so much data can be represented due to pixel size) so there is no need to show every data point of a 10,000 point graph. It's meaningless- It just looks like noise! But I bet you want the user to be able to zoom in and out eh?

Probably. I don't use un-named queues since I have a single VI that wraps the queue primitives and ensures there are no resource leaks (and I don't like all the wires going everywhere ) Are you still getting differences in the graphs? When I run your example, I see no difference in CPU usage between scrolling and not (~5-10%) although I haven't looked at all the "Questions"

I think so. Yes the bottom loop is free-running. Put an indicator on the front panel wired to the difference between 2 "GetTickCount" VIs. You will see that it is pretty much "0". You are in fact putting all the data onto 1 un-named queue. So, every 3 ms you are adding 4 lots of data, but you don't know which order the bottom de-queues execute in or, indeed, which order they were originally placed (but that's another issue). Your time-out is is exactly the same (3 ms) so if there are 4 pieces of data on the queue, then everything is fine. However this is unlikely since the producer and consumer are not synchronised. If a timeout occurs; you still increment your counter so, due to jitter, sometimes you are reading data, and sometimes you are just timing out.....but.... you still only display the data (and add it to the history) in case 19. And although you will read it next time around, you don't know on which graph it will be. You have a race condition between data arriving and timing out. Does that make sense?

Not quite.. Here are the licensing options. They are quite clear.

Haven't had time to go into all the above. But have noticed that your bottom loop (dequeue) is free running (0ms between iterations). I get a very stuttery update (just ran it straight out of the box). Changing the time-out (deleting the local and hard-wiring) to, say 100ms, and everything is happy and the dequeue loop updates at 3ms. I imagine there's a shed-load of some time-outs going on which is causing you to miss updates (not sure of the mechanism at the moment)..

Datatypes in SQLite Version 3 If you give me a a specific example of what you mean. Maybe I can help more (but read the link first)

I've never found an easy way to do do this programmatically within LV. I use one of two techniques. 1. Create a function in the DLL called Get_Ver which will return the the dll version and LV version used (I don't use this much any more) 2. When you build the dll, put the LV version in the description section. It won't help you for the current DLL. But you shouldn't have a problem in the future.

Sin? Noooo. But this is an interesting one. It will fit on 1 screen. Just do a "Clean Up Diagram" with shorter variable names and you're pretty much there. But that's not the interesting bit There is a large number of operations that are identical. Identical operations easily be encapsulated into sub-vis. This not only shrinks your diagram, but also segments it into easy to digest chunks of code. Consider this piece of code.... this is replicated no less that 6 times. I would be tempted to do something like this : It achieves several benedits. 1. it is more compact 2. It is easier to identify repeated functions.. 3. It reduces wiring errors 4. It gives more control (you can, for example make it a "Subroutine" for faster execution) 5. You can re-use it . There are many more places within this piece of code where it could benefit from sub-vis. The net result would be that it will probably fit on 1/4 of a screen and be a lot easier to read/maintain. There are also a few areas that would benefit from "For Loops" too.

Because classes aren't very friendly? I would imagine it's because a class is an entity and you access that entities data through methods and properties by exposing them to a greater or lesser extent (I think of it like a box with buttons and indicators on it). As such your interface boundary is the "class" so you are in fact saying that the Method B should be able to poke a couple of wires behind the buttons and indicators when all Method B can do is press the buttons and read the indicators. But then again. I usually over-simplify things there's probably a more technical explanation.

You can use "REPLACE" which will "INSERT" if it doesn't exist or, "DELETE" the old record and then "INSERT" if it does.

Queues are good for this sort of thing. they give you inherent FIFO sequencing. You can use the "Event" structure to place the controls' refnum on the queue then replicate the changes by emptying the queue.

Indeed. You can. When you edit the pallet menus, there is an option (right click on the VI) to "Place Vi Contents". I you create a VI and set this value, the contents of the VI will be placed in the diagram instead of the icon. lol. JGCode is a faster typist than I

I don't think they are any more painful than, say, queues or notifiers. My only gripe is that there aren't more built-in ones.(but that's something different).

Sweet. I'll update it for the next release.

An elegant solution . That's going in my snippets draw.

What's wrong with using "File>>Save For Previous Version"?

OK. Definitive answer. Change the "SQLite Read Blob.vi" moveblock call to "LabVIEW" (note the case...it matters!) instead of "labview.exe" or "lvrt" Let me know if it fixes your issue and I'll add it to the API library.