ensegre

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.

I think I've run into a nasty little bug, or perhaps I fail to grasp the higher reason for this. Seen on LV 2014 and 15 linux. Can someone confirm, so I escalate to NI support? Let's say I have a Text Ring (or Menu Ring) typedef, and use it as a constant somewhere on a BD, like in the attached. At some point I modify the typedef in any way, like changing the text, editing the numeric values... and Apply Changes. The change is reflected in the control and in the indicator bound to that typedef, but not into the constant. Why? They are eventually, only if the constant is turned into a control and back. ConstantControlIndicator.vi TextRingTypedef.ctl

And, "slight trick" is just passing "clone.vi:590003" to Open VI reference, options 0, instead of a path. Puzzled about what's the case, too...

What I would usually do is to retrieve (or strip) the selected path on exit, and feed it to a FGV, or to the property Browse Options/Start Path of the control connected to the input, or something along this lines. This way I can handle multiple initial paths for different controls in my application. Yes you could convert the express VI to standard VI and modify it, but I wouldn't bother to tamper with it.