mje

Somewhere in the web palette there's a pair of VIs that can swap between the cluster image format and a PNG string, you could potentially just do the disk I/O yourself. Do those work on RT?

I find examples like this scattered throughout the VI server hierarchy. Don't know if you'll get a 'why' answer, it just 'is'. Sorry, don't have an obvious recommendation for you. My assumption is things ended up like this as features were slowly tacked on without proper consideration for where they ought or could be in the hierarchy. Details like this give me the impression that the underlying implementation is not as clean as it could be...

Good suggestions both of you. I have a whole set of internal libraries I'm using for 2D picture elements in this application, so I'd rather not make the switch to .NET or 3D just yet. That said this may be the last time I use the native 2D picture routines for any serious work. I threw this together this morning as a proof: The performance is as expected, hideously slow when it comes time to flatten the result (do not try to render the raw op-code string). As a result it's a literal interpretation of the Wu algorithm as described at wikipedia since all the optimization in the world won't change how slow it is to render op-code based dots in LabVIEW. This is just a proof of concept, at this stage I'm happy enough to say it can be done and defer the implementation until later. Still needs color, line width, and ditching of the op-codes in favor of a raster buffer which should improve things by at least an order of magnitude. Example code is LV2013, public domain. Wu.zip

Sounds like a great idea. I've tried and failed miserably a few times to get my brain around git's way of doing things. I had best figure it out. Until then good luck!

I'm looking to do some line drawing in the picture controls which frankly have to be anti-aliased. Really basic stuff that can be entirely software based. Does anyone know if the routines LabVIEW uses to draw lines in the graph/chart controls are exposed and can be re-used in any way? I'm not against implementing something like the Wu algorithm myself, but clearly LabVIEW has already implemented something...

I'm not sure exactly what you're after, you want a millisecond time relative to what? Your VI calculates it from the beginning of the current day, is that what you're after? Essentially you need to define an epoch-- what it is you're measuring your millisecond time relative to if you want to be able to convert back and forth between the native LabVIEW time format. If you pull out the milliseconds elapsed since the beginning of the day, when you go back to the native type you need to add back in the absolute time you dropped when you shifted your epoch. Hint: the time type in LabVIEW is measured from the 0:00 UTC January 1 1904 epoch and is a 128 bit second based measurement. You can convert it to a DBL to obtain the number of seconds at a possible loss of precision and range, or cast it as a cluster of {I64, U64} numbers without the loss (reference). The signed integer is number of seconds since the epoch (signed to allow times prior to the epoch) and the unsigned integer is the positive fraction of a second. Edit: Added the wrong snippet, should be fixed now.

There are many things you'll find on at NI's website, which makes me think that at least some people there must be banging their heads running into these issues, so maybe there is hope. There's many ways to skin this one: I take the RTE distributed by NI, run the self-extracting EXE locally, then package up the result into my installer. At run-time I evaluate which (32 or 64 bit) to extract/execute and call the setup.exe with "/q /AcceptLicenses yes /r /disableNotificationCheck" (reference). I'll add my code for checking if the native version of the LV RTE is present: function IsLabVIEWMissing: Boolean;begin result := not RegKeyExists(HKLM, 'SOFTWARENational InstrumentsLabVIEW Run-Time13.0');end; Tests like this are evaluated in the Files and Run sections to determine if the appropriate item needs to be executed. Similar tests for .NET, MSVC.

My recommendation is to just ship everything. If you try to be too sneaky with the RTE it can cause you issues if another application installs that loads the same environment. What if you don't install the math libraries but another application needs it? Most installers only check for the registry key added by the core RTE. I don't know how "well" the NI built installers behave with a previously segmented environment, but I expect not well considering if they did their job people like us wouldn't be on this mess. If you try to outsmart the RTE, it will likely cause issues because it's just not that smart to begin with. I really do wish it was, because like you I've lost days to these issues.

Agreed, though it's not inherently secure, rather it offloads the security to how the user handles the key. I'd say it's the most secure way software could handle it, but an uneducated or lazy user could still result in no better security than plain text. Whole different subject indeed. Suffice it to say I would appreciate a "secure" data type where buffers are strictly managed and not copied at a whim. I shall not hold my breath...

InnoSetup is awesome. We have a corporate installer team that handles installers for all our commercial products and they use InstallShield. I'm grateful for what the installer team contributes and think they do a great job, but I don't have any positive recommendations regarding the use of InstallShield itself. For non-commercial projects which my group maintains full control of (internal software, beta-collaborations, R&D) we use Jack D's Deploy which uses InnoSetup under the hood. I haven't found anything I can't do by hacking up an InnoSetup script. Mixed mode 32/64 bit installers, doing install time checks (Pascal!) for third party libraries and installing if missing, it allows me to do exactly what I want. I definitely recommend InnoSetup, whether you use it directly or through a product like Deploy.

