shoneill

Service unavailable......

36 minutes ago, hooovahh said:

That's what I was trying to say.  I like that I can do that with an NI VI.  Just hit run and start interacting with the front panel for debugging.  But this version looks like you have to perform a separate compile operation, which makes the bit file, and then you have to write host code to talk to it.

I also understood the opposite of what you apparently meant (and also thought "hey, you CAN do that with NI").

Check to see if any line intersects with any other.  For N line segments, this requires (N-1)! comparisons.  Easiest way to do it.

Once you know which lines intersect, you can remove the in-between lines and move the start / end point of the two directly affected lines to the intersection point.

So it's not a bug in the node per se but a bug in the mind of the person who thought this is how it should operate.....

Poly VI works as long as at least the connector pane pattern is the same, even if the data types of the individual connectors is different, this is true.

If the code is rapidly changing, the mainteainance of the poly VI can be a pain though.  Apart from that, I agree it's a very nice way to kind of get the best of both worlds.

I spent many hours trying to solve similar problems only to come to the conclusion that the solution I'm looking for makes no sense logically.

Asking for Dynamic dispatch to take care if which VI to call is only valid if the connector pane in invariant.

As soon as the connector pane is no longer invariant, then Dynamic Dispatch alone cannot know what to do.  You can either move to a generic dat ainput type (A solution I personally am not fond of) or you can implement some VIs to pass in arguments BEFORE calling "Initialise" (as others have pointed out).  The second version has the advantage of allowing a new "Initialise" to be called ont he object whenever you might want that as all of the parameters are internalised.

14 minutes ago, kull3rk3ks said:

so am I correct in assuming that what you are suggesting is that I implement a config class of which i pass the correct child instance to the initialise() method of the messenger class and the child instance gets its init data from there?

