ShaunR

That's looking pretty slick You've also given me an idea for another use case for my little sqlite project

Yup. Dlls are a nasty business. I avoid them when I can.. I presume it is a dll written in C or C++? For *char (i.e name) you can use a "String" Type with the "C String Pointer" Format. Int will depend on how the dll was compiled (32 bit or 64 bit). An int compiled for an x32 will be I32 Integer. For 64 bit it might be I32 or I64 (it's up to whoever compiled it). Void is just an untyped pointer to something (could be a byte (U8), 2 bytes (int32), 4 byte (Int 64) a double (8 bytes) and so on). So you have to know the size of that something. If it is an integer, you need to know if it is 64 bit or a 32 bit. If it is a double (floating point) then you need to choose double (it will probably be be 8 bytes - I've never seen a 4 byte one in a C/C++ dll). Then choose "Pointer To Value" If you look at the function prototype, it will show you what the C calling format is for your function. By selecting the appropriate drop downs; replace "Int" with Int32 or Int64 (depending on what it was compiled with). So your Labview function prototype might look something like int32_t xiaSetAcquisitionValue(int32_t detChan, CStr Name, int32_t *Value); or if the value parameter is a floating point number then int32_xiaSetAcquisitionValue(int32_t detChan, CStr Name, double *Value); If Value parameter can be any type depending on the "Name" that you are setting, then you can use the "Adapt To Type" and define it in your labview code for each call by just wiring a U32, Dbl or whatever.

Somehow I figure you for the "cuddlier" type rather than cuter

I think you've been fed the hype intravenously. That is certainly the OOP mantra. But no evidence has ever been proffered to support this kind of statement (you have a link?). Sure. New thread? Ya think people will talk I would start off with explaining why typdefs (in labview) provide single point maintenance and expand into why OOP breaks in-built labview features and why many of the OOP solutions are to problems of it's own making Maybe I should bring my old signature back

This is "traditional" labview we are talking about. If you are suggesting to never use typdefs (because it creates dependencies) then I will take you to task on that. But I think "most" traditional labview programmers would use this method without all the complexity and overhead of conversions to/from variants.

Does that mean you get 3 salaries since you're obviously doing the work of 3 people

I think most people would have used a cluster (usually with a typedef) and just unbundled. That would also work for the OP

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.