hooovahh

Crosspost with more discussion.

Difficulties with scaling? Non scale-able? Less efficient development? More work in maintaining? More Error Prone? I get the issue of the language, but when you mentioned 'unmaintainable' I knew what you were saying so maybe my opinion isn't as important as someone who didn't immediately understand what you were talking about.

Sorry I couldn't hear you over the sound of my ZOOOOOOM! Okay maybe zoom wasn't my number 1 request, but it likely was the number one request by over all. Maybe XNodes would be my most requested features. VIMs gets 80% there.

I did this time round...I mean VIMs am I right?...still I'm lucky enough that my project development time was a year, full well knowing SP1 will be out before the deliverable is required, but that still is a decent amount of risk running a new version with so few miles on the tires.

Wish I would have known that earlier, could have filed a couple hundred CARs by now. When LabVIEW is stable I'd say it crashes a couple times a week, but it isn't a big concern because the fix is generally to start it up again. I also think variant to data could help invoke crashes too by converting things to things it shouldn't and then acting on those things. I just tried a few things I know used to crash LabVIEW when messing with registering for events but couldn't get it to occur so maybe that one was fixed. It's not a bug its a feature. One I'll admit I wouldn't use, but still.

So I have some VIs, and they call some subVIs. The dependencies have been replaced with a different but similar API. Instead of keeping both APIs I'm ripping the bandaid and getting rid of the old API moving forward. The old API has been used in several places and so now opening VIs that called them brings up a dialog of searching for the missing dependency. I can manually go in and do quickdrop replacements, but there called quite a few places and I'd rather do it with scripting. So what I'd like to do is open all VI references in a folder. Find all subVIs in that VI. Look at the path, or name or some identifying mark of the missing subVI. If it matches the old API, do a scripting replace on the new one with maybe some small adjustments like creating constants where before there wasn't an option. I'm running into an issue pretty early. I can open the VIs reference, and then get all references to subVIs. But since they are missing, the VI path and VI name for this reference is blank. So how can I know some identifying piece of information from the subVI that isn't loaded? One option is I see when you have context help open is you can see the expected VI path. But I couldn't find this property. Any suggestions? Thanks. EDIT: I see Missing VI Path, Missing Paths, and Dependencies >> Missing Dependency Paths, properties on the SubVI but these are always blank for some reason. Double Edit: I'm an idiot, the property node generated errors early on in my testing, and wasn't working right. Please disregard.

View File Hooovahh Array VIMs Here is the Hooovahh Array VIMs. This initial release contains 14 VIMs for manipulating array data, which are intended to replace OpenG functionality, but with the added benefit of data type propagation, and increased performance using newer array manipulation techniques. In later versions other Array manipulation functions were added moving all the OpenG stuff to their own palette. Most of the OpenG functions are unchanged, but a few use the newer conditional and concatenating tunnels. And a few functions have added performance based on other inputs. For instance the Delete Array Elements can operate in a more efficient way if the input indexes are already sorted. The Filter 1D array can also be more efficient if the input is known to not contain any duplicates. Because these packages contain VIMs, they require LabVIEW 2017 or newer. Having these functions be VIMs mean all functions work with various array data types. Included functions are: Conditional Auto-Indexing Tunnel Delete Elements from (1D or 2D) Array Filter 1D Array Index (1D or 2D) Array, Scalar, Row, Column Remove Duplicates from 1D Array Reorder (1D or 2D) Array Reverse 1D Array Slice 1D Array Sort (1D or 2D) Array Convert 1D to 2D Convert 2D to 1D Find Subarray Force Array Min/Max Size Foreign Key Sort Submitter hooovahh Submitted 10/11/2017 Category *Uncertified* LabVIEW Version 2018 License Type BSD (Most common)  

Same as crossrulz. But the one brought to my attention recently scares me, and that is not being able to build an executable in some situations, when using VIMs. Since I'm in the middle of a major overhaul of VIMs in our reuse library any given application will likely use 10s of VIMs, in 100s of instances. And debugging when one VIM prevents a build from happening would be a major pain.

Oh that's a good one and one I have used in the past. I had found that in some versions of LabVIEW, some methods of doing functions were more efficient than others. And so I would have the VI on start read what version of LabVIEW it was running in, and then do things differently based on if it was in 2015 versus 2016. Of course there are other issues in that this needs to be saved in the oldest version supported, and that would generally mean not using some new features that might be more efficient. But my point is I would have found LabVIEW version useful in the past.

I was stating how I would do it now. You speak as if there is an alternative, of which I'm not aware of one. Also I'd prefer a first call state, rather than a thread swap to the UI every time I call the subVI. But I do have something that I might use this for. Is VI top level? My actors can run independently of any central messenger structure, so that each can be unit tested and debuged on their own. During the initialization state of the state machine within each actor I will detect if the VI is the top level, and if so it will behave slightly differently. This information is kept in the private data of the actor in the forum of a cluster in a shift register. They detect this by looking at the call chain, not a property as you mentioned but even this I heard can take enough systems resources that calling it over and over is less ideal than just calling it once on starting that actor. Other things I check I can see changing at run time like if the actor is in a subpanel I may behave differently, or if the VI has its window showing.

