Notifier signals missed

[Mellroth]

...there could be a right-click-menu option that would change the behaviour of the node...

I rather have an additional input, because this is easier to spot on the block diagram.

Regarding the question of the default behaviour; I'm usually not that found of changing a default behaviour since old time users wont read the help, but use the node directly (I really hate how NI changed the default behaviour on some of the file VIs, e.g. convert EOL is now default).

But, in this case I can agree that it seems like the way to go since we are speaking of something that is "very" close to a bug.

I also did a quick check on some of my old projects, and I can not see that any of these should have any problem with this new behaviour.

/J

[Aristos Queue]

With W4N node it is possible to connect incompatible wire to the node as the developer gets no warning when he connects different notifiers to the same node.

I don't understand what you mean here... the notifiers have a well defined subtype. You can't attach two different type of notifiers to the same node simultaneously, since there's only one input. When I hook up a notifier of int32s to the W4N prim, then the terminals are int32 type. If I delete that wire and hook up a notifier of strings, the terminals are string type. If I create a subVI that takes a notifier of int32 as input, I cannot wire any other type of notifier to that terminal. Only a notifier of int32 will connect. I can't bundle different types of notifiers together in an array.

(putting mouse cursor on other side of the Red X on broken wire shows details of the other type -- a notifier of int32)

You've got a lot of good ideas, Jimi, but I can't even begin to imagine what you're referring to on this one. Safe mode???

