viRead and viWrite with Etnernet not working - Telnet?

[judyh]

Hi again,

Please see my previous posting at viRead and viWrite not working over serial connection to device

I managed to get the viRead/Write functionality working in a serial connection, but I am now having issues with Ethernet.  I will attach the associated file.  It appears that these function calls work.  I occasionally get a lost connection, but as I'm debugging line by line, I'm not surprised at this.  The problem is that my device is not responding to these commands.  I think this may be an issue with the module we have in our device (a different one than before - this one is not restricted to the 16 byte frame and currently handles ASCII bytes sent in through a Telnet session).  This module is a small piece of hardware that contains a web server and Telnet server.  It will also handle UDP connections, but I haven't tried that yet (long story) and I understand from the manual that this is not something compatible with VISA.  Here's what I think is happening:  My VISA code is writing bytes out of the PC's ethernet port and I believe these bytes are going into the module, which I think expects either Telnet or HTTP protocols, depending on the port I'm using.  The bytes are not getting scrambled properly and thus, the device isn't getting its commands.

My question is, have you heard of anything like this before.  I checked the manual and there was nothing in it about Telnet or HTTP protocols, so I'm assuming I would have to handle this on my end to talk to the device.  I am also going to contact the module manufacturer to see if I can configure it to simply handle a socket connection.

Thanks for any and all help.

Judy

[judyh]

Hi again,

I think I solved that issue.  It works when the port is 10001.  My Ethernet hardware guru tells me that the module is set to handle socket connections over that port.  Now, I have another question about the viRead function:

ViStatus viRead(ViSession vi, ViPBuf buf, ViUInt32 count, ViPUInt32 retCount)

My question is about the "count" parameter as it relates to the "buf" to read.  If my device is sending a variable length string in response to queries from my code, do I have to know the exact length of the reply and put it into the "count" variable in order to read my response, or can I simply make sure that "count" is always larger than the length of "buf"?  If I do that, will the function wait until all of the "count" bytes are received before it exits?  I've been looking at the documentation and it's not very clear on this point.  I'm currently sending a "help" command to my device that responds with multiple lines (36) of text to explain all possible commands and, rather than counting all the characters I will receive, can I just put a huge buffer in place to receive it?  I tried this using the serial communication but kept getting timeout errors on the read functions if I did not put 16 into the "count" variable.  I also had no start/stop bytes for the frame of information coming out of that older device.  With the one I'm attached to now, I don't have termination bytes either.  Will give it a shot on the ethernet, but I'd like details.

Thanks,

Judy

[jr_2005]

It's easier than you think. The data read by the library function has to be put somewhere inside your code - that is what buf is for. The library routine has to know how big this area is, so that it does not try to put too much data in it - that is what count is for. Finally, it needs to let you know how much data it has actually placed into your buffer - that is what retcount is for. Just make sure the buffer is big enough for your worst-case data transfer and you can't go wrong. 

JR

Message Edited by jr_2005 on 11-20-2008 04:06 PM

[cymrieg]

Judy,

If you do a viRead with a large count and that amount of data is not available to transfer then NI VISA will timeout. If you don't know the exact amout the best thing to do is viSetAttributte to enable termchar - by default it is off. The viRead will then read the count value of data or if it sees the termchar first then it will return without a timeout error. The default termchar (termination character) is linefeed (10) but if your instrument has a different character then there is an attribute to change it.

[judyh]

Hi cymrieg,

Thanks for the info.  I did end up using a termchar on the variable length stuff.  Our device allows us to insert one optionally at the end of all lines of text transmitted.  I found that this worked, but I had to wrestle with it some.  When we insert a terminating character in our device, it sends a "\r\n\0" at the end of the string.  I had to make sure that I flushed the incoming buffer after each read because, if I set the termchar to '\r', the remaining two characters were still in the buffer as I moved on to send and receive the next command/response.

Thanks for the advice.  I like the idea of having one tool that handles all these different communication types.  It definitely makes my life easier, particularly with the Ethernet communications.  I had been looking that over for a while and, never having done TCP/IP or network programming, I knew without something like VISA that I was looking at a long slog to figure it all out and code it.

Thanks everyone,

Judy