Error: "BFFF0015 Timeout expired before operation completed."

[Kian]

Hi,

I downloaded the instrument driver from the NI website to control the Olympus BX2A series of microscopes thru a serial connection. I got the above error from VISA Read when I used the driver. I tried increasing the timeout period but to no avail. Seems like the PC couldn't communicate with the microscope at all. However, the PC is able to communicate with the microscope when I use another user interface provided by Olympus.

This is what I got from NISpy:

> 5. viRead (0x001A1018, 0x03A1F588, 1024, 0)
> Process ID: 0x00000F2C Thread ID: 0x00000804
> Start Time: 17:10:42.407 Call Duration: 00:00:02.003
> Status: 0xBFFF0015 (VI_ERROR_TMO)

Can anyone please help?

Thanks
Kian

[rolfk]

---

@Kian wrote:
Hi,

I downloaded the instrument driver from the NI website to control the Olympus BX2A series of microscopes thru a serial connection. I got the above error from VISA Read when I used the driver. I tried increasing the timeout period but to no avail. Seems like the PC couldn't communicate with the microscope at all. However, the PC is able to communicate with the microscope when I use another user interface provided by Olympus.

This is what I got from NISpy:

> 5. viRead (0x001A1018, 0x03A1F588, 1024, 0)
> Process ID: 0x00000F2C Thread ID: 0x00000804
> Start Time: 17:10:42.407 Call Duration: 00:00:02.003
> Status: 0xBFFF0015 (VI_ERROR_TMO)

Can anyone please help?

Thanks
Kian

---

From your error information it is a little difficult to see what might be the problem. One thing I can notice is that the Read function only took 2 seconds before reporting a timeout error. Depending on the communication link (serial, GPIB, TCP/IP) and the type of device this may be a little short. You specify the timeout usually at the beginning through a property node, after opening the VISA resource.

There is also a chance, that while the driver was developed with a certain type of firmware, your device has a different version, working differently in subtle ways. Or maybe if you use serial communication you use a wrong baudrate, data bit size, parity or handshake. Or maybe your device is configured to use a certain end of information character while the driver was written to use a different one, probably the factory default one.

Rolf Kalbermatter

[Poormanphysics]

Hello:

Did you solved this problem? You wouldn't believe this but at the moment of my search on this website I am debugging the same problem! I tried to work around with the timing issue by invoking the property node and adding more millisecond timing but I have the same problem! What I think is if you probe deeper into the matter we actually have a "write command problem" which I couldn't explain? I am driving our evaluation BX61 from a BX-UCB on it's serial port with the IX2 and BX2 NI drivers which I also downloaded recently as an attempt but I have no luck. Also, if you try to connect anything on the serial port while the controller is connected from the supplied BX2-BSW software it will disconnect automatically. The makers of Image-PRO and Scope-PRO (Media Cybernetics I think) an imaging software company that supports this series of microscopes has SDKs and DDKs for sale currently I do not or the lab don't have investment on them because we think IMAQ Vision is better but NI is short of supporting the drivers yet for this system I guess. There is another one supplying the Scope-Pro addons but not sure if they can also give the command set instructions for us to proceed making the custom driver.

Who ever replied to you before me must not know anything about the motorized microscopes were talking about here? I hope he has more concrete solutions to offer.

Let's discuss more because I am having the same problem right now.

Thanks,

Berns B.

[LoganS]

Magandang hapon Berns,

So let's take the hardware out of picture for a moment. If you are having both read and write problems, perhaps there is a problem with the connection itself. Can you successfully perform a loopback test with your serial port? Have you verified that it works without and with the cable that is connected to the microscope? If it's been a while since you've done a loopback test, I'll point you to a tutorial below. Please let me know if you are successful, and we'll continue from there.

How to Do a Serial Loopback Test

Logan S.

[Poormanphysics]

Hello Logan maayong hapon diha (now that is in Visayan for "good afternoon there", a language spoken 2/3rds of the country down South).

