moralyan

Oh, I don't know. Quite possible with Labview distributions

I was talking more in context with IEC61850 rather than the OPs requirement (but I can see that I wasn't clear on that). It seems, from a casual perusal ,that it (IEC61850) is targeting similar requirements to Ethercat (the 4ms deterministic messaging - Fast Transfer of events requirement for example). In this scenario, I can see UDP multicast being very useful.and much easier for a device to "register" for messaging or "listening" for status events rather than the controller opening specific connections (and the overheads in the controller associated with copying messages to multiple clients).

ShaunR, once again you show how smart you are Actually in IEC61850 GOOSE messages, we have a publisher/subscriber structure, similar to UDP multicast, however the messages are directly mapped to the physical layer (ethernet) without going through any underlying protocol, it is some sort of peer to peer communication. For this reason, GOOSE messages are so fast, even faster than the UDP. For our purpose, i spent the two previous days with labview ,and i ended up with an application that generates a 6% error in the received data, however, it looks like i have some luck, our goal is to send a TDMS file with UDP, and we are mainly interested with the values palette. the weird fact is that the error never occures at the level of the values, it just occures with the graph and some of the properties!!

Decided to Google IEC61850 and UDP. I found this interesting PowerPoint presentation in PDF form.

http://www.pes-psrc....%2002282012.pdf

I liked the next to the last slide best:

The author indicates that dropped messages are statistically insignificant. They were never able to eliminate them completely.

If you're just starting out with LabVIEW, this is going to take you some time, and I would wager that you will never achieve zero data loss using UDP.

Finally it seems like someone understands what is our focus from insisting on UDP, this is really encouraging; in fact our approach starts from the GOOSE model, we want to make UDP as reliable as possible by adding a small algorythm, just a light one to not decrease the speed of transfer. we have found that labview is the best tool to do so. IEC61850 is new standard that still needs a lot of work to be fully accepted in industry, we know it may look meaningless to insist on UDP, but at least, let's try this is the spirit

To me it looks like IEC61850 is not about transfering large files consistently over the network. To do that over UDP is really not a smart idea as you have to implement on top of UDP something similar what TCP does already for you.

An interesting side node to this: A while back I was looking at the network protocol used by Second Life and other compatible virtual world environments. They used to have the entire communication over UDP with their own sequence handling, acknowledgement and retransmission requests. The reason to go for UDP was supposedly the low overhead that was required to make movement and interaction in a 3D virtual world possible at all. However a few years ago they did introduce a new mechanisme for non-realtime critical messages and are porting slowly more and more of the messages over to this new mechanisme. It is basically a HTTP based protocol where the packet load is usually a data structure in their own LLSD format, which is in many ways similar to JSON.

And yes I have implemented some basic messages in LabVIEW that got me as far as logging into a virtual world server.

And this is the point my friend, we want to build anew UDP based protocol, you can say like UDT, to be used in power substations just like the GOOSE, i already said that i have a good theoritical knowledge with both TCP and UDP and the differences between them, however, i just don't know how to implement them using labview at the time my supervisor insists on using this programming language

I googled it too and that was my conclusion. There were clearly tasks that cried out for UDP, broadcasting time-critical small pieces of information, but there was nothing suggesting one had to use UDP for sending large files.

because you have just read what other people suggested for this new technology, IEC61850 is still under development, and the trend now is toward UDP based protocols, just look for more details about IEC and you will understand why we are insisting on UDP instead of TCP

wow, now it is working, but the received file seems to be corrupted due to packet duplication or miss-order, i tried to improve the performance using queues but i didn't get what i want, any suggerstions so far??

UDP File Client.vi

UDP File Server.vi

One way of getting the chunks could be:

thank you, i hope this will solve the problem

my brother, i'm not angry i'm just beginner in labview and i don't have enough knowledge with it to understand exactely what my friends here are trying to explain for me, moreover, i mentioned earlier this is not a home work, it is rather a research, and if you google the term IEC61850, you will understand why we insist on UDP!!

There is nothing wrong with your explaining skills! There are however people who do not want things to be explained to them but instead things being done for them. Or English is not the native language but the posts look pretty ok to me in grammar, so why someone with such a grasp of the language never has heard about "chunks" is beyond me.

Also while reading a file in chunks and sending it over UDP will probably work in a local network, I'm pretty sure the resulting file on the receiver end will be damaged after being transmitted like that over a more complex network infrastructure. That is unless one adds also packet sequencing code to the transmission (and in doing so more or less reimplements the TCP protocol on top of UDP).

i knwo what "chunks" are, but how to build them in labview!!, i don't want people to do work for me, i just need some help i already said i'm not expert in labview, i have a good theoritical background with both TCP and UDP protocols, and in fact they are just a part in a larger research about IEC61850 standard.

It means a piece. A bit. A portion.......of the file.

For GOD sake, this is my VI, please help me, i know TCP is better, but i just wanna see it working with UDP, so what shall i change to not see this error message anymore

Yes.

This is a similar VI that it used in the "OPP Push File" in the LAVA CR.

It opens a file and reads "chunks" that it then sends (in this case) via bluetooth. You need to do the same except with UDP rather than bluetooth..

thanks ShaunR, i will try this, but could you provide me with more details about "chunks", what are they exactely??

Just read 65k bytes (or 1500 bytes is better for the reasons Rolf outlined) from the file at a time and write it using the UDP write. However. As GregR stated. It is not guaranteed to be recieved in the correct order, or indeed a chunk to be received at all! So that's not a lot of good for files, but usually acceptable for audio or video where a lost frame or two doesn't matter too much.

The easy solution, as others are saying, is to use TCPIP where all the ordering and receiving reassembly is handled for you (as well as other things UDP doesn't do out-of-the-box such as congestion control, re-transmission of lost packets etc). If you really must use UDP then you will have to code all that yourself (unless missing or incorrectly ordered file chunks is acceptable-for TDMS it wouldn't be). There are a few examples of reliable UDP (RDP). Noteably UDT and NORM. I am not aware of anyone doing this in Labview however, since it is just easier to use TCPIP.

I do appreciate, and i am with you for the choice of TCP/IP instead o UDP, but unfortunatly, my teacher doesn't do so. He is insisting on UDP!!. Anyway, i have tried what you have suggested, but i got the same errror, and i think it is logical, if the buffer size is only 65Kb or less, how can it handle 600Mb!! what i want to know is what is the code i should use to devide my file into packets of 65Kb, because wiring the 600Mb file directly to the UDP Read VI didn't work. or shall i use a while loop?

No. I'm saying the payload cannot exceed 65k. If you can send 1 payload (of 65k) every 10ms then that would be 6.5 MB/sec

Brother, this is exactly what i wanna do, I have a 600Mb TDMS file and i need to transfer it as fast as possible. now i understand that the maximum data packet size is 65Kb, which implies that i must devide my 600Mb file into packets of 65Kb each and then send those packets using UDP. My question is: how can i devide my file into packets??

Under windows, the default udp datagram size is 1500 bytes (i.e the default MTU). The maximum it can be is 65535 bytes (you can set it to more than this, but it will still be limited to 65k ). This is because the UDP header field is a U16 and cannot represent more than 65k.

UDP, User Datagram Protocol

so you wanna say that there is no possibility to go beyond transfer rates of 65Kb/s using UDP!!

Sorry I didn't realize this is a homework assignment. In that case, you can learn about TFTP and implement your own solution by reading RFC 783 and RFC 1350. This will also give you an understanding of what chunks are.

Good Luck!

~Dan

thanks a lot for the help, i'll read what you mentioned even thogh i still think the solution resides in increasing the size of buffers!!

It's incorrect to say that UDP is a "faster" protocol. It is more lightweight than TCP, but that doesn't inherently make it faster - especially in the use case you have, where you'll basically need to handle everything that TCP does automatically (and at a lower level).

Speeds far in excess of 2Mbps are feasible using TCP, so you probably need to take a look at your implementation and maybe talk to your teacher about what you can do to optimize it.

i think you are right, and i'll go back to TCP, but i still want to increase the buffers size, how can i do so??

Can you send your data in chunks? You really don't want to set your datagram size to megabytes.

honestly i have never read about chunks, could you give me some details please

UDP does not guarantee ordering, non-duplication or even delivery of "chunks", so you would need to make sure each write contains enough information to completely identify which part of which file it is. That way you could reassemble them on the other side. Even then you may not get them all, so probably want a way to ask for some part of the file to be resent.

These are things that TCP would take care of for you. Do you really need to use UDP?

i have built successfully an aplication that transfer files using TCP, however it is really slow, this is why i need to use a faster protocol like the UDP

There's a TFTP example on the NI website: https://decibel.ni.c...t/docs/DOC-8301

No need to reinvent the wheel.

ok you can ask my teacher about that, he insist on building a new application!!

Here's a KB article on setting the read buffer. We had to do this because the unit we are testing is sending at Gb speeds and we would loose the packets in Windows. It only speaks of the receive buffer, but I imagine the send buffer is very similar if even needed.

Lost UDP Packets at Fast Transfer Rates

The TFTP example looks promising as well.

thanks for the link, i have already tried it and actually it can't give a transfer rate more than 2Mb/s, which is far from my goals!!

Hi everybody

I hope someone can help me. I'm trying to build a client-server file transfer application. The client reads a file stored on a given working station(PC) and sends it to a server installed on another working station for further usage. I am using UDP as the transport protocol. The problem is that my application works perfectly with files whose size is in the range of kilobytes, however when I try to send files whose seize is in the range of megabytes, the application crashes down and the attached error message shows up

I understood that I have to increase the size of both the UDP sending and receiver buffers, but I don't know how to do so. please if you have any idea on how to do so, just let me know

Best regards

Is the error related to "lack of information"?

No , a pop up message shows up and says that i have to add my PC as a machine server

i am using the TCP/IP transfer protocol, i have tried to build a timer that counts the time required for this problem, but it didn't work well.

hellow everybody

does anyone know how to build vi that calculates the rate of data transfer and indicates it on a monitor.

i want to build an application to exchange files and i want to display the rate of data transfer.

thank you

Thanks for your answer, Actually i need to build an application that transfers data from one device(PC) to another via ethernet. the used protocol is TCPIP, i managed to build such a connection but the problem is that whenever i stop the application an error message shows up. also i need to add an indicator that indicates the rate of data transfer, how can i do it?

Hi everybody, i'm beginner with labview and i want to build a tcp connection for my final year project, i have tried to follow the examples that come with package of this software but with no results. so plz if someone can show me in details how to use the different elements; tcp listen,read,write etc