ensegre
-
Posts
565 -
Joined
-
Last visited
-
Days Won
25
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by ensegre
-
I'm trying to use LVTM to debug an issue I have with, probably, stale references to asynchronous dynamically launched VIs. To stress test the problem, I open LVTM, open my project, launch what I have to launch, and then I uncleanly choose File/Close all (this project) while the whole contraption is running. LVTM shows me then this attached unreactive almost empty tree, with an entry surviving from the aborted project. If I double-click it, I get the error dialog. How can I help to debug LTVM (and my issue too?)
-
If I put such a threshold I see no memory events at all. Is you trace dependent on some particular data already present in your SV? Otherwise, it may be that the issue is solved in LV2017. Edit: Ok, with more data in the string I see this (a different sequence of memory operations in fact): But does this indicate a leak? I note the free of 4 bytes, which maybe you squelched with the threshold.
-
I don't know if I'm looking at the same as you, and I haven't investigated either, but I don't see leaks. LV17 32bit Win (where else do you have SV?) 10. I suppose allocation and deallocation sizes might depend on the variable content too, don't they? My trace has many more events, are you somehow filtering them? I don't fully understand your throttling of the second loop based on timeout of an occurrence, but there you know better, maybe it has to do with your architecture at large. Untitled Project 1.lvproj.det
-
thx. And agree with the very limited value of piecewise parsing just for checking. Btw, I see, you don't keep in sync github, forum and CR entry page. Never mind... Am I the only freak of this toolbox?
-
This is what I'd propose (cluster output). Backsaved for LV2015. mupGetLastError.vi Construct.vi Get_Last_Error.vi Now it occurs to me that only the first parsing error in a (multi) expression is reported; I could think at cases where I would like to see all errors in long expressions at once (when not ambiguous), but I think this is not contemplated in muparser. For example, I don't think you can merge different expressions parsed separately into a single muparser instance.
-
wow that was fast. I'll evaluate tomorrow how it fits in my current project. I agree that syntax errors can result only where expressions are defined and hence there may little reason for an a posteriori VI. Though, muparser allows decoupling it so it may be an argument in favor of it, but no need of overdoing. Something I could suggest is to group all the outputs of GetLastError in a cluster for compactness. I was also considering to include these as attributes of the muExpr class (ref), but I realized that your choice was to generate an empty class in case of error during construct, so that wouldn't apply.
-
Still about: No big deal, they are all very simple. The full message from mupGetErrorMsg() is already more informative, beyond that I can't imagine. See my go at it: While designing an interface which should highlight syntax errors in typed formulas, I realize that I miss a VI returning directly the strings of mupGetExpr() and mupGetErrorToken() together with the number mupGetErrorPos() [when applicable], instead of tediously parsing them from the full error message. Do you envision adding it to the toolbox? I may have a go at getting them from the encapsulated form, it later.
-
More out of curiosity than of hope: has anybody any idea why SVs are almost unsupported on linux? By almost I mean that controls and indicators cannot be bound to shared variables, and that shared variables cannot be programmatically created and looked up. I know that SVs hosted on windows can be accessed in linux LV using datasocket nodes, but that is all it gets. And it has been said that datasocket is despicable. What are the missing pieces that make SV windows-only? I didn't find much in the canonical places, so I posted a dumb zero-kudos attracting idea.
-
Dataflow.The small loop runs only after the big acquisition loop ends. You probably have no choice but to communicate the avi file reference and the writing status from one to the other via local variables. Or a channel wire perhaps.
-
Basic LV programming question. One way is with event frames. You should only open the AVI file when the boolean changes from false to true and close it when it reverts to false.
-
http://zone.ni.com/reference/en-XX/help/370281AD-01/imaqvision/imaq_avi2_create/ http://zone.ni.com/reference/en-XX/help/370281AD-01/imaqvision/imaq_avi2_get_codec_names/
-
I don't see a producer-consumer in your VI. That is e.g. two loops, enqueueing and dequeueing image references, or something equivalent. You create an AVI file at start because your program does so, you might want to do it rather only after the button is pressed. And I would handle that with an event structure and a shift register propagating the file reference from one iteration to the next. Maybe you'd want to check some LV learning resource first?
-
A producer-consumer architecture, with a queue of images to be saved by the consumer loop, is the first thing you should really try. Alternatively and asynchronously grabbing one image from each loop for either viewing or saving, like you do, wont bring you far. Also, rendering the preview image might be resource intensive and compete with saving, you may want to display only one every N images. Finally, AVI could involve compression codecs, which can also be computationally demanding; to maintain a given frame rate you might have to stream uncompressed images, or to choose a less demanding codec, to reduce the image size.
-
you mean "String ranges: A range of a..c includes all strings beginning with a or b, but not c." which is known and stated? I read time ago a discussion about its rationale, but I don't remember where.
-
Different packages have different names. For instance Matlab has log and log10, LV formula and mathscript has ln, lnp1, log10 and log2. Imho you shouldn't change. You're releasing a package which is essentially muparser, and can even work happily with the unpatched muparser, so users could expect a high compatibility with it. Besides you're already at version 1.0. You're going to irk your user basis...
-
Say the mean. RMS would give you an estimate of the standard deviation of your measurement.
-
Yes I wasn't diligent at all, I just sketched it to make the point.
-
How often you write new elements versus how often you have to read the whole array may also skew the preference given to one scheme. For example, if you write often a single element, just replacing it in place at (i mod N) may be efficient, whereas the readout which involves an array copy may be left with a more expensive solution. This is my go at it, not double checked, may be bugged.
-
Yes, to be fair I also have to admit that I used the GrabbeX in a setup with a single analog camera. An old setup to which I don't have access anymore for further checks. But these kind of converters are cheap so the risk in trying out a few may be low.
-
I've had good experiences (in the past, who uses TV cameras nowadays anyway?) with this analog->USB converter (link to a random eshop, no recommenadation). You then see the camera as IMAQdx like any vanilla webcam.
-
hm, no, I haven't yet had to upgrade any installation with vision to 2017.
-
I have a fresh 2017 on windows with vision and both VIs are in. Are you sure it is not an installation problem?
-
interesting idea. With some modifications like firing only the first time the FP is Standard or Maximized it should do what the OP is asking, and work for clones too. I presume that the cost of dropping it in every BD is minimal and could automated with scripting. Going a step further, such a drop-in could even hold the opening of the FP till it receives a notification in return, that the cosmetic job has been done by the actor which handled it.
-
Maybe not the smartest or more efficient answer. I would think at this: I'd run it periodically and generate a notification for every one of the newly open FPs. Names are identificative as long as no two VI can be in memory with the same name. Now there is the problem of clones, as I was asking here. One suggestion given in the thread points to the fact that the naming scheme of clones is known, only their number a priori is not.
-
Appreciated, thanks.
