Jump to content

LabVIEW 2017 Dynamic Event Registration Behaviour


Recommended Posts

Okay deep breathes everyone.  (myself included I took part in this too)  I think we all understand where everyone sits.  I think Shaun understands that starting in 2017 NI made a change that they deemed was a bug regarding buffer reusing that caused the functionality to differ from what they expected.  This is seen as a good thing by some and a bad thing by others.

After watching much of the linked video from Linus my option that was far in one direction, swings just a little by closer to what Shaun was suggesting, thank you for that.  But I think an important point he made in that video was that the amount of effect a change has should make or break the change.  At one point someone asked what version of GCC a distro should use moving forward.  And he more or less said, well the people effected by this change now is some what small so "you are off the hook".  The most core library in the system effects tons of people and so breaking APIs here needs to be done cautiously.  The larger the impact the more likely you should just leave it alone.  Do lots of developers use user events?  Yup I think so.  Do lots of them use it the way Shaun is showing here, well it is hard to say but I would say it is the minority of those that use user events in general.  NI has broke other compatibility in the past.  Primarily I think of the INI fiasco a few years ago, but at least in that case these were vi.lib functions not on the palette so they assume few would be effected.  When possible I do see NI make an effort to preserve functionality.  Think about when you are opening an older VI in a newer version, there are times that a small subVI might be inserted automatically to keep the same functionality.  I saw this with some TDMS functions where a function wouldn't generate an error in older versions but would in newer, so NI would insert a clear error on that specific error if you opened older code in newer LabVIEW. 

Most of us work in pretty closed environments when it comes to our own APIs we can break compatibility and just tell the couple people (or update the couple of projects) that things may need a relink, or some tweaking to be fixed.  As teams grow our concepts of difficulties given to those using our APIs needs to grow too.  NI certainly has a larger user base on their APIs than I do, and then there is the fact that my APIs are free while you are paying NI to make updates that might break your code which can be discouraging.

Link to post
Share on other sites
  • Replies 67
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I just became aware of this thread and I'm not going to go back and comment on all the discussion points that have been made before, except to say: The original code which did not use a shift reg

It's too bad they didn't "fix" it by allowing this (where I take Shaun's original code and just delete the constant): Assuming an internal shift-register behavior in the Event Structure, th

To my understanding, the data type is fixed at design time but the Event Registrations are run-time dynamic.   I think Jack Dunaway's excellent examples on User Events showed this.

Posted Images

5 hours ago, hooovahh said:

At one point someone asked what version of GCC a distro should use moving forward.  And he more or less said, well the people effected by this change now is some what small so "you are off the hook".

He actually says they fixed it in the Kernel (~12:25) so they were off the hook because the downstream user wouldn't see it.

 

5 hours ago, hooovahh said:

When possible I do see NI make an effort to preserve functionality.

I agree and I think I mentioned that earlier. But it looks to me like this was fixing an unrelated bug which had unforeseen consequences. It's probably a bug I've never seen in another fringe use case.

 

5 hours ago, hooovahh said:

Most of us work in pretty closed environments when it comes to our own APIs we can break compatibility and just tell the couple people (or update the couple of projects) that things may need a relink, or some tweaking to be fixed.

I don't do this. It is something I vehemently practice as well as preach.

One example was that I changed the compane of a VI in ECL.If the customer used the new examples it would be fine. If they used the old VI in their own software, the new one would be loaded and they would have to rewire. To make sure this didn't happen. I marked the old VI as deprecated and replaced it with the new one in the pallets. But I still ship the old one with the distribution so as not to break user space. It will remain in there forever.

Another:

The MDI toolkit was written in LV2009 (like everything :) ). Something broke the event refnums (like now, but much, much worse). To make it work in later versions, all the front panel event refnums have to be replaced. If back-saving; the same had to be done. There were 3 customers already using the 2009 version so I pulled the 2009 version and recompiled for 2013 (this is when it appeared on the LVTN). I now keep 2 code bases for the toolkit, Development is still done in 2009 and changes are forward-ported to 2013 - the new minimum version. I do not require the 3 customers to update their LabVIEW version to get bug fixes and features as that will break their code and there is no way for them to recover without also replacing all the event refnums. So you see. This is not the first time I've been bitten by events changing.

