Error deploying UDP Channel Streaming Session

[dkelley]

All,

I'm suddenly running into an unexplained error when attempting to deploy a UDP streaming session to my veristand system. When attempting to deploy I get the attached message with an error code of -307652. According to http://zone.ni.com/reference/en-XX/help/372846A-01/veristand/vs_error_codes/ all that means is that it failed to open a connection, which is apparent... I'm completely stumped. Obviously the message isn't telling me much but to turn on more detailed explainations but I have absolutely no idea how to go about doing that. This message just popped up yesterday after the system worked fine the day before. No "code" related to the UDP system changed inbetween usages and UDP streaming had been fully functional prior to this problem. I know I have a connection through to my veristand system because command transmission works just fine (I can actuate things), but I have no idea what causes this type of error or how to go about fixing it. I've already gone through the unbelievably painful process of reinstalling EVERYTHING (Veristand, Labview, all associated device drivers and .NET) but that proved unsuccessful. 

Any and all suggestions would be appreciated.

-Drew

[Andy-C]

Hi Drew,

That does indeed sound like odd behavior. I assume you are programmatically deploying your System Definition through LabVIEW? 

That error indicates in general that the LabVIEW call is unable to communicate with the VeriStand Gateway. From your description it sounds like the rest of your NI VeriStand API calls are executing successfully in LabVIEW. Can you confirm that deployment/other API functionality is working as you expect?

For whatever reason the API is either unable to locate the VeriStand.exe process or is unable to connect to the .exe at run-time. Is there a chance your code may be making other API calls simultaneously? I found a few older bug reports that included references to this error occurring when a few different API calls were made in quick succession. Perhaps adding a delay might reveal something? That still doesn't explain why the problem started occurring in the first place, but I think it's a good place to start.

Let us know!

Andy

[dkelley]

Hi Andy,

so in brief, yes my other LabVIEW calls to the Veristand gateway are working just fine. I am actually deploying the system through Veristand itself, not from a LabVIEW system remotely in most situations. I have however, put together a quick little remote deployment setup that does manage to deploy 100% successfully. Additionally, I am perfectly capable of sending other commands through to Veristand from the LabVIEW system. So yes, things like SetChannel and the various StimulusProfile API sections that I'm using are 100% ok. It's just the UDPChannelStreaming calls that are throwing any kind of error.

To answer your second question, I've made sure to disable any other calls to the API when trying the deployment and am experiencing the same problem. To verify this, I actually started up a Wireshark packet capture and there is no communication between my LabVIEW system and the Veristand gateway after initial connection until I send a command or attempt to deploy the UDP stream. Additionally, I was able to see the error message coming from the Gateway to LabVIEW in a TCP packet so I know the issue is on the Veristand side, not the LabVIEW side (see attached screen grab), which I really already knew, but it helps to verify.

This really sounds to me like a network issue but I've verified that our firewall allows any and all communication from a computer on the LAN to any and all other machines on the LAN to pass untouched, and everything else on our LAN is unmagaged so there is no reason we would suddenly have troubled with a UDP multicast from a network perspective. 

-Drew

[thumble]

Hi,

If I'am right (but I'am not sure) it's a WCF error that means an exception was thrown during execution of a request on the server side (so in Gateway code). Because it seems that restaring the server does not solve and if you cannot identify the trigger of the appearance of the error, you could try to enable the "include exception details" (as mentioned in the error message) in a net.config file. The file was previously located at "...\ProgramData\National Instruments\NI VeriStand 20xx\NIVeristandService.xml" but for the latest versions it may have been moved.

[dkelley]

Thanks for the lead Thumble.

Unfortunately I am by no means fluent in .NET and am having a hard time figuring out exactly how to enabled the IncludeExceptionDetailsInFaults property as described. For instance, looking at a .NET documentation example here, I dont know how that translates into what is included in the .xml file I have (it was loc. For starters, the .NET documentation calls out files named with .config extensions where this file is a .xml. Do they serve the same purpose? They seem to be completely different kinds of files - though that is likely my ignorance talking. Any tips on how exactly to either turn on the IncludeExceptions property in this file or activate the .NET tracing features for Veristand? 

[thumble]

Re,

Unfortunately I’m not a specialist, but since the Gateway lays over the WFC I think there is a mean to parameterize some options from a net.config file. But to know what file and what section is a different story. Maybe some system guy from VeriStand could help more?

[dkelley]

Yeah I've got a support ticket going but haven't heard back yet. I figured I'd pursue two avenues: NI Support and on here until I got a solution. Thanks for the assist though! I'll let you all know what I hear back from Support. 

Any other suggestions are welcome!

[Layke1123]

Hey Thumble.

I am a fellow coworker of dkelly's.  I took a quick crack at changing the configuration for veristand to trace errors generated by veristand using the Microsoft SVC Config Editor, and managed to trace the error to a LabVIEW Veristand API called "NationalInstruments.VeriStand.ClientAPI.ClientWCFBase`1.Finalize()" which eventually tries to use a Pipe Connection (MSDN Server stuff) to write stuff, which is what causes an exception to be thrown.

I'm assuming that this could be the result of an error in state between our server and client, but I am unsure of the proper methodolgy when working with the Veristand UDP Channel APIs.  An example would be great which utilizes these VIs, but I can't seem to find a good one.  Anyways, I'm off to something else, just thought I would add what I found to the discussion in the attempts it helps anything.

Thanks!

[Layke1123]

Problem solved by dkelly.  Apparently it was just a simple deletion of one of our channels from our config files.  It would have been more helpful to have a more descriptive error than "something went wrong with the server", but at least the issue is resolved.  Thanks for the help guys.

[Jarrod_S.]

Thanks for the update. Can you tell me what version of VeriStand you were running? We can check into that error handling.