Being a teacher for a technical school sometime before elevating myself to university work this is one key principle I always tell my boys: Test before you plug! Yes, I did the exercise and I passed it with the VISA example right out of the box of NI. Funny thing is why am I actually loading when I piggyback another DB9 into another PC?

Something I found out before I went to this post is that Pin#1 and Pin#6 of the controller RS232C port is shorted (connected) and Pin#5 is as verified at GND. What does this tells me? The ports are looped handshaking is it? Now for me hardware beats any software so I'm wring up my piggy back cable into a breadboard where I have a logic analyzer waiting to catch that synch or missing handshake pulse when I connect my own simple Serial Config->Write->Read->Close test vi.

Your comments are certainly welcome.

Berns B.

[Kian]

Hello guys,

I have also successfully conducted the loopback test. I have also gotten the microscope sales rep to verify for me the parameters for calling the microscope.

I know very little, but noticed that the serial bytes received from the microscope is zero, while the driver has been programmed to read 1042 bytes. Perhaps the reason why zero bytes are returned has gotta do with the write command problem?? Please enlighten.

kian

[Albert.Geven]

Hi Kian

I guess that you don't send the end character that the other application is sending.
Try to add a lf or cr or even both as crlf and try again

You can add these characters in LabVIEW by concatenating the carriage return constant or the line feed constant or the End of Line constant from the string palette to your command.
These end characters are sometimes left out of the documentation.

Another possibility is to check what the other program is sending with portmonitor.exe
this program is freeware somewhere on the web.
One problem though is that this program only runs from a real hard drive (maybe even only from C:)
and surely not from a network drive.
You also have to start this program before you open the port in labview.

Success

[Poormanphysics]

Hello Kian:

What did your microscope dealer told you? Did he gave you anything about anything like DDK (Device Driver Kit) perhaps? That single document is what we need to specify string commands to the serial port you see. There are 3-5 software companies which support Olympus for their image analysis software and two of them I think write codes for automating the BX61 but for sure they are not willing to discuss anything on custom software we university people would like to code.

I notice a lot of bytes being written on the port (I made a T-tap on the pins and use a scope on TX and RX pins) using their BX2-DSW software it actually gave me the impression that there is no way for a VISA in LabVIEW to do exactly what the port is spitting out using Olympus software. It seemed that whoever wrote this has seen to it that the main program will have dependencies on at least 2-3 DLL files that wen't with the BX2-DSW software for it. I do not like the attitude of these suppliers not giving details on the driver for controlling the port using custom software while one has invested several hundreds and thousands of dollars for a research microscope?

Suggest you squeeze your supplier more for the communications protocols.

Regards,

Berns

[Poormanphysics]

Hello Albert:

The termination character is something I watch all the time since some experience I gained in GPIB programming at the lab. I really think the problem is at the read part? I see the bytes written into the port but somehow the controller does not recognize the protocol and I don't have bytes returning to me? However, using the hardware approach of probing the RS232C line on TX and RX pins I have noticed the first few bytes that is needed to initialize and connect my PC onlike with the BX-UCB controller for does so much and actually stays there with the same transmit byte all the time? It seemed to me that for an online connection to occur I have to do a lot of constant re-writing and re-reading of the control port but again NOT unless I know exactly what the protocol does I am helpless.

Anymore ideas?

Thanks,

Berns B.

[Ben]

Following up on and backing up what Albert said.

You could use Portmon or write your own code to watch what is being sent and recieved while the "other" software is running.

Pay close attention to timing and packet sizes.

AS you watch the data exchanged over the port start small with simple stuff. Get a handle on how the easy stuff is done.

Start throwing in more interesting operations and compare the difference with what you saw earlier.

If you get some data dumps together, share them here, there are alot of heavy weigths that can step in and help even if they do not know the details of the widget you are using.

Ben

BTW:
Rolf Kalbermatter is one of the great grand professors of LabVIEW. He taught many of those people that will step in to help you. Receiving a reply from Rolf is a special honor.