I wouldn't do this as it doesn't solve your problem, it actually only makes it worse because instead of casting from Variant to whatever data you require in your ACTUAL Initialise funciton, you are trying to cast objects which is (AFAIK) less efficient.  Doing this with classes versus variants brings nothing new to the table.  You can still wire in the wrong configuration class and get run time errors.  The option with internalising the parameters into the object before calling "Initialise" can at least catch type errors (even if it can't catch missing VIs to set certain properties).

Of course the other option is to have a dedicated "Initialise" method for each class and ditch Dynamic Dispatch for this function altogether.  By designing an "Initialise Device X" and "Initialise DEvice Z" methods independently of each other, you can then have the connector pane exactly as you require it with inputs declared required and strict typing.

Of all the methods mentioned here (assuming re-initialisation is not a big need) I would simply create non-dynamic dispatch initialise VIs.

Ooh, James, that's another interesting feature of RT deploys I forgot to mention.  Random broken VIs in classes which run perfectly well on their own.  I've seen this on many occasions also.

I mentioned these issues to some R&D guys at NI week and they seemed surprised at the information.  Where does all the information go when we send it to NI?

Below follows my personal experience and frustrations, YMMV.

I have been cursing this "feature" for a few years and have tried raising the issue with NI.  My dream would be context-free VIs.  There are certainly a few issues with saving VIs when using RT targets.

When working on multiple targets, apparently LV switches out certain libraries depending on the target.  Using one VI on a windows target and the "same" VI on a RT target may actually reference a different VI in the background with LV switching out target-specific VIs as required.  The user doesnb't get any feedback on this, it's all controlled by the IDE.  Unfortunately, the VI format is such that certain information about this specific VI is saved in the source code of the VI (Path, connector pane and so on).  So when deploying to a RT target, a save is forced which again forces the VI to produce a different source than before (other things can also lead to unneccessary changes to source code).  Going back to Windows target will then prompt a save when closing the file because..... I don't actually know why exactly.  Does the windows version of the file receive a notification that the file was since saved from a different context?

The very same thing happens with conditional disables, the currently active conditional disable is saved in the source code of a VI even though upon loading this is guaranteed to be overwritten anyway.  All of these things make code reuse over several targets a royal PITA.  I was hoping any future developments would fix these problems, but I'm as yet unsure if NI has understood how annoying this behaviour is.  I think any such pollution of source code by target-specific data (which is enumerated again on load anyway) should be avoided like the pest.  I have since written a VI which uses SVN command line tools to do an automatic LVCompare on the current on-disk VI hierarchy versus their pendant in the repository and auto-reverting if LVCompare detects no change.

Shane

PS:  Regarding saving of VIs between windows and RT..... "Funny" thing is when this all happens to VIs which are set to be inlined and actual code changes have been made.  My experience is that LV will mark the inlined VI as being changed, but not the owning VI (Whose compiled code actually contains the "old" version of the inlined VI).  When deploying LV will deploy the new inlined VI (which is a pointless exercise as the VI as such is never called) but will still deploy the old version of the parent VI (which now contains out of date compiled code).  This leads to all kind of fun with VIs running on RT not being marked as such in the IDE and vise versa.  Yay.  Productivity. .  My workflow has adapted to go through the entire VI hierarchy from the sub-VI to main VI one by one and saving each and every VI so that LV will actually propagate the changes in inlined code to the actual application being deployed.

On 25.7.2016 at 7:59 PM, Darren said:

 

I feel confident in claiming that I use Quick Drop more than anyone on this planet. I use these shortcuts (Remove and Rewire, Insert) dozens of times a day. I've never seen the instability y'all are talking about. No crashes, no "corrupt control references". I've also never seen a CAR reported on these issues either.

I'm not discounting the fact that y'all are experiencing these issues. Believe me, I hate it as much as anyone when the car repair guy tells you that there's no way your automobile can be malfunctioning in the way you describe. But if y'all are seeing these issues as frequently as you claim, why have I not received a bug report that I can investigate? I realize that it's sometimes hard to get things into a reproducible state that can be reported. But hopefully y'all also realize there's not much I can do when the first I hear of these issues in 8 years of the feature's existence is on this LAVA thread.

Reproducibility is the problem.  As soon as we strip down things to get a format suitable to submit as a problem report, the problem invariably goes away.  This is the case with several things we observed over the years from wierd RT deploys (The RT guys had never heard of our issue at all when I asked about it at NI Week) to corrupt FP control references in typedefs created by QD.  Reduce code, problem goes away.  Great. 

How does NI propose we document these problems without sending a complete VM with LabVIEW installed AND complete source code for our project?  Sometimes these problems just get swallowed whole by the inconveneice of trying to demostrate their existence.

BTW a tip for anyone who might want to contribute next year.

If your camera has a large enough capacity (mine could record over 30 hours in one sitting), it's quite feasible to set the camera up in one room and then actually go see a different presentation.  This way you can optimise your personal perferences separately to your preferences for recording.  I say this because Mark was too quick reserving a seat in Room 15 for the advanced track and without multi-tasking like that I would never have gotten to see Altenbach's presentation.

There were also enough power sockets available so that battery power was not required.  I don't know if that's alwaqys the case but it was here at least.  Additionally, each room had an audio mixer at the front of the room, it should be possible to connect the mic input of a camera to one of the outputs of the mixer in order to optimise sound quality (if NI allows that) instead of using a microphone from the back of the room.

You are all welcome.  Just trying to help out.

I, in turn, need to give huge props to Mark for initiating the whole thing and making sure it's acceptable to do so.  And also for properly naming all the videos I dumped on him....

Apologies to James McNally.  I missed the first few minutes of your "Practical OOP Techniques in LabVIEW" presentation because of the Champions lunch.  I ran to the presentation as fast as my little legs would carry me, but alas I still missed the start.  So apologies for that. 

Not all of my answers are useful.....

• Splash screen going black?  Haven't seen this.
• Locked classes? I bet there IS something running in the background somewhere or a reference to a sub-VI left dangling....
• The installer configuration will actually do a "Preview" of all executables before opening the dialog.  The time taken is therefore basically equal to the amount of time taken to do a preview of all of the other builds included within.  Extremely annoying.
• VI outside a project: Context.  The VI saves information regarding to the context in which it was opened.  Same problem occurs with RT and Windows and FPGA, my VIs I reuse on multiple targets demand repeated saving event hough the code itself has NOT changed.  This kind of bookkeeping rubbish makes life hard when working across multiple targets (And project and not project are two different targets)
• compile cache leading to saves?  I don't know.  I haven't directly observed this. (maybe liked to context changes between the version saved on disk and the version in memory?)
• Cursor not tracking properly? Graphics driver.  Windows 2D graphics acceleration. Virtual machine.  Take your pick.
• Saving VIs after a build.... I think the build opens the VIs in a different context for compiling and if the VI contains any target-specific code, this will be saved as part of the annoying constant bookkeeping LabVIEW does with its binary files which are "suppposedly" separated from source code.  Why the last context needs to be saved in a VI I do not know, but it's something NI is holding on to in future if you get my point.
• VI not being edited wanting to be saved? Don't know.  Again, possible context differences between disk and memory versions of VI.
• Every VI in memory when opening a project? Because that's how NI decided it should be done.
• Search system.  There's nothing to explain here, so I claim this point towards my beer tally by default.
• Cancelling a build.  This is a PITA and I have no explanation beyond sloppy implementation.
• Finding all instances of VIs with different search windoes : Never noticed that.  Must watch out for it in future.
• EXE icon, again nothing really to explain here. 
• Crash when undoing QD. QD is buggy or is using unstable methods.  We've had several cases of QD shortcuts creating corrupt control references which ended up costing us days of debugging to find.  Random crashes and general instability ensued.
• Accessor creation.  Because if working with Classes would be too easy, the sense of achievement when actually managing to get the code working would be severely dimished.  It's for the best.
• Class prioperties dialog.  No idea and it always annoys me too.
• SCC login.  Haven't used that for years after downloading a free version of Perforce.  Here again, nothing really to explain. Beer counter = Beer counter + 1
• last two dealing with bew services.  Don't use them, no comments.

To add to this list:

• When deploying code to a RT target, we're never quite sure which version of code gets deployed.  Inlined VIs, when saved with changes, do not seem to propagate the "changed" flags to their owning VIs which then leads us to do a bottom to top forced recompile in order to properly re-sync the compiled cache with the code.  Even then we sometimes get VIs marked as running on the RT which shouldn't (have just been removed) or vise versa where a VI which definitely IS running on the RT is not marked as running int he IDE.  Frustrating as hell and a real time waster.
• FPGA compiles continuously reporting that the maximum number of messages from the compile server have been exceeded and there'll be no more feedback on the compile process until the compile is finished and even then half of the timings and resource utilisation statistics are missing...... I LOVE having to wait 2.5 hours for no useful information.
• Window juggling in the IDE.  I want to open a VI and go straight to the block diagram.  Double-click, Ctrl-E in short succession.  Window swapping ensues and after the graphical random number generator is finished, my Ctrl-E nearly always gets sent to the project window which then switches to files view.  30 seconds later I can get back to work.  Lovely.
• I also love how the Internet Toolkit is deprecated but there is no VI in any current toolkit (that we have found) to parse a CGI string.
• Icon editor has, since several versions, not been able to connect to NIs server to update the glyphs.  Also, the glyphs are seriously lacking, far too few standard LV glyphs are included.
• I also love that the project does not allow two RT targets to share the same IP address.  We have one host software with several versions of our RT system, only one of which is ever connected.  If I give two targets IP addresses of 10.0.0.15, LV cries.  If I give one 10.000.000.15 and the other 10.0.0.15, labVIEW is quite hapy (And apparently, stupid).

Shane

Get VI Dependencies ignoring code inside a case with constant selector sounds like a bug to me.

I presume it works OK with inlined VIs?

I don't have any proposals.  You're completely free to choose to go or not go where you want.

52 minutes ago, ShaunR said:

You'd have to give me a link. I have a first in, first out memory so that info is long gone.

Here you go:

I also don't know why linking to a post includes the majority of the first line....

For the record, I believe we were on the same page regarding that discussion IIRC. I find the fact that Mark publishes the videos an outstanding piece of work and he forever has my gratitude.

Regarding the "elitist" attitude it is in part what you describe wih the "dark side".  Your own post in this thread about not wanting to go to NI even if LAVA was closed is in a similar vein. I just find it could present an unneccessary barrier to newcomers.  If someone comes here after learning from the NI forum (it IS possible) and they sense this attitude, it can be intimidating.  It is also a shame you don't post over there.  While I agree that the signal to noise ratio here is hugely better than on the NI site I think the community at large would benefit greatly from you popping over to the dark side to answer a few questions instead of only posting here.

Is it a huge thing. No.  Can it be off-putting for newcomers who aren't as rambunctious as some of us? I think so, yes.

Ps I also think your insinuation that the work done in the NI forum is somehow not "altruistic" is quite off the mark.

1 hour ago, ShaunR said:

That's just bizarre   I'm not sure what you are trying to say here.

Others = not LAVA

If I think a topic of of general interest- NI.

If I think a topic is only of interest to the LAVA crowd - LAVA.

It's not really very complicated.

Shaun, I'm referring to tone not content.  As I have mentioned in a few places in my post, the content here is great and I'm aware it's for more advanced users.

It's more a background noice of belittling NI.com that alienates some people because if creates an "us" v "them" mentality.

We had a discussion on the elitism approach to the CLA videos before and I outlined my position there very clearly.

Disclaimer: I don't mean to be negative in this post but I'm telling it as I see it.  I may be wrong (no surprises there) but if we value frank and open discussions, here we go.

I post a lot more on the NI forums than I do here.  I like helping out possible future LV gurus.  The word guru apparently means "He who dispels the darkness".  Many of you have much brighter torches than I do but we need to spread the light and spread it far and wide.  The more we withdraw into ourselves, the brighter the light may seem, but the fewer people benefit from it. 

To be honest I think LAVA has a bit of an elitist feel to it which does not help LAVA or its visitors (or potential visitors) in any way besides feeling smug about being good enough to be here (the people here are undoubtedy very knowledgable, this is undisputed).  This is why I try to bring also more advanced topics to the NI forum.  Chances are that it will reach more people.  If we decide to only hang around with people we think of as our peers (because the ego boost feels nice) we either create an unaccessible wealth of knowledge which benefits only a select few or we actually miss out on changes in the commujnity and end up getting left behind.  Neither outcome is particularly appealing to me personally.

I come to LAVA when I need something for me which I think is uninteresting for others.  I go to NI.com when I want my knowledge (or possible answers to my questions) to be as accessible as possible in order to benefit the LabVIEW ecosystem as a whole.  If we insist on creating an "us" v "them" atmosphere then the gulf will only keep increasing which will of course stroke our egos even more which will increase the gulf which will......oh dear.

I remember a story from way back when the computer game "Doom" was released.  One report was that the game was technically brilliant and fun but the reporter tired of it quickly.  It turns out he was playing the game in only the first room and never realised that what looked like a wall was a door to the rest of the first level (and to all other levels - he was playing like only the first 1% of the game).  I think it's fine showing off technical prowess to users but if we don't help newcomers find the door the appeal will be very limited.  Sure, not everything that comes through the door will be welcome but that's life (or Doom, I can't remember ).