2 hours ago, Neil Pate said:

I am just surprised ShaunR is using a version of LabVIEW newer than 2009 :rolleyes:

Define "using" :D I develop in 2009 and recompile in later versions :P (see MDI toolkit above ;) ). This is mainly because of TPLAT not supporting <2012? without putting special VIs in the code. Forgetting about 2009; 2013 is my next best/favourite choice (for stability and performance) but I have 2012 Linux and Mac versions for testing ECL so that is the minimum for that one. All the toolkits are tested in all versions on all platforms (except the MDI toolkit). From the minimum version to the latest, in both 32 and 64 bit.

Edited by ShaunR
Link to post
Share on other sites

Looking at older IDEs is a bit discouraging when it comes to IDE performance.  When I was beta testing NXG I made some comparisons in startup time, opening a simple project, opening a simple VI, and making a basic edit.  NXG was something like a couple minutes slower than 2017 for the whole process.  I imagine the responsiveness of 2017 to 8.5 is likely just as large a gap in 2017 to NXG.  And I remember when first using 8.x versions how it seemed dog slow in comparison to 7.1.  Maybe in a few years NXG 1.0 will seem fast.

  • Like 1
Link to post
Share on other sites
On 3/7/2018 at 8:07 PM, ShaunR said:

Define "using" :D I develop in 2009 and recompile in later versions :P (see MDI toolkit above ;) ). This is mainly because of TPLAT not supporting <2012? without putting special VIs in the code. Forgetting about 2009; 2013 is my next best/favourite choice (for stability and performance) but I have 2012 Linux and Mac versions for testing ECL so that is the minimum for that one. All the toolkits are tested in all versions on all platforms (except the MDI toolkit). From the minimum version to the latest, in both 32 and 64 bit.

It has been so long since I used 2009 (actually I may even have skipped that and gone 8.6 --> 2010), out of curiosity, in your opinion have there been any "must have" features that were introduced after this?

When were DVRs introduced, I seem to recall using them in LV2010? Off the top of my head the only thing I can think of is the reworked Web Services.

Link to post
Share on other sites
3 hours ago, Neil Pate said:

It has been so long since I used 2009 (actually I may even have skipped that and gone 8.6 --> 2010), out of curiosity, in your opinion have there been any "must have" features that were introduced after this?

When were DVRs introduced, I seem to recall using them in LV2010? Off the top of my head the only thing I can think of is the reworked Web Services.

DVRs were introduced in 2009.  I skipped from 8.6 to 2011, but I do remember having tons of issues with 2009.  But we all know that the best "must have" feature of any LabVIEW version was the new icons that showed the version starting with 2014!

Other notables: Vivado compiler for LabVIEW FPGA (2014), Channels (2016), Malleable VIs (2017).

Link to post
Share on other sites

Tunnels was a big one for me.  Was there something added to the functionality of static VI references?  Maybe adding the right click for their type?  Or maybe I'm thinking about features in the dynamically calling VIs allowing for run and collect being separate operations?  Many QD and functions can be back saved (but not all successfully). 

Others I use but could live without but do use all the time is dragging into and out of structures, live drag, and remove and adding space with CTRL and Alt modifiers, oh and snapping add/remove space to 1D.

Link to post
Share on other sites
On 3/9/2018 at 9:34 PM, craig said:

I just became aware of this thread and I'm not going to go back and comment on all the discussion points that have been made before, except to say:

