Managing timeouts for VISA-ethernet connections

[massen]

Dear Community,

We have a number of CRio units in our experiment that have RS232 instruments connected to them but where the cRio is only used as a bridge for the connection. So we've set up a visa resource that a labview programme on a separate remote device can use to talk to the instrument (of the type visa://128.141.240.225/ASRL3::INSTR). This works generally well. However, if the cRio device in question for some reason is off the attempt to open a connection stalls labview for almost 15 seconds - and there doesn't seem to be any timeout one can change to fix this ? I've attached a simplified code to send a command, and receive an answer that works - except if the device is off - it stalls all of labview at the "VISA Configure" for ~15 sec.

I've not resolved this yet, but my current get-out-of-jail solution would be to just ping the device beforehand to check that it's alive - but it seems like there should be a better way to not end up in this dark place ? Any suggestions ?

Regards,

Niels

[billko]

---

@massen wrote:

Dear Community,

We have a number of CRio units in our experiment that have RS232 instruments connected to them but where the cRio is only used as a bridge for the connection. So we've set up a visa resource that a labview programme on a separate remote device can use to talk to the instrument (of the type visa://128.141.240.225/ASRL3::INSTR). This works generally well. However, if the cRio device in question for some reason is off the attempt to open a connection stalls labview for almost 15 seconds - and there doesn't seem to be any timeout one can change to fix this ? I've attached a simplified code to send a command, and receive an answer that works - except if the device is off - it stalls all of labview at the "VISA Configure" for ~15 sec.

I've not resolved this yet, but my current get-out-of-jail solution would be to just ping the device beforehand to check that it's alive - but it seems like there should be a better way to not end up in this dark place ? Any suggestions ?

Regards,

Niels

---

If the picture represents how you are doing it for real, you're doing a lot of extra stuff.  All those buffer flushes are there to clear out stuff that you didn't read because you use Bytes at Port improperly.  I think that if you straighten out your communications, you won't have to ask this question because it would just work.

[RTSLVU]

bilko is right, and if you are using "Byte at Port" chances are you are doing it wrong.

Also it look like you are opening, configuring your port and closing it every single time you access it.

That is not good either, you should configure the port once at the start, pass the reference between iterations in a shift register, and close the port when your program exits.

I think this video can help you. VIWeek 2020/Proper way to communicate over serial

[BertMcMahan]

While his communication protocol may need work, it sounds like his question is "Why does open VISA session take 15 seconds to return if there is no valid device?"

Is that right OP?

[billko]

---

@BertMcMahan wrote:

While his communication protocol may need work, it sounds like his question is "Why does open VISA session take 15 seconds to return if there is no valid device?"

Is that right OP?

---

Boy, that was dumb mistake.  I thought the question was about serial communication issues, but it's really about what happens to VISA when the cRIO.  OP sorry for being off-topic like that.

[massen]

That's correct, in fact the VI needs only the "open visa" connection to fail for 15s if the network connection fails (e.g. device is off) - the rest was just to make a quick vi that worked with my device when it's connected. In trying to debug this I made a vi that didn't do ***any*** communication, just had a property note from a visa resource and asked for the "name" (name->string essentially) - that also stalls if the device if off-line... very peculiar.