07-08-2022 04:00 PM
@constructionworker wrote:
@Mark_Yedinak wrote:
I would still recommend a rewrite of the code. The server logic is bizarre to say the least. A true server would have a task which simply listens and spawns next tasks as clients connect. This is not necessary if the server supports one, and only one client at a time. You should not use the timeout event as a trigger to actually read the data. this is a very strange construct. As mentioned earlier, a basic protocol would help quite a bit. For instance, every message you send would include a header which contains a message type and a length field. The length field would specify the amount of data which is contained in the message. So, the server could simply read with a timeout of -1 waiting for x number of bytes. X is the size of your header. If the message ID is a U16 and the length is a U32, your header is 6 bytes. After reading this you check the length field to see if there is more data. If so, read it. If not process the message and then go back to waiting for the read of a message header. There is no strange "look for a timeout which will then trigger me to actually read data" construct. If necessary, you can put a short timeout on the read of the header which simply allows the server to do some other processing between receiving messages. However, hear when you receive a timeout you clear the error, do some basic task/processing if necessary and then go back to waiting for a message header.
This is a much cleaner server implementation than what you have posted. It also has a basic protocol which allows you to have a variety of message types. Other messages could be an exit/stop message, clear buffers or any other type of processing that may be needed.
To be honest, I changed the server and client logic a little bit for me.
Let me explain the type of application I want to have as follows;
Application on first computer:
-It is the application to run first. The application will start running and wait for the second computer to send the videos.
-If the application on the second computer starts running, it will display the number of connections to understand that the application on the second computer is connected.
If the videos start coming, it will start sending some numerical information.Application on Second Computer:
-It is the second application that will work.
The application will run, send the connection information to the first computer and start reading and sending videos from the cameras.
-It will display the incoming numerical data on the screen as an extra.
I'm trying to understand your suggestion to rewrite the code, it sounds like a cleaner implementation.
But I suspect there is some difference between the method you suggested and the application I want to create.
Even if the application on the second computer has a problem and closes, I do not want the application on the first computer to close. I tried to explain the application I want to create above in detail. I added the generated code.
If you can make changes to the code, I can try so I can better understand what you mean.-I removed the timeout case structure.
Thank you for all your suggestions.
Really, it doesn't really matter what your applications do. The communications protocol is part of the very underpinnings of the whole application suite, and if it is not robust, your applications won't be, either.
Setting up a listener is pretty common, and there is no reason to reinvent the wheel. Start with a robust protocol, and implement a standard communication layer.
07-08-2022 09:54 PM
I've done something similar to what you are trying to do. I don't have the exact code in front of me (since I'm not doing exactly what you want), but I think I can describe the process that I'm 95% confident will do what you want.
First, here's the "one-computer" method (be patient, it will become clear). This is a simple Producer/Consumer Design Pattern. The Producer loop opens the Camera and starts taking Frames. As each Frame is acquired, it is put into a Queue (or Channel-Wire Stream) and sent to the Consumer Loop. The Producer Loop also reads the "Stop" button, and if it is true, sends a "Sentinel" (a signal that means there are not more data coming to the Consumer, so the Consumer can exit when it receives the Sentinel) and exits (the Producer). This guarantees both Producer and Consumer stop at the same time. For a Network Stream, the Sentinel is built into the Stream Writer (and Reader). If I'm using Queues, I use a "blank" input to the Queue (not quite certain how to do this for an Image, but we can figure this out later).
Now let's place the Producer on Computer 1, and the Consumer on Computer 2. Run the same code, except Computer 1 has only the Producer Loop, and Computer 2 has the Consumer (plus other stuff, of course). The Images are transmitted by a Network Stream, configured to send Images. You'd need to use something for a Sentinel, but the logic is the same, except the Network Stream replaces the Queue. You may want two more Network Streams to send "commands" from 1->2 and from 2->1 (you can "fake" a sentinel this way).
Bob Schor
P.S. -- I notice @billko suggests settling on the Communications Protocol. I agree, and would suggest Network Streams, as they are robust, flexible, and (relatively) easy to set up (once you understand the protocol -- help is available here on the Forums, if not in the Help files).
07-09-2022 04:56 AM - edited 07-09-2022 04:58 AM
@Bob_Schor wrote:
I've done something similar to what you are trying to do. I don't have the exact code in front of me (since I'm not doing exactly what you want), but I think I can describe the process that I'm 95% confident will do what you want.
First, here's the "one-computer" method (be patient, it will become clear). This is a simple Producer/Consumer Design Pattern. The Producer loop opens the Camera and starts taking Frames. As each Frame is acquired, it is put into a Queue (or Channel-Wire Stream) and sent to the Consumer Loop. The Producer Loop also reads the "Stop" button, and if it is true, sends a "Sentinel" (a signal that means there are not more data coming to the Consumer, so the Consumer can exit when it receives the Sentinel) and exits (the Producer). This guarantees both Producer and Consumer stop at the same time. For a Network Stream, the Sentinel is built into the Stream Writer (and Reader). If I'm using Queues, I use a "blank" input to the Queue (not quite certain how to do this for an Image, but we can figure this out later).
Now let's place the Producer on Computer 1, and the Consumer on Computer 2. Run the same code, except Computer 1 has only the Producer Loop, and Computer 2 has the Consumer (plus other stuff, of course). The Images are transmitted by a Network Stream, configured to send Images. You'd need to use something for a Sentinel, but the logic is the same, except the Network Stream replaces the Queue. You may want two more Network Streams to send "commands" from 1->2 and from 2->1 (you can "fake" a sentinel this way).
Bob Schor
Thanks for your suggestion.
I understand what you want to say, especially it makes sense to use the producer consumer model, but I want the application of the first computer not to close even if the application on the second computer (cannot read the video or similar) closes.
Because if the second computer shuts down, the application on the first computer will be running during the re-run and will wait for data to come from the second computer.
@Bob_Schor wrote:
P.S. -- I notice @billko suggests settling on the Communications Protocol. I agree, and would suggest Network Streams, as they are robust, flexible, and (relatively) easy to set up (once you understand the protocol -- help is available here on the Forums, if not in the Help files).
I'm having trouble understanding some things about how to send videos as there are no examples of sending videos using network stream.
Thanks for your suggestion.
07-09-2022 07:25 AM - edited 07-09-2022 07:27 AM
I’m not quite understanding your reasoning. You seem to try to defend a poor choice for a flawed protocol by some requirements that you made up. In reality those requirements are not contradictory to a properly designed protocol, rather tbe opposite
As to missing video streaming examples, that has a very specific reason. Doing video streaming properly is an inherently difficult task that can only be done efficiently with data compression schemes. Those data compressors are however often patent encumbered AND at the same time need active interaction with the higher level protocol layers to work efficiently. This makes them either very complicated to implement, which goes far beyond what an example is supposed to be or pretty useless. And you need an army of lawyers to determine who you need to pay royalties to in order to be allowed to distribute such an example. The most sensible choice simply is to not create such examples.
If you do you will be damned one way or the other!
07-09-2022 08:33 AM
Let me try to answer your questions.
Here is how I have structured my "two computers/one cooperative task" routines using Network Streams. I'm going to name the machines "Host" and "Remote". These names are taken from the terminology that NI uses for Real-Time Projects, where the Host is a PC running LabVIEW and the Remote is, say, a cRIO running NI LabVIEW Real-Time Linux. But in this situation, the Remote is just another instance of LabVIEW running on a PC.
Hope this has been helpful.
Bob Schor
07-09-2022 11:32 AM
Thank you for your answers. By the way, I had to read it many times 🙂 I tried to develop a small code as far as I understood from you.
I could not create exactly what you said because I think it is necessary to proceed step by step.
The method you describe is exactly what I want, but I'm having some trouble creating it.
- VI's working as local hosts on the same computer do not transmit data streams on different computers. There is no problem with the network or anything.I encounter this problem when I try to send a normal data.
I don't know where the problem originates from.
I have included example below.
07-09-2022 11:41 AM
@rolfk wrote:
I’m not quite understanding your reasoning. You seem to try to defend a poor choice for a flawed protocol by some requirements that you made up. In reality those requirements are not contradictory to a properly designed protocol, rather tbe opposite
As to missing video streaming examples, that has a very specific reason. Doing video streaming properly is an inherently difficult task that can only be done efficiently with data compression schemes. Those data compressors are however often patent encumbered AND at the same time need active interaction with the higher level protocol layers to work efficiently. This makes them either very complicated to implement, which goes far beyond what an example is supposed to be or pretty useless. And you need an army of lawyers to determine who you need to pay royalties to in order to be allowed to distribute such an example. The most sensible choice simply is to not create such examples.
If you do you will be damned one way or the other!
I took this example from the shared examples in labview, apart from the video sending and receiving part. I just changed the multiserver TCP example a bit.
Do you mean that my delay in sending and receiving videos is not due to the generated code method?
Are you talking about the need to use the compression method, which is a very difficult task.
07-09-2022 12:25 PM
I was feeling very generous so I rewrote your server and modified the client. This still is not the way that I would really do this. Since your system is not a command response type of protocol I would use separate connections for the data coming from the server to the client and the image data being sent to the server. Using the single connection like you are both data streams are very dependent on each other. That is, the data rate for the server data is synchronized with the image data being received. I don't have the IMAQ stuff installed for 2019 so I didn't do anything with that portion of the client. I would not have both image captures in the same loop. I would use a separate loop for each one.
07-09-2022 12:53 PM - edited 07-09-2022 01:11 PM
Thanks for your generosity, but there's a bit of a problem.
I am using 2018 labview by the way.
07-09-2022 01:11 PM
Here you go.