Steen Schmidt

I will contact both of you to understand your concerns a bit more, since these toolkits (IO-Link for LabVIEW and TestStand) were developed exactly to accommodate the scenarios you describe. I can clarify a couple of things here as well: - Our runtime licenses are always perpetual, never a subscription that could expire. - For development licenses we offer both subscription (to get going for less) and perpetual (if you know you want to use it for a long time). - We do offer discounts on license bundles. So if someone has "hundreds of systems", they could use that option. - The software in question currently has more than 3,000 hours of development time behind it, with ongoing improvements. I assure you, no matter when you begin it will be a long time before you have something that is close to what you could buy today. And at that point you wouldn't consider giving it away for free 🙂. This toolkit parses the entire IODD XML standard, which is huge. It is not quite the same as picking the 2% you need today, and discovering that the next device you want to connect uses a different part of the standard...

Oh yes, that's a side effect of VIPM not making sure all dependencies are in order during the installation process. You want to either 1) uninstall and then re-install Expression Parser after its dependencies are in place (making sure mass compile is enabled in VIPM), or 2) manually mass compile the 'C:\Program Files (x86)\National Instruments\LabVIEW 2015\vi.lib\GPower\ExprParser' folder, whichever you prefer. All something VIPM should have done for you. The reason is that since you have updated a dependency (VI Register) after you installed Expression Parser it makes LabVIEW need to compile the Expression Tester when you launch that. For most LabVIEW code compiling on load is merely an annoyance that takes an extra few seconds, but for Expression Parser the matter is different. It's very complex code, which takes around 5 minutes to load an uncompiled Expression Tester for instance. The entire Expression Parser VI package takes around half an hour to build (so it's good only I have to do that). We made some improvements to the code architecture from the last version to this newest one, which improved VIP installation speed from 15 to 4 minutes. Still much too long for comfort. I have a much faster installing version here, but that one takes a 10% runtime performance hit which I'd like to get back before we release it.

You need to upgrade the VI Register toolset to v2016.0.0.31. VIPM should have told you this (since that is a dependency of Expression Parser), but VIPM has been broken for a long while on many details. You can get VI Register v2016.0.0.31 either through VIPM (it's published on the LabVIEW Tools Network) or from our website here: http://www.gpower.as/images/downloads/viregister/gpower_lib_viregister-2016.0.0.31.vipc Cheers, Steen

We have had such a toolset for a couple of years: http://www.gpower.as/downloads/expression-parser-toolset I have worked for almost 15 years writing math software for HP calculators, so I'm also keen on RPN ;-) It's not trivial to do a fully functional toolset like Expression Parser. Probably close to 1000 hours have gone into making it. From our website: Evaluate mathematical expressions, given as text strings, into numeric values: Build and change your math expressions at runtime. More than 260 math functions and constants supported. Very high performance. Supports any number of variables of any name. Supports VI Registers. Reports overflow if that occurs during evaluation. Supports all 14 numeric data types that LabVIEW offers, including complex evaluation. Offers special expression control like conditionals, piecewise defined functions, pulse trains, and defining your own custom periodic functions. Supported on desktop and real-time. Cheers, Steen

We investigated doing a non-LabVIEW UI for a recent project, due to alle the reasons Shaun lists, but LabVIEW web service support was simply too lacking (crippled web server and non-existent security). So, lot's of good reasons to do it, just not really possible in a comfortable way.

Thanks, but having N control P's, one on top of each control T, was what I'd like to avoid. I would much prefer a single control P that resized and moved in place over each control T whenever it was needed. The reasons for this: 1) Being able to drop just a single "Drop Sink" (I call the control P that) control anywhere on the FP is simpler than meticuously placing N of them over each control T (and leaving enough border of the underlying control T to keep its Mouse Over/Mouse Leave events actionable). 2) The hidden control Ps won't scale and move with the FP, unless you jump through all sorts of other hoops (you have to remember to also set those to scale/bind to splitter, and they have a different size than the underlying control). If they could be placed just in time, one control P would suffice and it would always be placed just right.

