How to ignore VISA Read Error (VISA hex: 0XBFFF003E) Power Amplifier Lucia 120/2

[Dimitris4235]

Hi there,

I am trying to communicate with a Lucia Power Amplifier via Serial RS232 connection (Command list attached). I have an error when attempting to Wake Up the device from standby mode. The device wakes up, but when I try to read data from the instrument I receive an error at VISA Read. However if you look at the output buffer, the expected message is there. I believe this is happening due to the null character at the beginning of the message? I am using Carriage Return as a Termination Character. You can see my attempt of using the VI to communicate on my NI Trace Capture. Whenever I am using <CR> on its own it is to flush the input command for the device, so you can ignore this timeout error.

Is there a way of ignoring the error from VISA Read? As I am receiving the message intended so it is correctly working.

Thanks in advance

[NIRebecca · Accepted solution]

Hi Dimitris4235

If you have a specific error you want to ignore you can implement this into your code quite easily with a case structure or using the Clear Error API. How Do I Ignore a Specific Error in LabVIEW?

You could even add extra logic to ensure this only happened on the first run to make sure if it does throw this error later on it is not missed. 

Something like:

[Dimitris4235]

Thanks for the reply,

It turns out I was just incorrectly using the Clear Error.vi. This resulted in the error reappearing in NI Trace and stopping my program. I now have a loop which clears the error BEFORE Visa Read every time and the program will only go through if VISA Read has no error out 

[billko]

As an extreme word of caution, make sure you truly understand the nature of the problem before you just swallow the error.  I'm not saying this is the case here, but usually something like this SCREAMS that you have an incomplete understanding of how to communicate with the equipment.  (Even if you think you do, oftentimes, you'll come to realize you didn't really understand everything.)

I am just afraid that the solution is actually treating the symptom and not the cause.

[Dimitris4235]

The problem which I believe I am facing is that my instrument's commands/replies are all supposed to end with a <Carriage Return> so this is set as my termination character. Now when using any of the commands listed in the manual this operates correctly in each case except from one:

This instrument has a Standby mode where it goes Idle after a certain period of time of inactivity, there is a command used that Wakes Up the device. When pinging this specific command which does not end in a <CR> my device does indeed Wake Up, however what happens is that VISA Read , although it does receive the intended Reply from the instrument "OK WAKEUP" this is not displayed on an indicator as VISA Read encounters the above error. I believe this is happening due to the instrument not sending back a <CR> when pinged with the Wakeup command. When I ignore the error it functions as intended due to the device actually waking up but VISA Read ends with an I/O error. Would changing my termination character temporarily work in this case?

EDIT: The Wakeup reply message does indeed end with a Carriage Return (hex 0D) but this does not stop the VISA Read block for some reason? Basically VISA Read ends on any other occasion except when I use Wakeup on my device. I'm starting to believe its the instrument architecture and not my code

[billko]

What I/O error is this?  That could determine what the proper way to handle this case.  As you've noticed, swallowing the error just made it do something different, but still not correct.  The I/O error could tell us what it needs to be happy.  🙂

[Dimitris4235]

Hi again,

Apologies for such a late reply I have been away this week. The error output is:

VISA hex: 0XBFFF003E(VI_ERROR_IO) 
Could not perform operation because of I/O error.

How my code runs:

1.Instrument goes into standby mode (Wait 20 seconds after the instrument enters the mode to settle)
2.LabVIEW sends message (20 spaces with no <CR> as instructed by the RS232 manual I have attached above)
3.LabVIEW reads response correctly as OK WAKEUP<CR>, but with the output giving the above error described.

I also tried using a <CR> at the end of the 20 spaces and nothing changed in regards to the response.
All other commands are working correctly, only the Wakeup interaction after the instrument enters standby is giving an error out. Which makes me believe its the instrument's coding architecture. I've attached the updated VI below.

Thanks in advance!

[billko]

Sorry it seemed like I just dropped off the face of the earth, but I actually did.  Well, metaphorically, at least.  I'll give this some thought this weekend.  I just wanted to post that you haven't been forgotten.

[Dimitris4235]

For the time being I am just going to be pinging a command every 15 minutes to prevent the device going into standby so that should be fine if I can just ignore it. 

Thanks greatly for your help

[billko]

I actually think you could use your temporary solution as a permanent fix, unless you actually do want it to go to sleep.  That's one way people avoid the dreaded Windows USB port power down.  Sometimes it's just easier to do that than figure out how to do tweak Windows to make it stop doing that.  In your case, it might just be easier to keep it awake by sending a simple command every so often, like you are doing now.  It is satisfactory to me because you are doing strictly legal stuff and you aren't swallowing errors.

If you have some time to experiment, you could try to flush the buffer at various places in the wakeup sequence (just one flush) to see if that fixes it.  A google of:

labview "0xbfff003e" site:forums.ni.com

returns about a zillion hits, and it seems that sometimes this error is caused by random data in the serial buffer.  This seems possible, as the serial adapter of your instrument could send a random byte or two as the instrument comes up, and needs to be flushed.  This scenario is fairly common.  This is just a guess however, because I only have LV 2014 at home and cannot open any of your NI/LV files.

I think you already have the solution, though; the experimenting stuff is for "extra credit".  I would mark your last post as a solution - if not the solution - because sending a valid command and receiving a valid response to keep the instrument from falling asleep is a much more robust solution than waking up the instrument and swallowing the error "just because..."

Caveat here:

While swallowing an error is generally a bad thing, this may be a case where I am erring too far on the side of caution.  There are some who will say that, in this particular instance, the chances of the error being meaningful are low, and therefore swallowing the error is OK.  And it might even be okay.  To put things in perspective, do you know how long it took to convince myself that leaving (most) property nodes unattached by error wires to anything was okay if I didn't care when they executed?  (For most property nodes, the chances of a runtime error are extremely small and only occur during development, when you are expecting errors from them, like running a VI with property nodes that are referencing controls in a different VI that hasn't executed yet.)  So keep this tidbit of info in mind when you decide whether I'm just being cautious or paranoid.  😉