If all of this makes people wary of being overrun by the unwashed masses then I think a paid subscription model is the only way to go.  But I severely doubt if that will increase the number of posts.

For me personally the bottom line is that if I had to choose between the NI forum and LAVA, I would choose the NI forum because I think the effort spent there is maybe less valuable to me in the short term but is essential to the longer term health of the community.  Don't get me wrong, I value LAVA greatly and have learned a lot here.  I don't want to see it go.  I also don't want to see it get increasingly isolated.

There are rumours of a private method to allow a child to remove the "must always call parent" from itself requirement but it's problematic.

Fast producer, extremely flexible consumer?
 
Object queue (yeah LVOOP is a good choice here).
 
Allows fully flexible parsing with minimal overhead in the producer (deals with no DD VIs).  Receiver doesn't need to know ANYTHING about the formatting.

BTW if you're thinking you can't send objecty by RT-FIFO, just send a DVR of the object instead.

String formatter.zip

Ah RT, gotcha.

You COULD pass on a display OBJECT instead of an actual subpanel reference (Abstract base with no action / data) with a DD "display" method and only provide a child of this with actual subpanel functionality for non-RT code.  That way you retain encapsulation and provide extensibility but it IS more work.  this transfers to a NOP on RT and can be modified as required if future code changes are needed.

 

