LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI to VI networking problem

Hello everyone,
 
I am developing a software for our laser microscope. We have 2 computers, both running a VI, one VI is master which the user controls and uses, the other VI is slave which acts as a server to the master VI. When we want to do a scan, the user selects parameters from the master VI and a G-Code file is created from the master VI and saved to the local Hard drive, once it is saved, it is sent to the slave VI (which is always listening to the TCP port for incoming connections), upon receiving the file, the slave VI automatically compiles the file and sends it to our motion stage. The two computers are connected to the same router and can ping to each other. The problem is that when I run the two VIs on one computer; the system works (i.e. the file is created, sent by the Master VI and received, saved, compiled by the Slave VI) but when i run them on different computers: The system works only the first time (i.e. the first time i send the file through the master VI), when i send another file from the master VI the second time; it does not give me any error (i checked with Highlight execution mode) as though the file was successfully sent, However it is not received by the server VI. To process works again if i just stop and start the Master VI so i think the problem is in the Master VI. On one computer; the process works no matter how many times i do it without having to restart the master VI. I have tried my best but could not find the problem.
 
Please help if anyone knows whats wrong...
 
Thanks...
 
btw: I am using TCP/IP protocol to send and receives the files.
0 Kudos
Message 1 of 12
(3,441 Views)

Hi Mutee,

      Any chance of posting the two VIs - or stripped-down versions?  The TCPIP functions are very solid - so it's probable you've over-looked something. Smiley Wink  Be sure to look for errors at every step, and if a TCPIP connection is repeatedly opened, make sure it's being closed too. Smiley Happy

Cheers!

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 2 of 12
(3,420 Views)
I have made one VI that includes Sending and Receiving parts of both Master and Slave VIs...I have labelled everything as much as i could...when the user does a scan on the master VI, a G-Code file (in this case foo.pgm) is sent to the slave VI running on separate computer, the slave vi is running a while loop, constantly checking for incoming connection, as soon as the file is received, it saves the file> compiles it and sends it to the motion controller...please read my previous post for what the problem is...
 
Thanks again
0 Kudos
Message 3 of 12
(3,409 Views)
First, clean up the spaghetti code of wiring.  Those Error wires in the slave VI are a mess.Smiley Wink
 
Second, the logic seems backwards.  It seems to me that your file receiver should be the one with the TCP listen waiting for something to try to connect to it.  The file sender would be the one to create the connection to that PC.  That would match what you wrote in the first post, but is contrary to what you did in the attached VI.
 


@Muttee wrote:
 it is sent to the slave VI (which is always listening to the TCP port for incoming connections), upon receiving the file, the slave VI automatically compiles the file and sends it to our motion stage



0 Kudos
Message 4 of 12
(3,394 Views)
Hi Mutee,
RavensFan is right - there are some major "no-no"s going on in the right side loop (described as "Slave") - but it was fruitful to have something to look at! Smiley Happy  As simple as your app appears, I expect the problem is going to dissappear as a result of straightening-up the code.
 
For fun, I went ahead and built an example based on your original post/description (attached).
One difference between your implementation and mine is to write a single packet instead of two packets.  With a single "link" in the communications chain, there's less possibility of starting the read process but getting stuck! Smiley Wink
 
Cheers!
 
 
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 5 of 12
(3,386 Views)
First of all, thank you all for looking into my problem, especially tbd for the example implementation. I looked at the example and changed the Master.vi (attached) a little bit to read a file and then send the Data and changed the Slave.vi  (attached) to save the file. I am getting the following error on the Slave.vi:
 
TCP Read in Util.TCPIP.Packet.WriteRead.vi->Slave.Wait.vi->Slave.vi
 
Error code 56.
 
this happens when i am running slave and then i press send on master.
 
let me know what i am doing wrong and thanks again in advance.
 
 
0 Kudos
Message 6 of 12
(3,356 Views)

Are you sure you have your address set right?  In your master VI, you have it set as Muttee.  I would thing if Muttee is your computer name, you should have the constant set as \\Muttee.  Try it with an IP address as well.  Also check to make sure that port 5535 is not blocked by windows firewall on the slave computer.  But if I were to bet, I think it is the address name being improperly formatted.

To start, run both on the same PC and set the address name to \\localhost.

0 Kudos
Message 7 of 12
(3,353 Views)

i tried using localhost, //localhost, //Muttee, 127.0.0.1 but all give me the same error on the slave.vi > "TCP Read in Util.TCPIP.Packet.WriteRead.vi->Slave.Wait.vi->Slave.vi"

Thanks...

0 Kudos
Message 8 of 12
(3,349 Views)

Hi Mutee,

      Sorry, it's a bug!  The Master is opening a connection to the slave, and the slave immediately calls Util.TCPIP.Packet.WriteRead.vi to read and waits...

... but the Master needs Util.TCPIP.Packet.WriteRead.vi too, to write the data, so the Master waits - it's a classic "deadlock" until the slave timeout (error 56.)

If you change the execution-properties of "Util.TCPIP.Packet.WriteRead.vi" to make  it "re-entrant" the problem goes-away!  A second way to fix it is adding a wait (of, say, 555ms) inside Slave.Wait, after Listen but before Util.TCPIP,WriteRead.vi  

Note: there wouldn't be a problem if running Master and Slave on two different computers. Smiley Happy

P.S. I recommend renaming re-entrant VIs with ".r.vi" instead of just ".vi" - that way you can tell at a glance what's supposed to be re-entrant.  It's over-kill for this application, but when developing "highly-reentrant" applications it's a valuable flag that can be used for programmatic validation/auditing.

Cheers!

Message Edited by tbd on 08-27-2007 10:08 PM

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 9 of 12
(3,337 Views)
tbd;
 
thanks very much again for the support. Yes, it worked on the same computer this time, will check it out on the lab computers later on. But i have a question; what is Pack/Unpack doing? ..the .PGM file i send is received with non-keyboard characters at the start causing it to not to be recognized as G-code...also the formatting is affected...
 
Is there a way to not affect the fomatting or add anything to the file?...even the end of file characters ...
 
thanks
 
 
0 Kudos
Message 10 of 12
(3,317 Views)