tcp/ip help communication

[bleite]

Hi everyone.

I started a new VI on LabVIEW 2021 to communicate, about tcp/ip, with a led display like a billboard as image below.

I get a communication as TCP/IP through the manufacturer software, but i didn't know what is the package i need to send, the full package.

This led display it's a simple command use, with there software (above) or bluetooth in cell phone,  but, to communicate for TCP/IP, they install a conversor, the USR-TCP232-T2 module, as image below

The image bellow, I show the simple program im LabVIEW to command this led display but the main question is: whats is the kind of package i need send to show the message or change the configuration of the display.

 

 

In attached, we can see the datasheet that manufacturer send us about this led display and the package to send, but i did'nt undestand how to do 😕 
It's my first time to work with TCP/IP on LabVIEW 

 

Something like this:

[billko]

If you're just new to LabVIEW but familiar with communication protocols, try to think about how you would go about doing in a language you are familiar with, then tell us how you would do it in that language, then we can help you translate to LabVIEW.  (HINT: You can't just send the text by itself, you need to send it in the format specified in the documentation.)

If you are also unfamiliar with communication protocols, then that's one more thing we need to go over.  Don't be afraid to tell us you have no experience with that, either.  We are very happy to help you; we just need to know how much help you need.  🙂

[bleite]

So, this is what I'm wanting to know.

I don't know how to transform this datasheet data into valid data to send via TCP/IP

I don't kwon pass of this:

To something like this:

[Kyle97330]

I can't read the Portuguese documentation but I can see they use TCP/IP port 502, which is usually MODBUS protocol.

LabVIEW has at least 3 MODBUS libraries available, you could look into trying one of them.  

[altenbach]

In addition, your serial to ethernet converter probably just translates the payload into serial, so it should not matter if you use TCP or UDP (both are part of TCP/IP, but you probably know that!). Since you are just fire off commands and not trying to read responses or keep connections open, it seems much more reasonable to use UDP instead. Much more lightweight. See section 4.1.4 in the manual of your dongle.

[bleite]

I discovered something that help too much.

I used an emulator to receive the data from manufacturer software, to see how is the data that the software send.

The data is show bellow:

01 02 04 01 46 45 43 48 41 4D 45 4E 54 4F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 03 06 00 00 06 06 06 00 00 00 00 00 00 00 00 00 00 00 01 FF

I need necessarily send 135 package of data. The last one (FF) is to end of the package of data.

the first four data (01 02 04 01) never will be change. 

the next data, is the message i need to show on the led display following an ASCII table, e.g.:

46 45 43 48 41 4D 45 4E 54 4F

F   E   C  H   A   M  E   N   T   O

The other data is not important for now.

After that, on LabVIEW, I created a code to concat all this data to send to TCP/IP, but this data is not equal the above, see bellow:

This string output is 4 number (4 digits), diferente of is sended from manufacturer software, that is 2 digits.

Now the question is: How can I send equal the manufacturer software?

[altenbach]

You can create a string diagram constant, set the display to hex format, and type whatever you want in it. That single string constant would replace your entire in that gigantic Rube Goldberg case structure content!

You need to attach your VI, because we cannot tell most important things from a picture. As a first step, make sure to show the display style! To replace relevant parts with real data, just a little bit more code is needed.

Byte manipulations are a core skill of any programmer and this is a trivial scenario. You simply need to learn a little bit more.

I am not going to squint for hours to see which four bytes are different. Can you point them out?

I would recommend to have a U8 array of the correct length where you would replace elements/subsets according to the desired data, then cast it to a string before sending. Where do you calculate the checksum?

[Yamaeda]

---

@altenbach wrote:

I am not going to squint for hours to see which four bytes are different. Can you point them out?

---

I would assume they're ALL different as there's a 96.5% chance it's normal string constants instead of hex ones. 🙂

[bleite · Accepted solution]

I finished this project with successfully. See below.

This first image, when you press the button, erase all message on led display:

In the second photo, we can send to the led display, de message "INFUSAO" like a HEX code, the display receive the message and show there:

I take off this part of VI code because this part is waiting a reply from the Led Display (TCP/IP read) and, with then, the VI is stopping per 20 seconds and this is not so good

It's better if I post/attache here a video of the functionality of this system?

[Mark_Yedinak]

---

@altenbach wrote:

In addition, your serial to ethernet converter probably just translates the payload into serial, so it should not matter if you use TCP or UDP (both are part of TCP/IP, but you probably know that!). Since you are just fire off commands and not trying to read responses or keep connections open, it seems much more reasonable to use UDP instead. Much more lightweight. See section 4.1.4 in the manual of your dongle.

---

Just to nitpick, TCP and UDP are not both part of TCP/IP. They are both IP protocols but TCP/IP is only TCP. An application protocol can generally be sent over both TCP or UDP but most applications only support a single protocol (TCP or UDP) for a given application layer protocol.