LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VISA read timeout error at uneven intervals


@RavensFan wrote:

First thing.

 

Get rid of the shift registers on the error wire.  I find they are a bad idea.  (Others might disagree.)  Yours is a perfect example why those shift registers are bad.

 

Right now you have no idea if that timeout error is some random, odd occurrence, or something that will persist.  Maybe it just happens rarely, but the next VISA read will work fine.  With the shift register, once you have an error, it will persist forever without any special code to do something else or clear the error.  That error goes to the beginning of the next loop iteration.  All the VISA commands have standard error input functionality which means they won't execute if there is an incoming error.  They all do nothing and just pass the error message on.  And the next loop iteration gets it, and it goes on forever until you stop your VI and restart.

 

Make those error wires normal tunnels.  Put an indicator on the wire so if something does happen, you can see it on the front panel.  Perhaps create a logging function that if there is an error, it rights the date, time, error message to a file that you can review later to see how frequently the errors occur.


Well, you hit the nail on the head, there.  In general, you should have some kind of error handling inside your loop.  I find no real reason not to put a shift register on a loop or you risk swallowing unhandled errors.  My first choice would be to have the errors handled in some way; my next choice is to have an unhandled error at least tell me something went wrong somewhere.  my last choice is to have an error swallowed and you never knew there was one in the first place.

 

Instead of swallowing that occasional error, have something inside the loop actually do something about it.  Even if it's just something to acknowledge the error.  Because you never know when an unexpected error will occur.  It's not the expected errors that will get you; it's the unexpected ones.  I would probably put in some error handling that would clear a timeout error, but pass any other errors on.  What happens if an upstream error came into that loop?  What if this error was important enough to NOT execute the command?

 

Not having shift registers, IMHO, is a dangerous habit to develop.  Instead, develop proper code to handle errors within the loop.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 11 of 25
(1,093 Views)

@JÞB wrote:

@RavensFan wrote:

@Alici wrote:

. I apologize if this is a basic question, but what kind of indicator would I put on the error wire? 


Right click on the error wire.  Pick Create Indicator.  Done.

 

(You can also find the error in control and the error out indicator on the front panel palette User & Dialog section.


The Controls palettes "Array, Matrix & Cluster" Contain Error In and Error Out or error in (no error) and error out depending on style


Thanks Jeff,  You're right.  I was trying to go by memory when I couldn't get LabVIEW to open at the time to confirm what I was thinking.

0 Kudos
Message 12 of 25
(1,077 Views)

@RavensFan wrote:


Thanks Jeff,


No trouble.  I actually had to dig for them myself since I usually just drop a merge vi with error in and error out at the same time.


"Should be" isn't "Is" -Jay
0 Kudos
Message 13 of 25
(1,072 Views)

Thanks for the information on adding the error cluster.  I added the error cluster and got rid of the for loop (just an input of 11 characters for the VISA read function), but I still get the same error.  I just read about the general error handler (as opposed to Labview's default) and making an exception action to ignore a certain error number(timeout) as I think Bill suggested so am trying that, hopefully wired correctly.

0 Kudos
Message 14 of 25
(1,050 Views)

I put the general error handler in and told it to ignore the timeout error. This approach prevented the vi from stopping and the timeout error message from showing up, but I stopped getting responses from the stir plate. It sounds like it might be a problem at the stir plate end rather than Labview end.  Would Labview be sending any command to the stir plate after a timeout? I know when I was putting together the vi, if I typed in the command to the stir plate incorrectly, that the stir plate would stop responding and have to be restarted.  I'm wondering if Labview might be sending some command to the stir plate when it times out that then throws off communication with the stir plate.

Thanks for the help.

0 Kudos
Message 15 of 25
(1,023 Views)

LabVIEW is only going to send a message to the stir plate if you tell it to.  A timeout is not going to cause any extra message.

 

Have you determined how long it works before it stops working?

 

Is this USB based and is it possible that the PC is turning off the USB port as part of some "power saving" mode?

0 Kudos
Message 16 of 25
(1,017 Views)

It is connected by USB, but I just checked and the computer is set to not turn off USB connections.  The code has run anywhere from 4 to 180 times before it quits so no pattern that I can pick up there.

0 Kudos
Message 17 of 25
(1,007 Views)

Am I to understand that this is using a USB to Serial adapter?  If so, LabVIEW is fussy when it comes to the chip set of the USB to Serial adapter, but I can't for the life of me, recall which one is okay and which one isn't.  It's just one of those days.  😕

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 18 of 25
(990 Views)

FTDI is the chipset that most people have reported success with.

Prolific is the chipset that most often comes up as being the problematic one.

 

Bill brings up a good point that didn't cross my mind.  Try a different adapter, particularly if the one you are using now is based on the Prolific chipset.

Message 19 of 25
(988 Views)

The stir plate connects via a serial connection to an NI USB 232/4 hub, which then connects by USB to the computer.

0 Kudos
Message 20 of 25
(960 Views)