Jump to content

LabVIEW 2017 Dynamic Event Registration Behaviour


Recommended Posts

30 minutes ago, hooovahh said:

So you weren't implying this is a bug that everyone relies on, by quoting someone saying:


Well. Listen to this for a few minutes It is my sentiments entirely and I get just as annoyed and frustrated as he does with this sort of thing..

24 minutes ago, hooovahh said:

This isn't the same issue as your event example above.  In the DVR case you actually made a method for the next iteration to use the newly created reference.  In the event case there is no shift register or feedback node.  You register for something, but then the next iteration of the loop has the event structure getting that null refnum again.

I supplied a prototype (DVR ref constant) to the the initialising terminal to fix the datatype and then initialise the DVR (with Create DVR). From my perspective. This is the same as supplying an event refnum to the left hand dynamic terminal and then initialising (registering) the event which is passed to the right hand terminal. In this analogy. The feedback node is hidden under the hood which is why the new registration miraculously appears at the left terminal after re-registering.

I think it is just a better analogy than a queue which is also hidden.

Edited by ShaunR
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

1 minute ago, ShaunR said:

I supplied a prototype (DVR ref constant) to the the initialising terminal to fix the datatype and then initialise the DVR (with Create DVR).

Right but that isn't what is happening in the event example.  Yes you are providing a type, telling the event structure what type to expect, but this isn't happening on just the first iteration of the loop (like the DVR example).  You are providing a type, and providing what the event structure expects is a valid refnum that points to to the specific events it should react to.  And every iteration of this loop you are providing a null reference.  The DVR example works because the new reference is used, the event structure doesn't because that new reference is replaced with a null at the start of the next loop.

I agree that there is a type of feedback node internal to the event structure, being able to know what it registered for last time.  But by providing a new event to the outside of the event structure, it believes you are telling it to now use that event instead of the last one you told it to.

Link to post
Share on other sites
2 minutes ago, hooovahh said:

Right but that isn't what is happening in the event example.  Yes you are providing a type, telling the event structure what type to expect, but this isn't happening on just the first iteration of the loop (like the DVR example).  You are providing a type, and providing what the event structure expects is a valid refnum that points to to the specific events it should react to.  And every iteration of this loop you are providing a null reference.  The DVR example works because the new reference is used, the event structure doesn't because that new reference is replaced with a null at the start of the next loop.

I agree that there is a type of feedback node internal to the event structure, being able to know what it registered for last time.  But by providing a new event to the outside of the event structure, it believes you are telling it to now use that event instead of the last one you told it to.

Correct. The behaviour has changed. It used to work similarly as I described (and to the DVR analogy). Now it doesn't.

Link to post
Share on other sites

This is a DVR analogy that represents why the event structure example doesn't work:

dvr_BD.png

This is more representative of what you are doing.  Yes it worked previously, but it shouldn't have.  If this VI worked in 2009, and doesn't in 2017 would you also claim it is a feature an not a bug?

EDIT: Also that video sounds interesting so far but is quite long, is there part you find the most relevant.

Double Edit: Seems I found it around 9 minutes in.

Link to post
Share on other sites
22 minutes ago, hooovahh said:

This is a DVR analogy that represents why the event structure example doesn't work:

dvr_BD.png

This is more representative of what you are doing.  Yes it worked previously, but it shouldn't have.  If this VI worked in 2009, and doesn't in 2017 would you also claim it is a feature an not a bug?

EDIT: Also that video sounds interesting so far but is quite long, is there part you find the most relevant.

It is representative of what it is doing now, maybe, and not nearly as useful. Also yes. If it had worked like that for a decade and I had written code to leverage it, I wouldn't expect it to stop working one day. Notice too, how a shift register, like the event, would restore the behaviour?

Lets be clear here. It's not a difference between 2009 and 2017. It is 2017 differs from all versions back as far as [at least] 2009.

I thought I had set the time start. anyhoo.....

Start at about 8 mins through to about 12 mins.

Edited by ShaunR
Link to post
Share on other sites