Thanks for making this clear. I know you mentioned conditional disable in the title but for some reason I didn't see it like that (us LabVIEW people are quite visual). I think I could see code like this. It could make things more reusable, but honestly I would just read this as a property node on first call into the VI the keep it in a shift feedback node all other times the VI is called. It isn't like reentrancy can change on a VI after entering run mode anyway, which is sorta the purpose of the conditional structure, things that can't change. Would you see implementing all properties of a VI in this conditional structure?

I really am editing the VI. It is fixing whatever bug or issue I found with the reentrant VI, that couldn't easily be troubleshot with debugging turned off (or no probing ability like on reentrant RT VIs).

I would definitely use this on reentrancy. Yes I designed a set of code to function as reentrant (and some times inlined) and it works and is tested and is great. Then comes a time when it behaves oddly on RT. Since RT can't debug reentrant VIs in the typical way with probes and break points, I will then change all the VIs I feel I need to debug to non reentrant. Make a set of test code that only uses one instance of that code, debug it, find the issue and fix it, then turn reentrancy back on. Maybe another one might be something like turning on wires retain values on a VI, or multiple VIs. Asbo had an idea on the Idea Exchange for improving this too. But overall I don't feel strongly one way or another

I was asking for an explanation, full well knowing it might lead to me asking for other things. But I do agree that the result of an XNode stating "I'm inline safe" and then not being, might lead to a crash or other unexpected behavior. Still I sorta feel like that is the result of a poorly made XNode, and while NI could protect for it, there are plenty of places I can force LabVIEW to crash doing something stupid and NI can just respond with "Don't do that." because I'm at fault for not abiding by the documentation.

You must know the second half of that expression...NOW WHERE'S MY MILK? (sorry for shouting but it felt appropriate). I'd love for a way for the XNode itself to state that it will or won't contain code that allows inlining since auto detection is mostly impossible. But it sounds like that will likely never happen. Thanks for the the help.

This really does seem like a feature of an XNode. Somehow telling the IDE that it can or can't be placed into a VI that is inlined. Looking at the XNode in a text editor doesn't seem to help, nothing jumps out at me as a value stating it can or can't be inlined. And the output of the generated code doesn't seem to indicate anything either. The only hint we might get is from someone at NI...that might be reading this and wondering if they should give the mouse a cookie...the mouse says "yes".

This isn't true for all XNodes so you are right there must be something else going on. If you drop the Error Ring XNode (made by NI) it appears to work as expected, working on inlined VIs.

Okay I think I figured it out. An XNode gets inlined into your VI automatically. But there are some functions that aren't allowed to be in an inlined VI, like New Data Value Reference, and property nodes. So if your XNode contains something that normally can't be inlined, then the XNode is fine, but it can't be in a VI that is inlined. Make sense? This is also why VIMs in 2017 can't contain property nodes since they aren't allowed to be inlined.

It seems the two functions used are uncompress, and compress, given a string input, and generating a string output. I'm unsure of if or how the LabVIEW native zip functions could be used in place of these but if you can do that this will be more multi-platform. Also how in the heck did I miss this toolkit all my life? Very cool.

I did find a work around for this. If you add an Always Copy to the ReadDVRData.vi coming out of the read function, this VI appears to work as expected.

I'm starting to feel the same way. I was super excited when this came out cause I had some real places that I could start using it right away. But I found a bug on RT (which I've submitted no CAR yet) which can cause RT applications to crash if you access a reference that is no longer valid (Queue or DVR). This is bad but the answer for now is just don't access invalid references until this is fixed. The problem is I've seen plenty of times where after I enable read-only DVRs, the reference goes invalid in some places causing a random crash. Debugging these crashes is really hard, and isolating it into a small reproducible project that NI and others can test with is also hard. But it is also difficult for NI to fully test these new features on a large production level project because that's not what NI does, we do. Thank you for posting it to NI, hopefully we get a fix as an F patch.

I have some software I've written that outputs to the non default speaker (headphones in my case too). It worked as expected changing the device ID in Windows 7 x64, but I haven't tried running that software in Windows 10 since upgrading my OS. I'll try to remember to try this out when I have access to that computer. Edit: Okay a little bit more on my situation. I had a desktop PC with audio going out on the HDMI to a TV. I would plug in head phones, which Windows would make the default audio device. I didn't like that so I changed the default audio device back to the HDMI output and all normal software would output to that. I would run my LabVIEW VI to output specific audio that I wanted to hear on my headphones, and not interrupt the HDMI audio.

I've used Mercurial with LabVIEW in the past, I'd recommend you checkout the TortoiseHG which has similar explorer functionality you are probably used to in TortoiseSVN. https://www.mercurial-scm.org/wiki/TortoiseHg As for separating source. This feature has been in place for several years, and while there could still be bugs with it, most of the initial problems problems people have had with it have been ironed out. That being said I do sometimes still need to purge my compile cache to force things to work, but I think that issue could happen on non separated code as well. As for the read-only locking functionality. I remember having this but I don't remember how to configure it to behave this way. But with DSCC I think the idea is to not need to first ask to get locks. The intent is anyone can make changes and then push them to the repo as they need. I have only worked with DSCC a couple of times, but I don't remember stepping on any other developers foot much.

It's somewhat non-trivial to setup. But you can create an x86 based Linux RT VM to test this type of thing.