LabVIEW Channel Wires
Could Not Create The Requested Channel Endpoint
So I found LabVIEW 2016 on NI's public FTP site and installed it. I haven't seen a public announcement yet but figured if it is there then it is probably okay to install.
And I created a few channel wires just learning about the different types, but when I went to create a Messenger Write Ack on a Variant constant I got this error dialog error code 1055. After playing around with it a bit I now realize that an Ack is going to go along on a different channel. What I was expecting is the Messenger Write would just perform the write with the data type specified, and it would sit there and wait for the Ack which would be generated when the Messenger Read took place. It might just be my lack of understanding on how that channel was intended to work, but it was confusing seeing the error for not being able to generate a VI because of the data type, when the data type isn't used in that channel.
Brian Hoover wrote:
So I found LabVIEW 2016 on NI's public FTP site and installed it. I haven't seen a public announcement yet but figured if it is there then it is probably okay to install.
I bet that disappeared faster than the Jakobshavn Isbræ glacier.... I don't think it is released until after the first day of NI Week!
I spent most of my time with the stream channels instead of the message channels so I am not sure how this Ack feature is supposed to work. I think that the actual shipping version will have a bunch of examples to clarify.
I didn't go searching for it very hard, I just took the link to the 2015 download, and changed the name to 2016 and there it was. The downloader was put on FTP July 11th, but the actual image of 2016 looks like it was put up there on June 29th!
Anyway yeah the Ack appears to be a special channel that you give the ID of a stream and then wait on the confirmation from the writeing of the Ack. As a result the data type can't change, and it is always the data type of the ID which is probably an I32.
There are a few good examples, but none that I saw mention the Ack functionality, even the Messenger one just shows how it works with a mouse tracking example.
Does the ACK need to be actived on the receiver side with explicit code or is automatically generated when the channel read is executed and the data made availalbe. It depends on how bullet proof you want to make the communication by hash checking etc. and not merely dequeing the data in the channel. There is an arguement to be made for each version.
My testing was with an earlier version and since the Mac version is not posted for a variety of reasons on any site, I usually have to beg a special favor to get the downloads.
The channels in 2015 were hidden and an interesting first shot at things. In the beta (I think I can use that word here??) they were developed fairly well but a lot of changes, fixes and features changed during the course of the beta. But certainly here is a a great place to suggest examples showing the ACK feature should be included in version 16.0.1.
I was part of the 2016 beta, I did play with the channels, but I can't remember if I tried making an Ack message, or even if they were part of the beta I participated in.
I'm not quite certain how the ack is supposed to work, but I got it to work using two streams, one to send the data, and one using the message Ack, but I get the feeling it should be built in some how, since the writer has a Wait on Ack input but I couldn't get it to work right.
sth wrote:
My testing was with an earlier version and since the Mac version is not posted for a variety of reasons on any site, I usually have to beg a special favor to get the downloads.
I realize for the Mac that the evaluation version is different, but I did find download links to the Mac 2016 also on the FTP site.