We abandoned the NI built installers with the 2011 release over similar issues, the 64-bit IDE was failing to package up the entire RTE even when asked. You're not alone.

Indeed, constantly opening the refnum would cause memory to increase, but there would be no way for your clone to close that refnum from the diagram you showed because the clone doesn't know what the refnum is. Note if your clone obtains a refnum to itself they are different refnums, both must be closed. "Static" refnums (those that originate from constants) do not need to be closed, but anything you get from an Open primitive must have a corresponding Close at some point. There are a few special cases too where refnums returned from property nodes also need to be explicitly closed-- these are usually documented but not always (the XML library for instance is particularly bad/inconsistent). My recommendation is to review your refnum usage, you seem to have a few of them floating around there. I give up. Editing forum posts is just plain broken. If this edit results in illegible html...

Your "Starting Clones_HeavyLeak.png" code opens a VI refnum but does not close it so it makes sense that memory would increase on each call. Does your "Starting Clones_SlowLeak.png" code do the same?

Hi Joe, Do you have a little bit of code that you can show the problem? I can't quite tell if you're running into some serious issues with LabVIEW or perhaps just aren't getting what you'd expect from your code. I've seen really strange corruption issues creep up before and also observed behavior with properties, but it's hard to tell what may be happening in your case based on what you've said. I'll also note those threads are dated a few years ago, though I've never worked with 2012, I've generally had none of these issues with the 2011 development environment. This statement however does set off alarms in my head as I've seen this behavior (first linked topic). My recommendation would be to take your top level VI that starts everything and do a full recompile (click the Run button while holding Shift + Ctrl). Sometimes these the observation that a VI is returning the wrong data is only a symptom of an issue high up the call stack: there's nothing wrong with the VI in question, rather something else is passing it bad data. Cheers, M

Though I have yet to re-write any of my VIs to use this, I think the new Get LV Class Default Value By Name VI does the trick. Qualified names of course, but there's a corresponding VI that returns those too now.

Yes. The coercion would be automatic, the only reason to explicitly do it would be if one wanted to get rid of the coercion dot.

I'd expect your implementation is about as good as you're going to get if you want to build your cache dynamically. The DVR/SEQ would have an block as well due to the refnum operations (no idea how efficient the locking mechanism for those are relative to VIs).

Just store it as LabVIEW Object (or any other parent). To keep things safe have your accessor methods act on the proper class: the read will use a To More Specific primitive prior to returning the object, and live with the coercion dot in the write (or use To More Generic Class). Doesn't matter if you're by value or by reference, same deal with the exception being you need to be aware of the implicit lock/unlock on the TMS operation.

Hah, yeah. I thought as much. It's just so easy with that picture's cursor property: I know it's scripting, but it definitely has worked in the RTE for the last few versions. It's one of those things I check when I build this application for the first time in a new RTE. Anyways yes, it'll have to be a combination of mouse events and the menu palette for this feature I suppose.

I wouldn't expect it to matter for reference types (and if it does I'd expect it's a bug) but may some form of recursion be biting you? I know you can definitely put a strict VI refnum in a class under normal circumstances, I've done so before.

I have a graph control which I'd like to provide some feedback to the user by changing the mouse cursor depending on context, does LabVIEW have a built in way of doing this for it's graph controls? I've done similar things for the picture controls (see below): Am I blind here or does this capability not exist for graphs? Note I'm not talking about the built in "graph cursors" which display x,y points and allow navigating on the various data coordinates, but rather the actual OS mouse cursor. I can bust out the Dialog & UI Cursor palette if need be, it just seems weird to use such a low level when other controls provide a nice wrapper.

A quick look at the html source shows me it's old-school HTML, not XHTML. That 'X' is very important as it implies the content would be valid XML in addition to HTML. The LabVIEW DOM functions operate on the XML DOM, be it XHTML or any other XML, and demand valid data structures. If you want to parse (non X) HTML you'll probably have to do search and replace string operations. Either that or work some sort of browser engine into your code which can interpret HTML and allow you to operate on the HTML (not XML) DOM.

Scratch that. I just had a build fail with a (120 second) timeout (after about an hour). Time to put the pings back to greater than build time and blindly build where no one has built before.

An ID in the sense you are using it is functionally equivalent to a refnum, assuming behind the scenes you'd be tracking refnum regardless of what you send along for the ride over the transport layer. An ID is a unique number which *your code* dereferences. A refnum is a unique number *LabVIEW* dereferences. In this case I'd save myself the trouble and not bother with the extra layer of indirection, it gets you nothing in return but does cost you development and run time.

If LabVIEW limits the string representation of EXT numbers you may be able to extract more digits by rounding to some precision, generating the first set of digits, then generating the second group based off the difference. Ugly for sure, but if that's the only way...