LabVIEW 2017 Dynamic Event Registration Behaviour

[hooovahh]

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.

[Neil Pate]

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

[ShaunR]

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 

Define "using" I develop in 2009 and recompile in later versions (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 March 7, 2018 by ShaunR

[Neil Pate]

Slightly off topic, but the other day I opened a version of LV I have not used in ages, I think it was 8.5 (maybe it was 2009) and was blown away by the speed of the IDE.

[hooovahh]

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.

[craig]

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.)

 

 

 

 

[Neil Pate]

On 3/7/2018 at 8:07 PM, ShaunR said:

Define "using" I develop in 2009 and recompile in later versions (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.

[crossrulz]

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).

[drjdpowell]

I would say the conditional and concatenating tunnel options are a very notable feature introduced post-2009.

[ensegre]

Parallelizable for loops were 2009 or 2010?

[hooovahh]

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.

[ShaunR]

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)

[ShaunR]

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 March 13, 2018 by ShaunR

[hooovahh]

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.

[infinitenothing]

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 March 13, 2018 by infinitenothing

[drjdpowell]

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.

[shoneill]

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.

[Daimones]

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