No no, that's perfectly fine. I may come of as too complaintive. At other times I'm a fierce defendant of LabVIEW :-) It might be a question of circumstances for me - I enjoy programming LabVIEW, so if I have the time to do it I don't mind challenging workarounds. If I'm short on time I hate I have to do them. And also, things might get better in the future. So don't put too much weight on my complaining, my bark is much worse than my bite :-) Yes, exactly the workaround I want to implement. But it's not so simple. I don't want the invisible path control (let's call this Control P) to be over my target control (let's call this control T) permanently, as I want control T to behave completely normal, except when I drag something onto it. That is, upon dragging something from the explorer onto the VI FP, and ultimately onto control T, only then do I want control P to place itself over control T to receive the drop (and whisk itself off to the side again after it has passed on the dropped item via Value Change). There are two problems with this: 1) Once I drag something onto the FP all normal control event firing stops. I would have hoped Mouse Enter or Mouse Down would fire on control T, but they don't. So I have no way of detecting when that cursor is over control T. I can't even detect such a drag entering the VI Pane, so I couldn't even poll the cursor by looking at the mouse position with Input Device Control. 2) If I succeed in detecting that drag, and move control P in place, if I then want to abort the drag (by pressing ESC on the keyboard, or by dragging outside control T again and letting go of the mouse button), I have no events firing in this case either. I would have hoped Mouse Leave would fire on control P, but it doesn't. So, I'm contemplating how I can discover that drag from explorer has started, and how I can discover if it is aborted again.

I'm interested as well, I think we've come to the end regarding gifs anyway, haven't we? But for future searchability we could start a new thread...

Wow, this is frightening to look at from the outside: All I wanted was for LabVIEW to play my animated gif correctly, a feature it's supposed to have built in. That didn't work with my gif (nor Michael's it seems), and no sensible error message comes out of LabVIEW. And now you guys are discussing embedding web browsers in ActiveX containers, and programming a gif decoder and playback feature manually, the latter even as an XControl. And all that with a straight face. We're so used to LabVIEW falling short and us solving simple shortcomings with days of programming, that we can't see the joke here. Over the last 24 hours I've come across two other simple things LabVIEW should be able to do in 10 seconds, but each will end up taking 5-10 hours of programming to get done: 1) Being able to drop a file from the explorer onto a control and get that event in the event structure, and 2) Enabling any control and even the front panel to drag the entire window (as you would be able to do with the title bar). Every small step is really a huge leap with this tool...

Not like that. This requirement is: 1. Illustrate busy state on the window. 2. When the window is not busy, the busy indicator must be visible but subdued (to familiarize users with the location of the busy indicator). Just like in VIPM for instance: One simple way to do that was with a toggle-button that has a static subdued image in False state, and a spinner gif in True state. Then activating "busy" is simply programmatically setting the button to True. It's not so the user can push that button.

Probably won't get added to LabVIEW: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-drag-and-drop-support-for-OS-files-on-any-control/idi-p/1073586

Ok, not going to happen. I try to use http://ezgif.com/maker, which is a great site for making and editing animated images, but LabVIEW just gives me this on the created files:

Yes, I want to do some loaders/spinners. I wanted the gif on a button to easily switch between inactive (a static subdued image) and active (the animated gif) states. I started on the route to populate either a ring or a 1D array with the images, and then make a brat VI to automate animation of it. Then I thought better of it; "this is LabVIEW again forcing me to jump through hoops and spend numerous hours on something that should just be a drop-in". I simply won't do any of these work arounds to get a freaking animated gif to roll. But LabVIEW isn't alone here, animated gif support is always riddled with exceptions in browsers and the like. Animated PNGs are even worse for wear in this regard. LabVIEW probably just have an upper limit as to how many frames it will allow a gif to execute per second. Below that rate it'll play at full speed. I'll investigate that assertion and get back shortly.

Just ran into this today. Wanted to use the attached animated gif, but it runs really slow on a FP (as state image on a button actually). Oh well, just one of those things. I bet one of those images from 1985 will work just fine. You know, black/white 16x16 px, 4 frames, 1 second in-between frames, no transparency... EDIT: I did try one of those gif speedup services (ezgif.com), and the new gif animates much faster, except in LabVIEW where it continues to crawl along. It must be an issue of LabVIEW throttling resources to run the gif. I can see how such a gif could easily bog down my multi-GHz 8-core CPU. I'm glad those gifs are kept in check, wouldn't want them to animate at anywhere near intended speed... Sarcasm might occur.

Yes at runtime. But dynamic dispatch isn't a phenomenon at edit time, only the type resolving (which doesn't have to force load of all VIs in the class). So my question remains; what is the reason behind classes having to load all their member VIs in the editor? Since classes are basically a type, it is probably to avoid edit racing like with typedefs (two people simultaneously editing two members, afterwards both edits need to update the same class lib resulting in a non-resolvable conflict).