Jump to content

odrulz

Members
  • Posts

    5
  • Joined

  • Last visited

    Never

odrulz's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Sorry, I didn't save any of the raw data. I mostly just used probes and indicators. I'd like you to see the data too, now that you brought it up.
  2. Well the good news is that I was able to resolve the problem. The bad news is I'm not entirely sure why or how. I created much smaller TCP Host & Target vi's that only sent and received one thing each, but it used the same Meta data that I was using for my application. That worked fine. So then I set up the small test vi's to work with my app vi's. When I replaced my app target vi with the test vi and ran it to my app host, it worked. When I replaced my app host vi with the test and used my app target, I got the same error. So I replaced some of the Meta related elements and vi's on the target and now everything works fine. I think something must have gotten corrupted. I also noted that when I received the packet and everything worked the "bytes to read" value I was getting was 5445, when it failed the value was 5450. So the failure was related to an extra 5 bytes of something (linefeeds or carriage returns would be my guess - something that caused at least one empty line in the middle of my data) getting placed at the 4097byte mark. That's as much as I could figure out as to why it was failing. If anyone has any better guesses or more information as to what I was seeing I would appreciate it just for further understanding. Thanks for the help TobyS. Scott
  3. From what I could gather from the googled 2IHG7FZ8 article, it was saying that the full duplex is only an issue with a crossover cable and that with a hub it works fine. Did you take it that way? I'm seeing the exact same results every single time, with both a crossover cable or using a hub. And the article seemed to say the connection becomes unstable. I was getting error 66 during the Meta element transmission from the server to the client after 4096 bytes every time - the very first thing I transmit once the connection is established. And the max vi's were fine up to 16kbyte packets. So I was getting the same error at exactly the same point every time. I'm not sure if that's quite the same thing. Thanks for the post though. I will keep that in mind if I run out of ideas that's for sure - which I've only really got one more idea to try out at the moment.
  4. Well I adjusted those Maximum TCP Transfer vi's and verified that I was able to send and receive up to 16kBytes reliably from the PXI target to the laptop host, with the best transfer rate occuring around 4kByte packet sizes. So there doesn't seem to be an issue with packet size limit, but something else within the Meta vi's. My TCP vi's work great between two pc's as well as when I just use localhost, so what's the difference in running the server from the RT target vs a pc? The only difference I can see in the block diagrams is that the Max vi's are sending arrays of numerics and the Meta vi's are sending an array of clusters. I'll tweak the Max vi's to send the same array of clusters that I use in my program and see what happens next. I've tried using a crossover cable directly between the target and host and with a hub (not a switch) at 100mbit and both ways the packet was getting clipped. I haven't done anything with the duplexing, and I'll have to look that up to even know how, but will look into it and check it out. Did you ever find out the reason why half duplex and 10mbit gave you faster rates TobyS? Thanks for the help
  5. Hello, I've created a TCP/IP with XML server and client to be used as our standard connection between any remote systems and the main running application using the vi's described at http://zone.ni.com/devzone/conceptd.nsf/we...6256F170079411E. I've tested it out using localhost on a single computer as well as on two separate PC's running Windows on our intranet and everything works great. But when I send the target vi to a remote PXI chassis and run the host vi on a laptop connected only to the remote system (I've used a crossover cable linking the two directly and a patch cable with a hub in between, but either way the only two pc's on the system are the remote PXI and the laptop) I'm getting a failure. I'm using a PXI 1045 chassis with an embedded 8187 processor running LV7.1 RT only - no Win OS on the remote system. The laptop is running Win XP with LV 7.1. At this point I'm not making any attempt to utilize anything on the PXI chassis other than the TCP communications. The problem I'm seeing is the Read Meta.vi (located in the host vi running on the laptop) is only getting 4096 bytes, then the I get error 66, connection closed by peer (the remote PXI running the target vi - Write Meta.vi). The bytes to read value within the Read Meta.vi is 5450, which is the correct number of bytes needing to be read, but then it only reads 4092 bytes (4096bytes minus the 4bytes telling how many bytes to read) and so the XML data gets corrupted and the resulting error stops the vi's before they really get started. 1. Why would this do that? 2. Does anyone know anything about a packet size limit for PXI - TCP? I understand that LV 7.1.1 has a fix to allow packets to be up to 65536 bytes, which would solve my problem I believe, but we will want this to be used by hosts and remotes that run with LV 7.1 (and possibly earlier versions), so I need to resolve this 4096 byte issue as it is. 3. Do I need to rewrite the Read Meta & Write Meta code so that it breaks the data packets into maximum sizes? I was under the impression that TCP/IP communication did this automatically, is that incorrect? I just downloaded the Maximum TCP Transfer vi's and will play with those, maybe I'll find something there. Thanks for any help, Scott
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.