Oh, and as for the "new prim vs added terminal" -- I thought about it some more. Adding a terminal wouldn't work -- this is behavior you'd have to pick at compile time and not have changing at run time. If you put one of these nodes in a loop and on the first few calls said "don't remember every refnum's history" and then changed it for later iterations to "remember every refnum history", there'd be no way to reconstruct the data of previous calls except by having stored it even though it wasn't being used (big performance hit). It would get messy. So I think that adding a new prim entirely would be the way to go (not that I'm planning on getting to this any time soon, let me remind you). We'd just have to make sure the new icon was distinctive. Other options would be a popup configuration (not something I like) or the terminal that requires that it be wired with a constant (which would be odd). There could be an on-diagram configuration [such as the polyVI selector ring] but that sort of thing cuts of access to the node's bottom terminals and takes more space on diagram.

[brian175]

EDIT: I tested that if I embed the W4N or W4MN call to reentrant VI everything works ok. However if I embed this reentrant VI into a dynamic method we end up into a hang again as expected. So if you have only one non-reentrant VI in your call chaing to W4MN or W4N then you have good chances of failing to catch a notifier. Bug or not? I modified my project to present this behaviour. The modified project is below.

Here's a workaround for this LabVIEW "feature" (until dynamic methods can also be reentrant). Force the "Wait for notification Dynamic.vi" method to use a unique copy of the "Wait for notification reentrant.vi" by instantiating it with the create notifier.

Brian

AQ - Here's a definite BUG, or perhaps it is the new fast shutdown :

0. SAVE and close anything important in LV 8.2!

1. Download zip _v3

2. Open New Notifier Problem.lvproj

3. Open Wait for notification Dynamic.vi

4. Wire the "Notifier Class out" output of the call by ref nod to the Notifier Class out (delete the existing wire first)

5. Notice the broken run arrow

6. Delete the wire just created

7. Rewire the input to the output

8. Instant off, do not pass go and do not collect $200

Download File:post-987-1163800435.zip

[LAVA 1.0 Content]

Here's a workaround for this LabVIEW "feature" (until dynamic methods can also be reentrant). Force the "Wait for notification Dynamic.vi" method to use a unique copy of the "Wait for notification reentrant.vi" by instantiating it with the create notifier.

Brian

Yes, this works. Although opening VI reference by VI path is a bit clumsy and of course very slow. I also suspect that there may be a LV 8.20 bug related to opening VI references to class methods using open VI reference and then calling then using call by reference node. Have you used this methods Brian? If you have, have you encountered mystic project corruption or LabVIEW crashes especially when using dynamically called VIs?

EDIT: Brian, it seems you were fast finding a bug You may have saved my day or really rest of the year. I've a project that probably corrupts because of this bug and I cannot submit the project to NI support as it contains confidental parts that are hard to isolate.

[LAVA 1.0 Content]

I got Brian's project to "vanish" (crash without error message) on Friday although I didn't follow Brians instructions. However today I cannot make it vanish even when I follow Brians instructions. Seems like a hard-to-find memory leak bug.

[brian175]

... Have you used this methods Brian? If you have, have you encountered mystic project corruption or LabVIEW crashes especially when using dynamically called VIs?

Yes and no, No I haven't used that method yet in LV 8.2, I'm just starting to look at OOP in LV 8.2. And yes, LabVIEW will crash if you call a dynamically referenced VI with the Call By Ref Node IF the connector pane that was used to open the VI ref doesn't match EXACTLY the actual connector pane of the VI being called.

I was actually interested in this topic since I have an idea for using Notifiers to keep the object wires synchronized using OOP in LV 8.2.

I got Brian's project to "vanish" (crash without error message) on Friday although I didn't follow Brians instructions. However today I cannot make it vanish even when I follow Brians instructions. Seems like a hard-to-find memory leak bug.

I can still recreate the CRASH everytime!

[LAVA 1.0 Content]

And yes, LabVIEW will crash if you call a dynamically referenced VI with the Call By Ref Node IF the connector pane that was used to open the VI ref doesn't match EXACTLY the actual connector pane of the VI being called.

I haven't experienced runtime crashes but rather weird crashes during development time and weird corruption of the project. Both of these occurred when I started using call by ref node with class methods. EDIT: I wonder if the connector pane constant doesn't get properly updated.

[Aristos Queue]

I haven't experienced runtime crashes but rather weird crashes during development time and weird corruption of the project. Both of these occurred when I started using call by ref node with class methods. EDIT: I wonder if the connector pane constant doesn't get properly updated.

I cannot replicate this. I've tried everything. I've followed instructions verbatim, I've tried variations, I've tried loading without the project, etc. No crashes when I delete - wire - delete - rewire.

[LAVA 1.0 Content]

I cannot replicate this. I've tried everything. I've followed instructions verbatim, I've tried variations, I've tried loading without the project, etc. No crashes when I delete - wire - delete - rewire.

I can now get it crash every time. Unzip. Make sure LabVIEW is not running? Double click on the project. Open Notifier class branch from the project explorer. Double Click Wait for Notification Dynamic.vi. Press Ctrl + E to show block diagram. Put your mouse cursor on the right half of the wire connecting Notifier Class in and Notifier Class out and wait for vanish... Brian, you are left handed, aren't you?

EDIT: Even easier method to get crash (LabVIEW vanishes). Make sure LabVIEW is not running. Double click "Wait for notification Dynamic.vi" from Windows explorer. Click ok for warnings. Front panel appears. Press Ctrl+E. Put your mouse cursor on the right half of the wire connecting Notifier Class in and Notifier Class out inside the case structure and wait for vanish... Does it work for anybody else? I shall call this vaporizer bug. (Vaporizer was used in Space Quest 3 to vaporize stuff, especially content of waste basket...)

[Yair]

I shall call this vaporizer bug. (Vaporizer was used in Space Quest 3 to vaporize stuff, especially content of waste basket...)

Wow, SQ3. I have practically zero memories from that one. I do remember the quasi-Windows-3.1 waste basket from SQ4, though (as well as most things from SQ1, 5 and 6).

Where would be without Sierra?

[crelf]

Even easier method to get crash (LabVIEW vanishes). Make sure LabVIEW is not running. Double click "Wait for notification Dynamic.vi" from Windows explorer. Click ok for warnings. Front panel appears. Press Ctrl+E. Put your mouse cursor on the right half of the wire connecting Notifier Class in and Notifier Class out inside the case structure and wait for vanish... Does it work for anybody else?

Confirmed - my LabVIEW vanished too...

[Aristos Queue]

Confirmed - my LabVIEW vanished too...

It does not replicate inside NI. Another of the LabVOOP team did get it to crash while he was on remote working in California, but cannot get it to replicate now that he's here at NI in Austin. I downloaded a fresh copy of your VIs from LAVA. I tried wiping out my .ini file. I've tried reinstalling my LV8.2 just to make sure I'm clean. I've tried another machine. Nada. I tried Brian's original instructions and Jimi's variations. Nada.

You guys are working in MSWindows right? This isn't a Linux or Mac bug that I'm hunting, right?

So at the moment, the best I can say is that when our developer gets back to California, I'll have him investigate this bug. And if it really does replicate when he gets back out to Calif, then I may just hang up my tools and find a new profession.

For what it's worth...

This was reported to R&D (# 43JCLR2K) for further investigation.

[brian175]

... Brian, you are left handed, aren't you?

No, right handed

I cannot replicate this. I've tried everything. I've followed instructions verbatim, I've tried variations, I've tried loading without the project, etc. No crashes when I delete - wire - delete - rewire.

Try this

1. Open New Notifier Problem.lvproj

2. Right click the Notifier Class.lvclass

3. Select New=>Dynamic VI

4. Switch to wiring tool (I have auto tool turned off)

5. Hover (or click) on object wire

6. Goodbye!

You guys are working in MSWindows right? This isn't a Linux or Mac bug that I'm hunting, right?

Right, Win XP Pro SP2

[LAVA 1.0 Content]

You guys are working in MSWindows right? This isn't a Linux or Mac bug that I'm hunting, right?

I can replicate it from my home computer, Windows XP Pro SP 2, AMD Athlon XP 3200+, 1GB mem, Radeon 9550, LV 8.20.

I cannot replicate it on my work laptop, Windows XP Pro SP 2, Intel Pentium M 1.6Ghz, 1GB mem, Mobility Radeon 9000, LV 8.20.

Both computers have LabVIEW 8.20 loaded from NI web site and installed using same serial number. Both computers have Windows XP installed from same installation media. Both computers have F-Secure Anti-Virus Client Security, although the version at my home computer is 6.01 and laptop 6.00. In both cases I extracted the Brian's ZIP on a New_Notifier_Problem_v3 folder at my Windows Desktop.

EDIT: The bug is INI file dependent, I copied my INI file to the other computer and it triggered the bug. I attatch the INI file that can trigger the bug. INI is in the attached ZIP.

Download File:post-4014-1164231624.zip

[crelf]

It does not replicate inside NI.

That's just downright freaky Maybe we all need the superspecialsecretNIinternalactivationnumber?

This was reported to R&D (# 43JCLR2K) for further investigation.

Are you sure you're hovering on the right part of the right wire?

[brian175]

Here is a version that Doesn't Crash for anyone following this topic and interested in using notifiers in objects

Download File:post-987-1164231546.zip

As for the crashing, I believe that the cause is the fact that the VI strict type def in the class data contains the current class object as an input and output. LabVOOP doesn't allow a class to include itself in it's data.

[LAVA 1.0 Content]

This was reported to R&D (# 43JCLR2K) for further investigation.

I've had troubles with the following kind of recursive call acrhitecture (see attachment). The class structure is of course much more comlicated and constantly changing. However, the problem seems to be realted to the addition of this kind of recursive call to the project. The project may get corrupted, LabVIEW may start behaving strangely by claming that there are unsaved changes in files that are just saved. There are crashes and freezees. And all this is very hard to replicate each time until the project already is somehow corrupted.

Aristos, should this structure work with LabVIEW or does your intuition tell that there is something wrong with this. I admit I do not close VI references but LabVIEW seem to close them as the VI exits, so it shouldn't case the problems...

Download File:post-4014-1164235857.zip

[robijn]

Getting back to the notifiers, I tuned in a little late, but I get the story. It is important to note that the problem only occurs with "dynamically" wired nodes. If you wire a single ref there's no problem. It's optimized for that and that should remain. But I would think a list per node, like JFM proposed will only improve the situation and have no bad consequences like breaking old code.

This discussion is important and it relates to very important general issues, namely code reuse and LabVIEW compile time safety mechanisms.

I think there is an issue in this discussion that nobody has yet mentioned. During the development time the developer doesn't know in which circumstances his/her module is used. Only in projects where there is only one developer, all the code reusage situations are somehow predictable. If the developer writes code that may be used by other as part of some software, notifiers are risky due to the possible program hang feature. So even though the notifiers function well in the case the uses them, the code reuse may lead to mysterious program hang in later times. Especially if one writes a library that may be used by third parties totally independet of the developer, one should not use notifiers due to the fact the library may mysteriously hang.

:thumbup: Indeed so ! You're very right here.

Then a second issue that is not discussed here yet. It's more general and not related to notifiers directly. I think one of the best features of LabVIEW is strong typing. I am not fan of variants, I'd prefer polymorphic types instead of variants. Strong typing guarantees that it is hard to create bugs as one cannot connect a wire of wrong type to the node.

Yes variants destroy the strict typing which is so important to build good programs. Theoretically it means you need to run the program for each and every possible situation and check that there is no variant converted back from an unexpected type - which is usually impossible to guarantee. That's why I would favor an "untyped" control, of which the type(s) will be determined when compiling. Stephen may remember a picture I sent in once... I will post more about it later.

Joris

[Aristos Queue]

This was reported to R&D (# 43JCLR2K) for further investigation.

Ye, gods, gentlemen!!! Close your Context Help window!

That's the crash. I reflexively close the Context Help. So when I tried to replicate what you were seeing, I never could.

The data type is recursive -- the class uses a VI reference that has the class on its own conpane. While this is perfectly acceptable from a data standpoint, when the CH tries to display the data type of the wire -- when you mouse over it -- it goes into infinite recursion and crashes.

[crelf]

Ye, gods, gentlemen!!! Close your Context Help window!

By Jove - he's got it! Hurrah and well done!!!

[Jim Kring]

There's an example program showing how to wait for ALL of a set of multiple notifiers at "<labview>\examples\general\WaitForAll.llb"

Stephen, there is a bug in "Wait for All Notifications" -- it should be reentrant. I've reported this here and here.

Thanks,

[Aristos Queue]

Wish granted in LV8.6: new notifier primitives.

Search in this document for

Advanced Notifier Waiting VIs and Functions

[Yair]

OK, so I didn't really read the entire thread, but I think maybe the documentation should be updated.

I wanted to have an array of "current values" updated from dynamically called VIs. I could have done it many ways, but I figured the quickest would be to create a notifier for each VI and go over those notifiers in a for loop with Ignore Previous set to F, like the attached example, right?

Well, no. It was wrong. As the help says, each node remembers the time of the last notification, and as Stephen said here, remembering a separate time for each reference is apparently not worth it. OK, since I'm using 8.6, I did a quick workaround by replacing the notifier with a lossy queue, which works fine, as can be seen in the example.

I have to say that it took me a while to figure it out, though. I think the help needs to be more explicit about how this specific case (iterating over notifiers) will not be handled as the user might expect.

P.S. I haven't looked closely at how the W4MN and the new notifier primitives are supposed to work, but a quick test seems to indicate that they do not do what I want.

[Aristos Queue]

QUOTE (Yair @ Dec 30 2008, 01:18 PM)

I have to say that it took me a while to figure it out, though. I think the help needs to be more explicit about how this specific case (iterating over notifiers) will not be handled as the user might expect.

Write up the exact documentation change you'd like to see. I'll ask the tech writers to review it and see if we agree.

[Yair]

Sorry, I made a mistake. I thought that a notifier which times out returns the latest notification, but it actually returns the default data for its data type. That means I couldn't have done what I wanted even with a single notifier.