ensegre

Plotting over a flattened pixmap (rather than incrementally adding to the picture new plot data, that's the trick) can be fast, and has the same cost no matter the previous image content. Like this: I guess that periodically replotting the whole lot of curves would become too expensive even this way. In a case like this perhaps one should manipulate directly the pixmap, like erasing the pixels of the oldest curve first with an xor operation, and then overplotting the newest. Unfortunately the internals of the picture functions, for attempting something like that, are not well documented, IIRC. I think that, much time ago, I ran into some contribution which cleverly worked them out. Maybe some other member is able to fill in?

The trick is to get the Edit Position first, set Key Focus to false, get the (now updated) value and process it, set Key Focus to true again and then restore the previous Edit Position. For an application of mine I had to process arrows with and without modifiers, tabs and whatnot, sometimes jumping columns besides correcting the entered values, and allow only the input of [0-9] in some cells and text in others - you can go quite far in tweaking the standard table navigation behaviour if you invest time in implementing all cases.

I have somehow the impression that you're assuming that there should be some magic option of the LV plot widget as is, which saves from application design. What you show about hand drawing a template curve, and classifying traces, hints that there is more computation going on behind the scenes. The display in the plot window must be a somewhat sophisticated GUI, only giving the user a feeling of what data is been accumulated and how to interact with it, quite likely not doing the mistake of replotting the whole dataset for every new curve acquired (that would be expensive). The right question might be whether you can use the LV graph widget for what it gives, or rather the picture widget as Shaun suggested above (that would overplot directly to the pixmap, I guess, and be significantly faster), as a starting point for building such a GUI. The LV graph widget, optimized as it may be, is slow because it is complex: it handles autoscaling, abitrary number of curves, arbitrary plotting stiles, filling and whatnot, and this comes with a price. Someone may correct me, but I don't even think it can handle adding incrementally new curves, without replotting the whole bunch. If I would have to build something the like, I would store the data in memory appropriately and without connection to the graph; I would consider to update that display only periodically, fast enough to give the user a feeling of interactivity, and track user clicks on the graph area in order to replot the data with the right highlights, to give the user the impression s/he is playing with it.

If this helps...

I think you should part with the idea of regenerating a plot at every new event; storing vast data for later analysis is one thing, display for GUI feedback another. Instead of trying to plot 5000 curves at every iteration of the loop, you could try maintaining a different loop plotting, at lower rate, the most recent N, with N suitably large. Another approach I thought of, is using an intensity plot to display a 2D histogram. Grid the time-amplitude space in bins, and increment each bin every time a curve passes in it (you have to write the code for it, I don't know of a ready source); thus you get a plot similar to that of a scope with infinite persistence, brighter where traces overlap. Different loop and lower rate, ditto.

Not to mention The MB icons in the screenshot upward in this thread make me think that the OP was referring to the old (not good old) ni-modbus-1.2.1, still available here: http://www.ni.com/example/29756/en/ I have used the latter here and there for simple communication, and while I could make it work, I was not impressed by quality, and vaguely remember bugs and quirks.

The q&d NaN replacement in a duplicate signal is because Waveform Graph was brought into cause in the first place. For large datasets, and multiple graphs, the solution may be less performant; I would then switch to other solutions, like an XY Graph, where each plot can have its own x dataset.

Benoit preceded me.

this is a q&d way of doing it (2nd graph with NaNs). Does it qualify?

This is what I'd generally do, and end up doinf for things like confidence intervals. What do you mean exactly "that's not working"? Can we see code? You must be familiar btw with ain’t you?

shameless self: if linux is an option...

Oh, and Sorry, there is a problem The page you requested does not exist Error code: 2S100/6

Is the video still available? Shouldn't the blurb be corrected?

Style quite awful (stacked sequences, local variables, no modularization, and what - you open and close various files for rereading unchanged (?) data between each A/D and D/A operation?), so it's difficult, for me at least, to understand what you want to do. Anyhow, two suggestions which are a bit of a shot in the dark: Open, define and keep open the Daq tasks properly. Don't rely on the auto behavior of DAQmx Read and Write if performance is of any concern. Provided that opening delays are not of concern there, check for poor USB cables/flaky connectors/EM interference. I remember an occurrence I had where simply using shorter cables, wound a couple of turns over a ferrite core, solved random "resource unavailable" issues.

I have some minor comments on usability, from quick testing. I don't know if you're already interested in such detail. TopLevelDialog/SelList[] loops erroring, if the VI examined is closed and thus the ref becomes invalid, and ShowEventsFromCtl becomes topmost (i.e. even if there are other opened VIs, but they are not topmost). That should be trapped. TopLevelDialog/SelList[] list loops erroring, if the VI examined is password protected. Either that should be trapped and reported or the standard unlock dialog should be brought up. Show Event blinks the right place in the BD, but that may not be visible if scrolled away. An improvement would be to center the window on it, like Stop on error does.

I second Yair, and think that looking from the user point of view only, no registration for downloads promotes the LAVA spirit. The comparison coming to my mind is sourceforge. My perception as an user is "hey, I can get a lot of interesting stuff from here for free. And I can also give technical feedback, contribute, and even start my projects, but for that it's legitimate that they know who I am". They certainly have orders of magnitude larger technical staff to deal with server issues, though.

Looking on http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf (page 40), "because they say so"... If "why" means the rationale, maybe historical? UARTs with maximal buffers of 16K, and low bauds (not thinking of ethernet), so 16K was almost synonym of infinite time? Only speculating.

Uhm, maybe _IOC_TYPECHECK(v4l2_format) involves the length of some pointer buried within the v4l2_format structures, maybe it comes from elsewhere (/usr/include/asm-generic/ioctl.h #defines can be overridden). I meant, it's involved enough to see where it starts, for the rest I rely on the proficiency of v4l people.

Thanks for reinforcing Rolf. In the specific case I know that is a constant because: these numbers keep being the same on different platforms, on different instances of the application, in compiled C snippets as well as in LV CLN calls. No indication of pointers depending on relocation. tracking the macro definition through the involved .h's , it boils down to a constant, much likely for the reason Rolf says. Pedantically: _IOWR() is defined in /usr/include/asm-generic/ioctl.h as #define _IOWR(type,nr,size) _IOC(_IOC_READ|_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size))) _IOC() is #define _IOC(dir,type,nr,size) \ (((dir) << _IOC_DIRSHIFT) | \ ((type) << _IOC_TYPESHIFT) | \ ((nr) << _IOC_NRSHIFT) | \ ((size) << _IOC_SIZESHIFT)) _IOC_TYPECHECK is #define _IOC_TYPECHECK(t) (sizeof(t)) the various IOC_ constants #define _IOC_NRSHIFT 0 #define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS) #define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS) #define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS) #define _IOC_NRBITS 8 #define _IOC_TYPEBITS 8 and so on. (wasn't there the story that someone writes a lot of C so that I don't have to?) [show of hands, all this was for updating my https://lavag.org/files/file/232-lvvideo4linux/ which works, proof of the pudding. I resolved to tackle the typedef constants issue with a script in the lines of what I quoted above.]

I succeeded in adapting the sources to work both on 32bit and 64bit. Package available at the repository linked above.

I'd say it's a constant, whose value is computed by the macro, defined in turn in another .h and telescopically. That results in different values, depending on bitness and architecture. But whatever, my point was for using the ring instead of an enum with such odd values. Ah, not blaming anyone for wandering off... the discussion is instructive to me.

Indeed, and this is what I'm tentatively coming up with: My use case is that of passing to a certain CLN the value VIDIOC_S_FMT, which evaluates to 3234616837 with the 32bit library and to 3234878981 in the 64bit (at least in the 1.0.1-1 version of the library), as #defined in some obscure .h file, which I parse in order to generate the appropriate typedef. When I rebuild the typedef for the new platform, I need to care that the BD constant which represented my VIDIOC_S_FMT is updated to the correct item with the same label, in the new representation (as would happen if it was a changed enum). A different use case than the one you suggest above for combos. I would say fortunately not, because they are controls. Differently from ring constants, controls are true typedefs. Ok, I could have not-typedefd BD cluster constants which contain this type, and I should traverse all clusters, and, and, but let's not exaggerate.

hm, this is turning into a nice discussions about the relative merits and limitations of enums vs. rings. On which I agree all the way, but is not my original problem. That was, how to update "typedef" BD constants when their parent typedef is programmatically changed. IDE and prior to loading the involved VI set acceptable, at this point. Combo strings suffer of the same problem btw, as stressed by the KB linked above. Now, unless there is some magical Xnode contraption, I think I would explore some VI scripting way - like scan every VI of the hierarchy for typedefd constants, unlink them and relink them from their parents, resave the VI. Looks like it will be much easier than a bloated translation layer, which implies extra code for every appearance of any constant.

Kudoed that idea, and the duplicate one mentioned in the discussion, for what helps. So yes it turns that presenting the BD typedfd ring constant as typedef with a black ear is just a graphical mockery; on the BD, that object is treated as a non-typedefd, "Because type definitions identify only the data type". Only enums carry their legal range and labels as part of their data type. My use case is to interface with a C library, whose (many and sparse in value) #defines may change across versions, and certainly do across bitnesses. I already had in place a dynamic way to create all the typedef.ctls I needed; only, I realized that all was fine when the typedefs were used for subvi controls and indicators, but not for BD constants, which were static. Now I'm scratching my head about whether I want to turn my generated typedefs into enums, then write a translation layer to obtain the nonsequential values, or what. Changing all my BD constants into dummy controls with defined default value doesn't look very elegant to me...

Doh, by design: http://forums.ni.com/t5/LabVIEW/Possible-Bug-Ring-Constant-Typedef-not-updating/m-p/2400754 http://digital.ni.com/public.nsf/allkb/46CC27C828DB4205862570920062C125 However enums allow only sequential values... turns out that I'll have to revise what I was doing, which was happily using a lot of ring typedefs.