08-22-2007 02:03 PM
08-22-2007 10:16 PM
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. Be sure to look for errors at every step, and if a TCPIP connection is repeatedly opened, make sure it's being closed too.
Cheers!
08-23-2007 09:15 PM
08-23-2007 09:27 PM
@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
08-24-2007 02:12 AM
08-27-2007 03:53 PM
08-27-2007 04:15 PM
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.
08-27-2007 04:47 PM
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...
08-27-2007 10:04 PM - edited 08-27-2007 10:04 PM
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.
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
08-28-2007 01:06 AM