visa I/O error -1073807298

[louis_nichols]

Hi everybody! More VISA troubles, it seems.

I have a little module that goes a little something like this.

VISA write -> VISA read -> VISA flush -> VISA read again

This is because I send a message via a serial converter that loops back the request, so I have to flush it.

Now, I use this module (let's call it serial1) in another application that looks something like this:

VISA configure serial port > VISA serial break for 25ms > wait 25 ms > serial1 > do actions

OK. The thing is that serial1 works on it's own, but when used in the sequence above, I get an error -1073807298 from the first VISA read in serial1.

This is very puzzling and unexplainble to me.

Does anyone know why this might be?

[Jason W]

Hey louis_nichols,

Thank you for contacting National Instruments.  Are you using a third party serial converter?  If you are, take a look at this knowledge base.  If that doesn't solve your problem, take a look at page 2 of this forum post.  The third post on the second page talks about a work around for this issue.  Let me know if you have anymore questions.

Hope this helps!

Jason W.
Application Engineer
National Instruments

[louis_nichols]

Hi Jason! Thank you for your reply!

The thing is I don't use any third party converters. I should have been more clear. For communication I use the standard PC RS232, COM1. The converter I was mentioning about is just an external level converter, from RS232 to K-Line. I kinda hate it, because of the loopback bug (No! It's not a feature! ) but it's standard in my company, for some reason, and I have to make it work.

I will try the suggestions in the thread once I get to work on monday. In the meantime, do you think NI-SPY could give me some more useful information about why this is happening? I don't really know how to use it, but I guess I could figure something out. Even so, as long as there is no error at error in to VISA read, but there is an error at error out, even if I do find some useful info with NI-SPY, would there be something I could do?

[Jason W]

Hey louis_nichols,

If you are still having problems with this issue, a NI-Spy capture would help in determining what is wrong.  Take a look at this knowledge base for instructions on how to perform a good NI-Spy capture.  If you do have to run NI-Spy, feel free to post your results, so we can further troubleshoot your problem.  Also, let us know if the suggestions in the thread linked above helped.

Regards,
Jason W
Application Engineer
National Instruments

[louis_nichols]

Hi Jason! Thank you again for your answers and interest.

My answer comes later because I was assigned to another project this week and got back to my problem just today. I managed to solve that problem, it seems and I think I know the cause of it, too.

Long story short, the current, working solution can be seen in the attached image.

before I didn't use that while loop before doing the VISA read and I think the error was because, at the time it was trying to read, the required number of bytes was not present in the buffer. I think...

Anyways, that works now. I have another problem, though. After the sequence aabove, I perform another read using this sequence.

The problem is that it only reads up to 8 bytes. I know my messages are longer than this, but I can't explain why they are not received completely. Messages with 6 or 7 bytes are ok. Do you have any idea?

Message Edited by louis_nichols on 11-23-2006 09:12 AM

[louis_nichols]

Sorry about that! It won't let me edit the message anymore. The block diagram for the read is this one:

as I said, it won't read the whole message sent by my peripheral device...

[pincpanter]

Hi louis_nichols,
maybe you need to wait more: even if bytes_at_port is > 0, it's not guaranteed that all characters have already been received, especially if there are latencies in the serial output of your device. If the device's messages have a terminating character, you could setup VISA to wait the terminator in order to end a read operation; alternatively, you may write a loop where you wait the terminator until a given timeout has expired.

[louis_nichols]

hi pinkpanther! thanks for your reply!

I thought of the same thing, but I wouldn't want to use an arbitrary delay before reading, because in my application timing is pretty important, so I need to read that message asap. also, messages could be up to 260 bytes long, with most of them only 6-10 bytes long. So I would have to set a delay of around 300ms (9600 baud) before reading even the shortest message.

unfortunatelly, I don't get a termination character

how about if I use a loop that starts reading when there are bytes at port and stops when there are none? that would mean end of one message... I think. I'l try this tommorow.

Message Edited by louis_nichols on 11-23-2006 11:42 AM

[TCPlomp]

Hi Louis,

How do you know what message (and lenght) you get?
If your messages have a (let's say) 3 byte header, you can read the 3 bytes. and then read the number of bytes for that message!

Ton

[louis_nichols]

Hi TonP! Thanks for your suggestion!

The format and length of the message can indeed be deduced from the header. But it would involve more processing that I am hoping to use at this level of my application. I am trying to find a way to receive the message without performing any processing of its contents.