How can I transfer the Qt Signal Data to 3rd party Software Such as Labview?

Yash001

@dheerendra Let me try. Thank you for Direction.

JKSH

@Yash001 said in How can I transfer the Qt Signal Data to 3rd party Software Such as Labview?:

what is good way to transfer the Data to other Application from Qt... Qt dll is generate the datasignal. I would like to connect that data siganl to Labview Application.

What type of data is it? How fast is the data being generated?

My application is Created in Qt. I am gone use the Qt dll in Labview Application.

...

I need to call the some function through CLF

"CLF" is Call Library Function node. You can only use CLF on a Qt library (.dll); you cannot use CLF on a Qt application (.exe).

I may transfer the Data Signal value outside Qt-application through TCP/IP. or Is it better way to transfer data from Qt application to Labview Application GUI?

Choose either TCP/IP or CLF. Don't mix both.

For beginners, it is much easier to use TCP/IP than CLF.

With TCP/IP, you can create a regular Qt application (.exe) and communicate with LabVIEW. You don't need to use CLF to transfer anything -- just use a fixed TCP port.

Yash001

@JKSH Thank you so much for exact information . I know CLF is only used for calling Library (.dll).

" What type of data is it? How fast is the data being generated? "

data is received in Qt dll through COM port. After that, i am doing manipulation on received data, and generate few readable value (double) (10 - 15 value). I wanted to represent readable value on Labview GUI.

I am receiving data through COM port on bud-rate 57600.

#include "Config.h"

qint32 DefaultSerialPortSettings::Baudrate() {
	return QSerialPort::Baud57600;
}
QSerialPort::DataBits DefaultSerialPortSettings::DataBits() {
	return QSerialPort::Data8;
}
QSerialPort::FlowControl DefaultSerialPortSettings::FlowControl() {
	return QSerialPort::NoFlowControl;
}
QSerialPort::Parity DefaultSerialPortSettings::Parity() {
	return QSerialPort::NoParity;
}
QSerialPort::StopBits DefaultSerialPortSettings::StopBits() {
	return QSerialPort::OneStop;
}

JonB

@Yash001
I don't get it. You say your "application" will be a DLL file, and it will be included into a LabVIEW application. So where is any TCP/IP going to be? That's for communicating with another process.

If you're really producing a DLL which is directly accessible from a LabVIEW app, you'll just be in @dheerendra 's situation:

You have no option other directly calling method in dll and get some return values from methods in dll.

Yash001

@JonB

Current Our GUI

Currently, I have application, which is created in Qt and C++. I am creating my application by just create the Object of Mainwidnow Class in main() function.

constructor of Mainwindow class is handle the remaining things. Such as create the serial thread, start Serial thread, create the GUI, connecting signals and slots, etc. Basically you can say it is initialized State.

on closing of Application, ~Mainwidnow() will release all the resource, and stop serial thread.

whenever the device is connected on COM port that time it is detected on serial thread and inform to GUI about new Device Connection.

On receiving data from the COM Port, serial thread will receive the data and and decode it. After that, Decode data is making Readable by many calculation.

Then readable data is display on GUI.

For Labview Software.

I copy whole project.
I remove the GUI Stuff from the code, and add functionality of TCP/IP (client). then I create the .dllfile instead of .exe . (Qt Library side)
I will create TCP/IP (server) on labview side.
I also remove the main() function while creating Qt Library (.dll). I am creating instance of MainWindow class by calling CLF node, from Labview.
Now constructor of Mainwindow is handling Serial thread, connecting to TCP client to TCP server, connecting to qt Signals.
depending on User Interface on Labview, I will send command through TCP/IP from Labviw to DLL.
Now if any raw data receive from the COM Port, then dll will make it readable data, and send back to Labview through TCP/IP.

By creating .dll instead of .exe, User will handle application completely in Labview.

I think advantage of TCP/IP is I am able to display real time value on Labview Application.

Thank you,

JKSH