Ooooooo I like this idea shoneill!  Let me see if I understand it: So the basic flow would be to call the "Get UI Refs" DD vi to gather the necessary identifiers, then use ACBR to call the DD UI method (wrapped in a static VI in the parent method) and pass it the chosen UI ref.  The DD method then checks its own VI ref against the input ref, and calls the parent if it doesn't match.  The only task left is to pass the active vi ref back to the caller for insertion into the subpanel, which can be accomplished with the single element queue we discussed previously.  Am I understanding your suggestion correctly?

Where do you get the refnum for the comparison?  Can't you use the string identifier and then request the reference from the DD vi?  Alternative would be to pass in the reference for a subpanel and tell the object to insert itself.  That way verything stays encapsulated within the objects and changes in methodology can be better managed.

Otherwise yup, that what I was going for.

Normally, this would be my go to as well, but this particular design restricts that option, see below

• Wrap each class' implementation in a static vi.
  • You cannot have VIs in child/parent classes with the same name unless they are DD.  Therefore, I would have to create and name each UI differently, which is not very maintainable.
• Wrap the DD vi in a static VI at the parent level only
  • This would mean that it would no longer be possible to call the specific implementation that I want.  This option is great for the general case of calling a DD vi with an ACBR node, and I use it in several places already.

I don't see the problem with this approach to be honest.  Even if the VI you are calling is not DD (Implemented as static in the Parent) the VI being actually invoked will be the correct child version.  Your problem is knowing which version on the hierarchy chain to call explicitly.  If you already have a function to return unique identifiers for the different UIs, make that an input of your static VI and pass it to the DD VI which subseqeuntly makes an ID check at each level of the hierarchy and then launches the UI if the ID matches and passes the control to the "Call parent method" node if it doesn't match.  Think of it as a "Chain of responsibility" which is a valid OO approach.

This way you can filter down from the actual child until you have the correct UI.

wrap the dd vi in a static vi. done. dusted.

I think how you do it is a bad idea.  There are almost certainly more robust und easier to understand methods to do this.

You can call the "Call parent method" in any child DD method and in this way pass on UI data to the base class (which will be called last) which then creates and shows the UI.  In this way you automatically have a hierarchy of UIs available.  If, for some reason, some UIs are not always available, then you simply don't add the data to the chain for that instance of the inheritance hierarchy (abstract classes for example).