The original code which did not use a shift register was wrong, but happened the work because of a bug in the LabVIEW inplaceness algorithm.  Any input tunnel should retain its original value of every iteration of the loop, so it should've stayed not-a-refnum every time, and therefore the dynamic registration should should have been lost where the loop iterated.   The issue was that the left dynamic registration terminal (which is always in-place to the right one) was also in-place to the input tunnel, causing its value to be stomped incorrectly.  This is clearly a bug and needed to be fixed.  It violated dataflow  'rules' for how tunnels are supposed to behave, and could've made some correct programs yield incorrect behavior.

This is not a change that would break a correctly written program, so it does not qualify as an "API breaking" change; this usage has always been wrong but happened to work due to a bug.  (This is categorically different than changing behavior of correct code or even changing undocumented behavior, which we try strenuously to avoid.)

It worked so it was was "correctly written" without knowledge of the underlying mechanisms and a method of how it "might" work in that way (like the DVR example) did not break dataflow.

That aside. Was the bug fix reported in 2017 issues responsible for this change in behaviour? If so. What was the use case that it addressed where the behaviour was errant ?(an example would be nice)

Link to post
Share on other sites
On 3/12/2018 at 7:11 AM, Neil Pate said:

It has been so long since I used 2009 (actually I may even have skipped that and gone 8.6 --> 2010), out of curiosity, in your opinion have there been any "must have" features that were introduced after this?

When were DVRs introduced, I seem to recall using them in LV2010? Off the top of my head the only thing I can think of is the reworked Web Services.

DVRs are in 2009.

I have thought twice about upgrading due to new features. Once was for the native JSON but it was so useless in the real world I stayed with my own. The second was the Start and Wait On Asynchronous call. My architectures could benefit from it but had no pressing need since I already have the tools to achieve the same result,

Many people rave about self indexing tunnels. It was (is?) just some syntactic sugar for the old style so there were no performance benefits but It looked a bit nicer - hardly worth the risk of updating to a new version or keeping old and new versions of the code base.

Some features (like the live moving of structures and wires) I detest but will suffer it if the needs must. Anything. that forces me to change my work-flow (like quick drop) I resist vehemently so you can add any of those to the list of why not upgrade.

Be aware, though. I produce toolkits so the minimum version is important so that as many people can use it as possible. This is an incentive for me to go back as far as possible. It just happens that 2009 is pretty much bullet proof, no random busy cursors slowing me down and arguably still the fastest executing code. When it first came out I was so pleased that the pain and suffering of the buggy 8.x series was over and disappointed with most of the later versions for the same reasons.

Edited by ShaunR
  • Like 1
Link to post
Share on other sites
2 hours ago, ShaunR said:

Some features (like the live moving of structures and wires) I detest but will suffer it if the needs must.

Just an FYI there is an INI key that can turn this off.  It is not exposed in the options but probably should be.

Changing work flows can be a good thing.  Years ago I thought the best way to keep a record of my source code was to zip up all of my source everyday.  I'd have a zip for each day with that days snapshot of code in it.  I'm so glad I learned about proper SCC and the workflow changes that came with it.  QD and conditional tunnels have likely saved me man months of time and I'm grateful for it.  SCC has probably saved me more than that in the amount of times I would have otherwise lost data, or opened the wrong version unintentionally.  That being said many improvements you don't like you simply don't need to use.

Link to post
Share on other sites

I guess this is a "what's new in LV" thread now. There are some performance improvements in the conditional indexing tunnels on a for loop. I think it allocates the max size and trims it at the end. The async tools are also a huge performance increase over the old VI server method. Also, DVRs now allow parallel read access which is cool. The menu plugins provided many productivity improvements. VIMs make reuse easier.

Regarding the new dynamic refnum behavior, does everyone agree that the right terminal is more or less obsolete and could probably be replaced with something like a linked tunnel? Am I misunderstanding the new behavior?

Edited by infinitenothing
Link to post
Share on other sites

Conditional Tunnels had no performance benefit in 2012, but beta testers of 2012 argued for higher performance, and for 2013 they were changed to use the same techniques used with indexing While Loops, which are much higher performance and not something one can do another way.