It's too bad they didn't "fix" it by allowing this (where I take Shaun's original code and just delete the constant):

Screen Shot 2018-03-02 at 4.43.14 PM.png

Assuming an internal shift-register behavior in the Event Structure, then this "uninitialized shift register" behaves in a perfectly dataflow-like fashion, and it's even simpler to code.   Unfortunately, it's also broken, as the Event Structure wont adapt to the type input to the right-hand Dynamic Event Terminal.

  • Like 2
Link to post
Share on other sites
8 minutes ago, drjdpowell said:

It's too bad they didn't "fix" it by allowing this (where I take Shaun's original code and just delete the constant):

Screen Shot 2018-03-02 at 4.43.14 PM.png

Assuming an internal shift-register behavior in the Event Structure, then this "uninitialized shift register" behaves in a perfectly dataflow-like fashion, and it's even simpler to code.   Unfortunately, it's also broken, as the Event Structure wont adapt to the type input to the right-hand Dynamic Event Terminal.


Or they could have just left it alone ;)

Link to post
Share on other sites
1 hour ago, ShaunR said:

For the purpose of the analogy, the feedback node is hidden.

I see your point there; a "read only on first call" input makes sense.   Unfortunately, it doesn't just read the input on first call, and there are use cases (though perhaps rare) where one might feed in different refnums on each iteration.   If you look at the example I posted, the input tunnel to the loop actually changes what it outputs, which breaks the dataflow rules.

I agree they should not have changed the behavior that has applied for so long (especially without telling people).

Link to post
Share on other sites
29 minutes ago, drjdpowell said:

I see your point there; a "read only on first call" input makes sense.   Unfortunately, it doesn't just read the input on first call, and there are use cases (though perhaps rare) where one might feed in different refnums on each iteration.   If you look at the example I posted, the input tunnel to the loop actually changes what it outputs, which breaks the dataflow rules.

I agree they should not have changed the behavior that has applied for so long (especially without telling people).

I'm not sure what "use cases" you are thinking of. But changing the event event reference null and voids all the cases using it. It is a design time, type, decision and can't be changed on the fly. The only thing one can do at run-time is listen for or stop listening for events. It seems, however, that if you really, really unlisten (Unregister For Events) then you are now stuffed.

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

It is a design time, type, decision and can't be changed on the fly.

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.

  • Like 2
Link to post
Share on other sites
On 02/03/2018 at 8:28 PM, drjdpowell said:

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.

Ahh. You are talking about panel/control/user refnums contained within an event ref? Yes they are. That still works as expected <2017 - either before the structure or inside it. There was no bug here to prevent this use case.

evnt5.png

evnt5.vi

Link to post
Share on other sites
2 hours ago, Antoine Chalons said:

statement that starts at 10:00 is the key and it ends with "if it's a bug that people rely on, it's not a bug, it's a feature".

Yup. My fault. I've changed the quote and noted in the edit. It also makes hooovahhs objection moot; for which he can carry no blame since I subtly misquoted. The sentiment is unchanged.

It's well worth watching from ~8mins through to ~12. I agree 100% with him and it is the reason I pulled Linux support for my toolkits that aren't pure LabVIEW - even though they do work on that platform.

Edited by ShaunR
Link to post
Share on other sites

There is a bug fix listed for 2017 for the following.

596804—Re-registering a dynamic event can cause subscribing event frames to behave improperly

There are no details beyond that but I suspect the behavioural change is a side effect of fixing this-whatever it was :P

Edited by ShaunR
Link to post
Share on other sites
On 02/03/2018 at 6:21 PM, ShaunR said:

I'm not sure what "use cases" you are thinking of. But changing the event event reference null and voids all the cases using it. It is a design time, type, decision and can't be changed on the fly. The only thing one can do at run-time is listen for or stop listening for events. It seems, however, that if you really, really unlisten (Unregister For Events) then you are now stuffed.

The bolded statement is rubbish, I'm sorry.

I have a use case.  In order to create a branching execution order in my event-driven code, I create entirely new registration refnums for a branch, swap out the event registration wires, execute the branch (which may itself branch....) before returning to the original queued up events.  It's a rare use case, but it does exist and is powerful. It also adheres to all of LabVIEW's semantic rules of how things should work.

I was reading the thread for a while and thought I was going to side with Shaun, but after looking at the code which he posted, I have to side with the others and say it's clearly (and I mean really clearly) an illegal buffer reuse compiler bug which has been fixed, and that's good.  The semantics of the code dictate that the Event Shaun wishes to fire should never be handled in this code.

The event registration refnum can be changed in every iteration of the Event structure.  That's dataflow.  The prototype of the Event Structure must remain constant but the actual event wueues handles within can be altered and substituted at will.  Swapping out the Event registration refnum and wiring up new references to the existing refnum (as mentioned elsewhere in the thread) are NOT the same thing.  Wiring up a new reference to an existing Registration refnum changes the event source for that event queue, but leaves all existing events in there.  Swapping out the event registration refnum actually changes the event queue.  Both of these should work and both of these adhere perfectly to dataflow.

Edited by shoneill
Link to post
Share on other sites
2 hours ago, shoneill said:

The prototype of the Event Structure must remain constant

and what happens if you change this "prototype" refnum?

On 3/2/2018 at 5:21 PM, ShaunR said:

null and voids all the cases using it.

Maybe?

Everything else is guessing but you should post some code to show your use case like everyone else has.

Link to post
Share on other sites

The usage of the word "Prototype" was careless.  Use "Datatype" instead.

If you mean changing the data carried on the strictly-typed wire attached to the left-hand side of the event structure, then the job queue for the event structure changes to whetever is contained there.  As expected really.  Jack Dunaway has an example of it in a link previously provided (not by me) in this thread (snippet provided below).

If you mean changing the TYPE of the wire, that's a silly question since that can't be done.  Doing that requires a recompile of the VI.

 

events.png

Link to post
Share on other sites
1 hour ago, shoneill said:

that's a silly question since that can't be done

It can be done but it:

On 02/03/2018 at 5:21 PM, ShaunR said:

null and voids all the cases using it.

because:

On 02/03/2018 at 5:21 PM, ShaunR said:

It is a design time, type, decision and can't be changed on the fly.

1 hour ago, shoneill said:

Doing that requires a recompile of the VI.

Indeed it does.

Edited by ShaunR
Link to post
Share on other sites

And this relates to your original code....... how?  You are NOT changing the datatype of your registration refnum, you are changing the data on the wire (which is the first of the two cases I mentioned in my previous post) and for which I posted a trivial example.

Link to post
Share on other sites
11 minutes ago, shoneill said:

And this relates to your original code....... how?  You are NOT changing the datatype of your registration refnum, you are changing the data on the wire (which is the first of the two cases I mentioned in my previous post) and for which I posted a trivial example.

It relates to drjdpowells comment:

On 02/03/2018 at 5:08 PM, drjdpowell said:

I see your point there; a "read only on first call" input makes sense.   Unfortunately, it doesn't just read the input on first call, and there are use cases (though perhaps rare) where one might feed in different refnums on each iteration.   If you look at the example I posted, the input tunnel to the loop actually changes what it outputs, which breaks the dataflow rules.

Which I later went on to say:

On 03/03/2018 at 10:34 PM, ShaunR said:

Ahh. You are talking about panel/control/user refnums contained within an event ref? Yes they are. That still works as expected <2017 - either before the structure or inside it. There was no bug here to prevent this use case.

There was confusion between "refnums". I took it to mean the event "prototype" refnum (since that was my first example use case) and he was talking about contained renums. What I said was not "rubbish", though.

Edited by ShaunR
Link to post
Share on other sites

The code I posted illustrates why a "read only on first call" cannot work.

If what you said is not rubbish, then more clarification is needed because by my understanding it is.  You can change the protoype refnum for another of the same type no problem.  You can bait and switch to your heart's content.  Hence my insistance on differentiating between the data contained within the Refnum and the Type fo the refnum.  One is possible to switch (without invalidating anything), the other isn't.  Of course you can't change it for a refnum of a DIFFERENT type, that's a design time decision.

The code I posted swaps out the refnum for another, but of the same datatype and therefore there's no invalidation at all.

Link to post
Share on other sites
8 hours ago, shoneill said:

The code I posted illustrates why a "read only on first call" cannot work.

I don't think it is a "read only on first call" and I never said as such. I intuited that it may be as described in the DVR example and was "a feedback node/shift register that was "initialised on first call". That was my observation of its behaviour and I wrote code around that. It obviously does work because your example taken from jacks stuff was written way before 2017 (2015, in fact) and before the change in behaviour and my examples show that it also works as expected when registering and re-registering in pre 2017 versions.

I think you have just miss-interpreted what I said and then proceeded to jump up and down about the semantic meanings. I have been very clear, with examples, of what the issue is; what the change has been, and we have all discussed various work-arounds and alternatives. I may be a lone voice in thinking that it is unacceptable to change a behaviour that worked fine (as far as I could tell) for a decade but then I have to rewrite code, so it's understandable.

Link to post
Share on other sites
  • I never claimed you said that.  But it was said.  The code I posted illustrates why the proposed operation is incorrect. Jack's code only serves to illustrate why your intuiting which led to your original code was flawed.
  • I don't think I've misinterpreted anything. I understand the original code, the changes and the workarounds. The workaround is to better understand the issue and code appropriately.
  • Regarding not wanting code to change and the plea to Linus' authority: Taken at face value, Linus' comment would preclude the closing of any security flaw which has ever been exploited. Yes, obviously Linus is claiming that Spectre and such should be maintained indefinitely as some may be using it.  :wacko:
Link to post
Share on other sites
4 hours ago, shoneill said:

I never claimed you said that.  But it was said.

Perhaps you should direct your comments to them instead.

4 hours ago, shoneill said:

I don't think I've misinterpreted anything. I understand the original code, the changes and the workarounds. The workaround is to better understand the issue and code appropriately.

I also never said you misrepresented anything. I  said you misinterpreted what I said.

4 hours ago, shoneill said:

Regarding not wanting code to change and the plea to Linus' authority: Taken at face value, Linus' comment would preclude the closing of any security flaw which has ever been exploited. Yes, obviously Linus is claiming that Spectre and such should be maintained indefinitely as some may be using it.

It's not a plea to authority. It is just a better oration of my own view with a preceding explanation as to the reasoning so that I don't have to write pages and pages. Your straw man argument doesn't help your case in this context.

There is little point in continuing this branch of the conversation as it has just become me defending against unfounded accusations and that doesn't impart any useful information about the issue to anyone.

If you have more technical input, then by all means please do.

Edited by ShaunR
Link to post
Share on other sites

All of my input has been technical. The information you seek is all in this thread if you care to find it.

23 minutes ago, ShaunR said:

I also never said you misrepresented anything. I  said you misinterpreted what I said.

I also never used the word "misrepresent", so I'm unaware what you're referring to here. Is this supposed to be a joke regarding misinterpreting my misinterpret?

24 minutes ago, ShaunR said:

It's not a plea to authority. It is just a better oration of my own view with a preceding explanation as to the reasoning so that I don't have to write pages and pages. Your straw man argument doesn't help your case in this context.

I disagree re. the plea to authority.  Plus, I'm fully aware of the ridculousness of the logical extension of what Linus said when context is ignored. Note the smiley.

26 minutes ago, ShaunR said:

There is little point in continuing this branch of the conversation as it has just become me defending against unfounded accusations and that doesn't impart any useful information about the issue to anyone.

If you have more technical input, then by all means please do.

Well, for yourself perhaps but others read these threads also so even if you stoicly refuse to listen to any relevant technical details (or god forbid, other opinions), others may be able to incorporate the technical details of the discussion to help form their own opinions.

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.