@Yash001 said in How can I transfer the Qt Signal Data to 3rd party Software Such as Labview?:

data is received in Qt dll through COM port. After that, i am doing manipulation on received data, and generate few readable value (double) (10 - 15 value). I wanted to represent readable value on Labview GUI.

I am receiving data through COM port on bud-rate 57600.

I meant: How many "packets" do you receive though the COM port each second? How many doubles do you generate each second?

The baud rate itself doesn't give us much useful information.

For Labview Software.

I copy whole project.

I remove the GUI Stuff from the code, and add functionality of TCP/IP (client). then I create the .dllfile instead of .exe . (Qt Library side)

I will create TCP/IP (server) on labview side.

I also remove the main() function while creating Qt Library (.dll). I am creating instance of MainWindow class by calling CLF node, from Labview.

Now constructor of Mainwindow is handling Serial thread, connecting to TCP client to TCP server, connecting to qt Signals.

depending on User Interface on Labview, I will send command through TCP/IP from Labviw to DLL.

Now if any raw data receive from the COM Port, then dll will make it readable data, and send back to Labview through TCP/IP.

By creating .dll instead of .exe, User will handle application completely in Labview.

This can work, but you must bear in mind:

To use QTcpClient and QSerialPort, you need a "running" QCoreApplication (this means you need to call exec()). exec() blocks permanently, which means that the VI that calls the CLF node will also run permanently (until you tell QCoreApplication to quit).
You must not run your QCoreApplication in LabVIEW's UI thread, or else LabVIEW might hang. You must run it in a secondary thread.

I think advantage of TCP/IP is I am able to display real time value on Labview Application.

There are other ways to send real-time data from your DLL to LabVIEW (such as posting a LabVIEW User Event from C++). However, TCP/IP is much easier.

JonB

@Yash001
You obviously know what you are doing. I find it pretty weird that you will be creating a DLL which runs inside LabVIEW, yet you will be communicating with LabVIEW (i.e. the same process) via TCP/IP, which 99.9% of the time is for communicating across/between different processes, whereas you have both client & server being the same process. But there you are....

JKSH

@JonB said in How can I transfer the Qt Signal Data to 3rd party Software Such as Labview?:

I find it pretty weird that you will be creating a DLL which runs inside LabVIEW, yet you will be communicating with LabVIEW (i.e. the same process) via TCP/IP

I understand the weirdness, but it has its benefits. For one thing, it allows the C++ code to remain relatively simple and self-contained.

One big barrier in LabVIEW-C++ interop is that LabVIEW is implicitly multithreaded -- When you make a function call in LabVIEW, you don't really know which thread runs the function. The only way to force a specific thread is if you tell LabVIEW to call the DLL from the UI thread. However, since QCoreApplication::exec() is blocking, this will freeze the LabVIEW UI so it's not an option.

Long story short, you need some gross wrapper code to drive Qt from LabVIEW: https://github.com/JKSH/LQWidgets/blob/master/src/Cpp/lqlibinterface.cpp

Yash001

@JKSH said in How can I transfer the Qt Signal Data to 3rd party Software Such as Labview?:

How many "packets" do you receive though the COM port each second? How many doubles do you generate each second?

I am receiving near about 800 packet at com port. I am generating near about 20 - 30 double value.

To use QTcpClient and QSerialPort, you need a "running" QCoreApplication (this means you need to call exec()). exec() blocks permanently, which means that the VI that calls the CLF node will also run permanently (until you tell QCoreApplication to quit).
You must not run your QCoreApplication in LabVIEW's UI thread, or else LabVIEW might hang. You must run it in a secondary thread.

Thank you for pointing about exec() and thread.

SGaist

Hi,

Out of curiosity, why not use Labview's serial port support ?

Yash001

@SGaist I am not using Labview's serial port directly because of my code contain many background functionalities. It will take time to implement all in Labview. We want to just give readable data and few User interface to Labview. So user can directly use readable value and interface in Labview.