Could Not Create The Requested Channel Endpoint

[AristosQueue (NI)]

The files are always public a bit early as we deploy out to various sales teams around the world (and we do it through what will be the public channels in order to test that the public channels actually are working). We just don't talk about it and, officially, we're still in a window when we could yank the image back if something really egregious was discovered. So you've downloaded what should be the final, but there is that ever-so-small chance it isn't.

[sth]

Brian,

I tried to load your snippet but it completley hangs my evaluation version of LV.  Just the SPOD (Spinning Pizza Wheel of Death) for LabVIEW until I force quit it!  Almost something egregiously wrong! 🙂  I tried removing all my channels from the LabVIEW Data folder but it hangs at the same place.

I just dragged the snippet onto an empty block diagram.  It seems to be blocking on loading a channel class that it just created.  This is the 2016 evaluation version of LV for Mac OS X.

[Hooovahh]

Thanks AQ, I think I did find the example you were referring to, and think I understand it.  It seems you can do this with just one stream, but you need to call the read twice, once to get the actual data, and then a second time to perform the Ack.  This is in the Channel Message Handler example by the way.

Is it possible to get the ID from the read, from any method other than to have your payload be a class that inherits from the messenger class?  If not I have a suggestion that ID be returned by the Messenger Read.  Or a function on the channel wire that maybe returns more detailed information about the channel wire.  Conceptually I just realize if you are going to wait on an Ack you need to have that ID available where you do the read, and at the moment it is obvious how to wait on an Ack on the write, but it isn't obvious how to confirm that Ack on the read.

[Hooovahh]

So there are multiple new things that might be preventing this from working.  First I thought the forum changes could be breaking snippets but I was able to get it back.  Then I remembered I made the snippet with the code capture tool, which predates channels so that could be a complication.  Then there is the fact that LabVIEW isn't really out yet, and as AQ mentioned we could be discovering some major issue.  In any case attached is a snippet made by LabVIEW not the CCT, and I've attached the VI itself, I'd be curious if either of these work.

[sth]

Thanks!  Both of those work so it may be something with the CCT.  The only weirdness is that the "Evaluation" watermark gets duplicated all over the screen as you move the snippet around.  It cleans up when resizing the window and is just a cosmetic screw up that I can live with.

So now I can actually play with the code!  Later...

-Scott

[AristosQueue (NI)]

Hm... I tried a couple variations... it looks like for some reason the Messenger channel is fighting with the VI Snippets. At least a couple other channels seem to work fine.

What will really toast your noodle: Drag the snippet, wait for the spinning wheel of death, kill LV, relaunch, drag the picture again. This time it works.

CAR! STAT! 🙂

[AristosQueue (NI)]

Note: This issue is not large enough to pull back the release image, not by a long shot. At this point, we would pull back for CARs such as:

• * DAQ driver doesn't work with LabVIEW! (hypothetical)
• * Install image has a virus embedded in it that we are distributing to all users! (actually happend 15 years ago. NI got infected with some malware that made its way onto the install disks)

That's the level of Bad we would need to pull back.

We would not pull back for "Customer reports LabVIEW has taken over the lab, is holding data hostage, and is threatening to download into human brains if someone doesn't get it more CPUs and a phat network pipe soon." That's just our new viral marketing campaign, stage 1. 🙂

[sth]

No, I didn't think it was that egregious, but I was yanking your (NI's?) chain.  This no where rises to the level of an unusable release.  For me, it still hung on the second and third tries for opening the original snippet.  Since it is not the "official" snippet that caused the issue but rather the CCT functionality is is even lower priority as far as I am concerned.  The official snippet opened on the first try, but I may not have reset all my channel generation files before that try.

Apologies again for the bad joke, but do you want me to file the CAR?  It is a bit tricky on an unreleased evaluation product... 🙂

[Bob_Schor]

Brian,

     I looked at your Ack Test, and all I can say is ... Ack!  I tried it, couldn't figure out what it should be doing, and when I tried to follow it using Highlight Execution, I managed (I think) to set up a Deadlock.

     Myself, I'm rather fond of Abort, so I tried (without any delays or timeouts) to set up "one number per push of the Write button, and Stop stops everything", with the goal of a single Channel wire.  Here's what I tried (and it seems to work):

Bob Schor (see you next week ...)

[AristosQueue (NI)]

General rule applies: If you ever have two channels going the same direction between the same two loops, you probably have a race condition or deadlock bug lurking. You can have one channel communicating A to B and a second channel communicating B to A, but duplicate either of those and there's probably a bug. This is one of the nice aspects of making the communication visual ...