Search the Community

How do you decode, unpack a flattened string in python which was sent by a LabVIEW TCP server? I want to exchange data via loopback. Therefore I take a sine wave and flatten it to string and sent over the network Simple TCP - ServerSINE.viSimple TCP - ServerSINE.vi. Then I have to decode the incoming data in a way that I have the correct numerical values like when I plot them in LabVIEW. I did this so far in python_client.py but the values are wrong. Does anyone know how to work with the transferred Data in python?

Hello, Could you please share your thoughts about problem shown below? Thanks in advance. Software used: LabVIEW 2013 f2, 32 bit DSC 2013 Problem: When trying to read a value of tag from third party OPC server which is not widespread software using NI DSC OPC client we got empty data. The type of tag in OPC server is Array of U16 and OPC server continuously writes array of values into that tag. However, NI DSC OPC client (and Distributed Systems Manager as well) defines type of that tag as String, thus can not read value of that tag (I suppose that NI OPC client is trying to treat variant data which holds array of U16 as string and because of conversation error issues empty data). At the same time Kepware’s OPC client defines type of that tag as a String as well, but can read the values of that tag which holds Array of U16 (I suppose that Kepware’s OPC client after getting error, while converting Array of U16 into String, starts to look in datatype defined into variant itself). Questions: Can the descriptions above explain the problem and if yes then what can we do to read the value of tag with DSC? Is there any opportunity to get more deep access to NI DSC OPC client to make some changes in order to work with customer OPC Server?

I need to find a transport for message objects that allows two way communication without polling but is limited to server side connections only. So, the client can connect to the server but the server cannot connect to the client. First some context: My application communicates over the network using VI Server. My client app (the UI) opens a ref to a VI in my server app (the engine) and sends a message object containing the client app’s machine name and VI server port. The server app then opens a ref to a VI in my client and sends a message object with the reply data. I now have a two way communication channel via VI server and can pass any message object back and forth without polling. I learned today that our IT department plans to block all incoming connections to all non-server machines in the future. So, my client would still be able to connect to the server app within the network, but the server would not be able to connect to the client app because of this rule. This will completely break my networked messaging system. I do not know a way for LabVIEW to setup VI Server so only one end can connect to the other but allow two way communication without polling. Does anyone use a message system that would work in my situation? I would prefer to continue to use VI Server but I am willing to look at other solutions, as long as they were very robust and had low latency. thanks in advance for you help. -John

Hi everyone, I'm wanting to open up the floor for your opinions and past experiences with designing a network communications architecture. - There will be one server, written in LabVIEW on a Windows based PC. - There will be multiple remote clients programmed in LabVIEW on cRIOs. - All devices will be connected via a wireless network, and all cRIO clients should have good throughput to the server. - It should be designed for bidirectional data flow, however the clients will do most of the talking. - Data sent will be, status packets, images, PDF documents, and other information. - Clients will not be continuously sending data, such as a typical DAQ system, but more reporting on events. I'm leaning towards the TCP socket option, but would like to consider higher-level forms of NI-propriety designs, such as Network Shared Variables or Network Streams, which I haven't had huge amounts of exposure to. Thanks for your opinions. Brenton

I am trying to use the HTTP Client VIs to implement a version of the C# code found HERE. Unfortunately there are no NI examples of how the client VIs are to be used and my various attempts to string them together only seem to result in "Error 42" (LabVIEW: Generic Error) from the POST vi, rather than returning the headers and body text. I have also tried using DOTNET calls and was at least able to get the login page returned but could not seem to trigger the login. I switched to the HTTP Client VIs because they offered an alternate hope and I could at least see where to attach a cookie file with them (though a cookie file may not be the same as reserving space for a session cookie). Any guidance would be appreciated!