Link to post
Share on other sites
13 hours ago, infinitenothing said:

 

Regarding the new dynamic refnum behavior, does everyone agree that the right terminal is more or less obsolete and could probably be replaced with something like a linked tunnel? Am I misunderstanding the new behavior?

There is no new dynamic refnum behaviour.  It behaves just like it was always designed to behave.  The left and right sides of the terminal in the event structure have always worked that way.

Link to post
Share on other sites
  • 2 months later...

I realize this is an old thread, but I noticed something and wanted to bring it back up. Also, I believe the functionality has changed, no matter how minute however there is a way to still make it work, which I've attached the VI for.

If you read the LabVIEW help on Dynamic Event Registration it seems that you are primarily supposed to be "Modifying" an event registration during run-time, not creating them. Because you have wired in a constant "Type" of the registration, you have never actually created an event registration, thus is can't modify it and send that modification back through the dynamic event terminals.

Thus, if you register with null events, rather than use a null event type specifier, you do not need to use a shift register. The shift register is allowing you to overwrite that event registration with an entirely different one, which the dynamic event terminal does not. 

Again, this was definitely a change in functionality, but I believe it makes sense to be the intended functionality after reading the LabVIEW help.

evnt.vi

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Jim Kring
      [Update: NI Bug 974336]
      There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here).
      Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet.
      Coerce to Variant Fail (LV2019).vi


       
      Note that adding another element to the outer cluster causes the problem to go away.


    • By A Scottish moose
      Hey everyone,
       
      I am working on a backup function for a test executive.  The backup uses the 'class to XML' vi to create an XML string and then save it to a file to be reloaded later. All of my test specific information lives in the class (or one of it's children).  I like this functionality because it makes backup and reload brainless.  It just works.... until now... I've got a test class for my current tester that's grown rather large.  Everything works fine, until the tester loads some waveform data into either of the waveform arrays.  Without data in this field the class reloads just fine, otherwise if fails and says the XML is corrupted.
       
      As you can see in my backup vi I have built in a work around that flattens the waveform arrays to strings, drops them back into the class private data, deletes the waveform arrays and then writes the class.  This works! Much to my surprise both waveform data and the rest of the class data are written to file and reloaded without error.  
       
      Does anyone have any knowledge or experience with this? 
       
      Cheers,
       
      Tim


    • By Stobber
      If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why? See the attached code (LV15) for an example.
      I don't want to use the ACBR node right now because I want to set some control values of the VI ref on a different diagram than the one that will run it. (I just want to pass the VI ref between calling diagrams, not all the values that'll be passed into it.)
      DVRtest.zip
    • By Bob Schor
      My colleagues and I use the Fit VI to Largest Decoration function in OpenG all the time, and it (usually) works like a charm.
       
      I've got a fairly small Project, a simple State Machine that takes readings from a Vernier SensorDAQ device and plots it on a graph.  I'm using a Queued State Machine pattern, so I begin by creating the State Machine Queue and enqueuing the Initialize State.  The first thing I do inside Initialize is Fit VI to Largest Decoration, and it throws Error 1, pointing to the final FP.PanelBounds Property node that it is setting to resize the Window.  I also watched this function run with Highlight Execution turned on, and sure enough, the Error line was OK until it got to that final Write to the Property node.
       
      My initial suspicion was the SensorDAQ function, even though it hadn't been called.  So I took it out, but the error persisted.  I also tried making the Fit VI to Largest Decoration the first VI to be run -- same error.
       
      Ohh, an idea.  The VI in question was written by a colleague, who is not big on LabVIEW style.  This morning, I rewrote the entire program, keeping only the Front Panel which has, among other things, a Graph on it.  This problem is so weird that it almost has to be something "unconventional" -- I'm going to leave this post here, in case anyone has other insights, but I'm then going to replace the Front Panel and will report back, especially if it fixes the problem.
       
      Bob Schor



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.