Visa Read Issue Code -1073807253 - myRIO - PmodGPS

I'm very new to LabVIEW. I'm a senior, so I have had two measurement classes that used data logging equipment. I have had my hand held twice creating new programs. I just bought my first myRIO and I'm trying to datalog gps at 10 hz.
With the help of a few on here, I have been able to switch the Baud rate (I believe) but now I'm getting the Visa read error code 1073807253
I have attached my full program, but below are screen shots of things I have changed. The initial program worked fine at 1 hz, so I know the problem isn't the code itself, but it relates to what I'm changing. I did a bunch of searching and I found this page http://digital.ni.com/public.nsf/allkb/F3E0621CB71AA16786256F970000FC57 that talked about adding a buffer in the system.
I added the pause but that by itself didn't do anything. So, then I completed the modification and added the buffer.
That still resulted in the same error. After doing quite a bit of additional research, I found where someone said they just ignored the error. So, I gave that a shot and added an ignore error code.
Now the program runs without throwing up the error, but it isn't running correctly and it isn't running at 10hz. See the NMEA coded is it now displaying below.
Anyone have any ideas? I'm really stuck on this one and I'm behind schedule on completing this project. Any help is greatly appreciated!
Attachments:
Main.vi ‏94 KB

Ok, So, I got ride of the buffer and error ignore and went back to what I was using before.
I added in the close and put in a new Visa Config. I connected the error out of the Visa close to the Error in of the Config. Do I need to do that?
As you expected, the time between samples is still 1 second. Thoughts?

Similar Messages

Error -1073807253 occurred at VISA Read in transient SR830.vi VISA: (Hex 0xBFFF006B) A framing error occurred during transfer.

Hi,
I am have written a program with labview to make transient c-v measurement using a stanford research SR830 lockin amplifier. The program seems to be runing fine, but sometimes it is givvibg an error:
Error -1073807253 occurred at VISA Read in transient SR830.vi
Possible reason(s):
VISA: (Hex 0xBFFF006B) A framing error occurred during transfer.
Error -1073807253 occurred at VISA Read in transient SR830.vi
Possible reason(s):
VISA: (Hex 0xBFFF006B) A framing error occurred during transfer.
but if I press ok, the program again starts running. What might be the poblem? BTW I googled a bit and I see that in the labview topic "RS-232 Framing Error with HP 34401A Mulitmeter" by pkennedy32 this is what is said about framing error:
""Framing Error" in an RS-232 context means a very specific thing - when the receiver was expecting a stop bit, the line was not in SPACE condition. This can be the result of:
1... Baud rate mismatch (although other problems would likely crop up first).
2... Data Length problem, If I send 8 data bits and you expect 7, the stop bit is in the wrong place.
3... Parity setting mismatch - If I send 7 data bits + parity and you expect 7 data bits and no parity, the stop bit is in the wrong place.
4... Mismatch in # Stop bits - If I send you 7 Data bits + parity + one stop bit, and you expect 7 data bits + parity + TWO stop bits, the second one might not be correct, although most devices do not complain about this.
But, I must say that this is the same com port setting that I use to measure c-v hysterysis, but I never gt this error there.
I attach the program herewith for your kind perusal. Please help me resolve this issue.
Thanks in advance.
Solved!
Go to Solution.
Attachments:
transient SR830.vi ‏94 KB
csac.vi ‏8 KB
sr830 initialize1.vi ‏15 KB

@Dennis Knutson you are right I checked the read indicator in backslash mode, and instead of a \n it is sending \r. So I changed the \n in my write strings to \r. But, if I keep the CLOSE VISA outside my loop instead of inside as you suggested, the termination character appears to come in the middle of the read string instead at the end. And since the read terminates at the \r so it is displaying some junk value before the \r, but if I put the CLOSE VISA outside the loop and play along with the bytes at the read buffer, I see the whole read string with the \r at the end of the string. But, whenever the values are in exponential form (when close to zero) like 6.938839 e-5, I always get a time out error whatever be the timeout that I put at the VISA initialize. And subsequently, if I stop the program and run it again the machine program hangs and I donot get any reading. Then after I close it again and start, sometimes it hangs for some more or starts working. If I put an arbitrarily large byte count at the READ VISA, then I always get the time out before the operation completed error.
@ Ravens Fan I have removed the CSAC VI altogether and taking the CH! And CH” reading separately, instead as one string. So, no more issues with that.
I use the control at the delay so that I can choose how much delay I want to set, and I use the math operation because I am using adding up the delay time to keep track of the time elapsed. Because in the end I have t plot a time vs. CH! And CH” readings.
I am not sure but probably I am making some silly errors. Please help me out.
Attachments:
transient SR830-2.vi ‏103 KB
sr830 initialize1.vi ‏15 KB

VISA Read timing issues

I am using an RS232 to control an older model Power Supply (OXFORD PS 120-10).
I have successfully written several VI's that all work, the only problem is that VISA Read takes WAY too long. I'm talking 10's of seconds to refresh. I need it have it refreshing in milliseconds or at least tens of seconds for the measurements we need. All of the VI's I have written have the same timing issue.
Attached is the most basic Serial Read/Write VI. Is there any way to improve the Read rate? Or might this just be an instrumentation issue. The strange thing is the Write commands work almost instantaneously (I can seem them on the instruments display).
Please help if you can, I've only been working with LabVIEW for a few weeks and am very must still in the learning process.
Thanks!
Solved!
Go to Solution.
Attachments:
READandWRITE timing test.vi ‏14 KB
READandWRITE timing test.vi ‏14 KB

Do you have the communications protocol for the power supply? If you do not have everything right, you will have problems with communications.
Tens of seconds is a clue that you may be getting timeout errors because the default timeout is 10 seconds. Try placing an inidicator on the error out wire inside the loop (after Read) to see if an error occurs on any iteration. The way you have the VI set up you only see the error on the last iteration of the loop.
You are writing a carriage return to the instrument. If it requires that, it almost certainly sends a carriage return with the response. (This is why I asked about the protocol). If the instrument sends a carriage return (or other termination character), then you should Enable Termination Character on the Configuration VI and set the termination character to the correct value. The default is line feed (hex A or decimal 10). A carriage return is hex D or decimal 13. You must wire the numeric value to the termination character input for any value other than the default. Then change the byte count value (at the Read input) to a number larger than the longest message the instrument will ever send, perhaps 100 or 500. The Read will end as soon as the termination character is received, regardless of the number of characters.
I suspect that this is the problem - the instrument sends fewer than 10 characters in most messages but does send a termination character.
Lynn

VISA Read over USB Problem: After a while the xBFFF0015 Timeout Error occurred

Hi,
I have trouble using labview with my non-NI USB device:
The device is an analog input DAQ board. I was able to setup communication with the board using a VISA driver specifically created for this board and direct FW calls using the product's firmware specification provided by the manufacturer.
This method has been working pretty good so far, but when I try to get large amount of data (64k samples @100ksps), the VISA Read returns the 'VISA: (Hex 0xBFFF0015) Timeout expired before operation completed.' error.
Please see the attached screenshot of the block diagram for details.
First, an 'analog input scan start' command is sent to the DAQ device, and then the vi tries to read all collected data from the device, once the right amount of data retrieved, or no more data is available the data collecting process (the while loop) ends and an 'analog input scan stop' command is sent to the DAQ device.
The data collection starts with no problem, but after a while, in loop# 400, the VISA Read hangs and then returns the error mentioned above.
I tried to increase the time out value, but it didn't help, the error occurred after the same number of loops, the VISA Read got hosed and the error occurred after the longer timeout expired.
I also tried to add some delays in the loop, but it didn't help either.
I am not sure what do I miss here and I would highly appreciate if anyone could give me some guidance how to solve this issue.
Thanks,
John
Attachments:
usb-read.png ‏18 KB

I just wanted to specify that this is not an NI board avoiding to make people think this is a hardware issue. And I think that the rest of the code is irrelevant in this case.
I believe that I don't use the VISA functions correctly. I assumed that someone who used these functions before would be able to point out the obvious steps missing in the data collecting process using the VISA functions.

Why do I get a "termination character was read" warning with VISA read and TCPIP?

I am using VISA Reads with TCPIP raw sockets without issue with NI-VISA 3.0.1 but when I moved to NI-VISA 4.4 I was getting timeout errors. The timeout errors went away when I set the termination character enable property to true (which seemed to be default in NI-VISA 3.0.1), but now I get a warning stating that the "termination character was read".
Can I disable this warning? Can I set the termination character enable to default? How can I get rid of this annoying warning?
Solved!
Go to Solution.

Hey Dagwood,
Unfortunately there isn't a way to globally change the attribute VI_ATTR_TERMCHAR_EN to VI_TRUE. I spoke with R&D about possible use of the registries and they say it's not accessible through that. To address why this change was made, the developer who made the switch isn't around anymore so I can't find his reasoning as an explanation for you. The best this for you to do in your code would be while initializing, use the VISA Property Node to make the change and until that VISA Resource is closed, this change will remain set to the value you assign. I'm sorry we cannot provide any other solution for this inconvenience. Also, if you feel this is a large burden on your programming practice you can definitely submit a product suggestion for the ability to change global default values for VISA attributes.
Thanks,
David Pratt
AES - Test Side Products
NIC

Increase speed visa read write

Hi guys,
I am using the visa read and write example, but I am facing some issue when using it in a larger software, and I can only receive date when the vi has been slown down (using the lightbulb).
The programme definitely works on it own with the settings defined.
Therefore, do you have any ideas/suggestions on how to increase the speed of this vi (attached) significantly? Also, it seems to create an issue with the data read
Many thanks,
Kentmey
Kentmey
Solved!
Go to Solution.
Attachments:
Read and write.vi ‏22 KB

How are you using this code inside of another VI? If you are actually calling this VI, there needs to be some changes.
1. The port should only be initialized once at the beginning of your program and clsoed once at the end.
2. There shouldn't be any need for the bytes at port. You are set up to use a termination character. So just set the number of bytes to read to something really large (like 50 or 100) and let the VISA Read stop when it finds the termination character.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

VISA Read Losing Characters off the end of the output string

Hi,
So I am writing a VI to take an output string of data from an ardunio Uno and parsing it. I am using the Read Visa vi to grab the string from output of the device. In the end I will be connecting a device that actually gives value in this type of string format : (#80212164,2289,2292,2296,2300,2328,2289,2297,2290,2300,2308,2292,2295,2298,2289,22,24,0*).
So after a large number of loops, the program starts to drop the last few characters of the string that it outputs. So the string output from Visa Read will read something like (#80212164,2289,2292,2296,2300,2328,2289,2297,2290,2300,2308,2292,2295,2298,2289,22,24,). The only way to fix this problem after it has occured is to completely close labview (all the way). Once I open it again and start running the program, all is fine in the world.
Anyone ever have this issue? I have been trying to debug this in different ways and the only weird symptom that I have other than the Visa Read function losing a few characters of the string is the fact that looking at the Bytes at Port after I Visa Read, is that it starts showing five bytes instead of zero.
attached is my most recent attempt at solving this issue.
Note: The Ardunio outputs a string of this format every 2 seconds with the values being incrimental over a specified range.(#80212164,2289,2292,2296,2300,2328,2289,2297,2290,2300,2308,2292,2295,2298,2289,22,24,0*)
Solved!
Go to Solution.
Attachments:
Ardunio(StringOutput).vi ‏36 KB

So i did a long data collect and It looks like ever 43minutes and 24 seconds the system goes from cutting off the last 5 characters to not cutting off the last 4 characters.
As I cant see how Labview would be causing that, I am going to try and dig into the Ardunio and solve that issue... hopefully when thats done I can simplfy my code like you guys pointed out.
Thanks!
Attachments:
overnight_11_18.csv ‏3001 KB
Overnight.png ‏146 KB

Serail port visa read

Hi all,
I'm using Labview 8 and communicating with the serial port and GPIB.
I'm receiving string "d" continuously in Visa read and want to compare it, as can be seen in my code. Whenever I read string "d" I want to initiate the structure for GPIB loop. Unfortunately I'm able to see a line of "ddddddddddddddddddddddddddddddddddd..." in my read string indicator but when I compare it with "d" using boolean eual to operator, I get FALSE!
Can anyone figure what is the problem,
Looking for help,
Regards
Attachments:
final_mod-1.vi ‏112 KB

The output of the Match Pattern is a signed integer. If what you're looking for is not found the "offset past match" is -1. The documentation states this. In general, you would use it as shown in the attached image.
That said, just so I get this straight, since I've noticed in your posts you tend to only give partial information which negate previous suggestions. You have a big while loop set up in which you're building a bunch of commands and you send them out to the PIC. The last one you send is "s". You then read from the serial port. I'm assuming you're expecting to see a "d" there to indicate that the PIC is done with the set of commands that you've sent? Regardless of what's on the serial port, you then go around the loop again and do the same thing. What happens if you don't receive anything on the serial port from the first iteration? You would merrily go around the loop a second time sending out the commands as before. Presumably this means the PIC goes through another processing phase, at which point you may get the "d" from the first set of commands. Don't you want to wait until you get a "d"? Why issue the commands again if you have not verified the PIC has completed its task?
You said "The delay kept inside the while loop can be adjusted so that structure loop executes fully before next "d" comes in." What delay? Are you talking about the 4.333 wired to the "Wait" function? If that's what you're referring to, that's not going to give you the delay you want, because that can execute at any time since you have no data dependency on it. In fact, it can execute while you're creating your commands. When is this delay supposed to happen?
Message Edited by smercurio_fc on 06-01-2007 03:58 PM
Attachments:
Example_BD.png ‏2 KB

The vi is identifyng the number of bytes to be read but the VISA Read vi is not able to read the data from the port.

We are trying to communicate with the AT106 balance of Mettler Toledo.The VI is attached.
We are sending in "SI" which is a standard command that is recoginsed by the balance. The balance reads it.The indicator after the property node indicates that there are 8 bytes available on the serial port. However, the VISA read VI fails to read the bytes at the serial port and gives the following error:
Error -1073807253 occurred at VISA Read in visa test.vi
Possible reason(s):
VISA: (Hex 0xBFFF006B) A framing error occurred during transfer.
The Vi is atttached.
Thanks
Vivek
Attachments:
visa_test.vi ‏50 KB

Hello,
You should also definitely check the baud rates specified; a framing error often occurs when different baud rates are specified, as the UARTs will be attempting to transmit and receive at different rates, causing the receiving end to either miss bits in a given frame, or sample bits more than once (depending on whether the receiving rate is lower or higher respectively). You should be able to check the baud rate used by your balance in the user manual, and match it in your VI with the baud rate parameter of the VISA Configure Serial Port VI.
Best Regards,
JLS
Best,
JLS
Sixclear

Visa Read Timeout Occurs with multiple Reentrant VI Calls

I have written a test application in Labview (6.1) which will be used to test (burn-in) up to 15 serial instruments through a 16 Port USB->RS232 Hub. Here's how it works:
When the App loads, I am transmitting a Connect command to each of 15 com ports (one-at-a-time) using VISA. If I receive the proper response from the unit on that port, I add the port to an array and continue on to the next system. Once I've found all systems on the hub, I wire my array of active Visa references to a for loop in which I open up to 15 reentrant VIs which will run in the background in parallel. Each of these reentrant VIs (all are idential with the exception of the Visa Resource they use) running in the background are sending commands to the the respective instrument and receiving a response. One Function in particular "Get Unit Status" is important and the response determines whether or not the instrument is functioning correctly. Here's the problem -- In my Main Loop, I am continuously acquiring indicator values from each of the reentrant VIs that are running in the background. After a period of time (not consistent) I will lose communication with a port (the symptom is no response from the unit). I've looked closely at the COMM engine I created and found that the Visa Write function is completing without error, then when I perform a Visa Read I immediately get the "Timeout occured before operation completed" error (please keep in mind that this occurs after 100-5000 successful attempts at writing/reading). Eventually another port will drop out, followed by another. This seems to stop occurring and the remaining systems run to completion without a problem.
Some background on what how I'm setting up my Visa Sessions...
When I originally scan for systems (before I load and run the Reentrant VIs)
- Init Visa Port
- 19200, 8, N, 1
- Use Termination = True
- Timeout = 400mS (I've tried larger values already) 400mS should be plenty
- Termination Char=13 (/r)
- Open Visa Session
- Visa Write "CONN18/r" (the command required to connect to my instrument)
- Visa Read with 1 for requrested byte count to read 1 byte at-a-time, concatenating the results until /r is received (or 1000mS timeout occurs -- this is not a VISA timeout) I've also tried 16 for requested byte count and just waiting for Visa to timeout -- both methods work.
Once all 16 ports are scanned I Close ALL of the ports using the Visa Close Function.
It is important to know at this time that I "AM" using proper wiring flow to ensure open occurs before write, write occurs before read, etc.
I'm assuming at this time that all of my Visa sessions are closed.
On to the Reentrant VIs:
Inside each reentrant VI I first Initialize all of my variables and Init/Open a 'New'? Visa session using the same parameters mentioned above.
Then I enter the "Run" case structure where all of the communication begins.
I am using the same Communications Engine to operate the instrument as before (the only difference being that all of the VIs in the comm engine are now reentrant and operate at higher priorities) I have actually saved two different versions of the engine (one for the reentrant calls and one for when I first scan for systems from my Main GUI).
When I init the reentrant VI, I am placing the Duplicate Visa Resource output of my Visa Open Function on a shift register. When I enter the Run case, it takes the Resource from the register on the left, wires through any Comm Engine Vis then back out to the shift register on the right and keeps going for a 12-hour period or until "Get Unit Status" has returned 60 naughty results.
On my Main GUI I am continuously (every 500mS) I am Getting certain Indicator Values from each reentrant VI AND I am also setting some control Values on each reentrant VI. There is no VISA interaction between each Reentrant VI, and the Main GUI.
As I said earlier, up to 15 systems will run for a time, then one will stop responding, followed by another, and another until a few remaining systems will run to completion.
Any advice as to why I'm encountering the timeouts with the VISA read fucntion as I have metioned would be appreciated. I managed to find one suggestion which uses the Bytes at Port function to ensure there is data at the port before doing a Read otherwise, skip the read and retry the whole operation -- I haven't tried this yet.
Sorry for the wordiness of my question. If anyone would like some screen shots of portions of my code (I can't submit the actual code because some of it is confidential) I'd be happy to post them.
Doug.

Hi Doug,
The first thing I would recommend is the solution you have already found, to check and see if there is data at the port before attempting a read. I would be interested to see if this will solve the problem. Does there seem to be any trend to which ports have this timeout error? How many ports does it cut down to before operation seems to continue as expected? Does this number vary, or is it always the same number of ports? I think the best thing to do will be to identify constant attributes of how the error is occurring so that we can narrow it down and see what is going on.
John M

How do I stop Serial "VISA Read" from giving me packets instead of available bytes.

Dear Labvillians,
Highlight:
How do I stop serial "VISA read" from giving me packets instead of bytes?
Background:
I have a system that serially publishes 14 byte packets on a semi-regular interval.
At busy times, the producer of these these packets queues the data, effectively producing super-packets in multiples of 14 bytes sometimes as large as 8 packets (112 bytes).
My protocol handler has been designed to processes bytes, packets or super-packets.
My application now has multiple devices and the order of message processing is critical to correct functionality.
My observation is that the VISA read waits until the end of a packet/ super-packet before passing the data to the application code. (See Plot Below)
My expectation is that VISA read should give me available bytes, and not get too smart for itself and wait for a packet.
I have observed this on PXI, Embedded PC, cFP and most recently, cRIO
I have experimented with the cRIO's Scan interface rate, which helps with reducing the packet backlog but doesn't resolve to sub-packet byte read.
I understand that one solution is to Write FPGA code to handle it and pass the bytes through R/T-FIFO, and there are some great examples on this site.
Unfortunately this doesn't help with non FPGA devices.
I have also dabbled in event based serial reads but it is diabolical on vxWorks devices.
Any Help is appreciated
iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT
Solved!
Go to Solution.

Sometimes Talking to yourself is helpful.
I hope this is a useful Nugget for someone in the future
iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT

PS CS3, Camera Raw 4.6 Update and Nikon D810 NEF File Reading Issue

Currently Have Photoshop CS3 & Adobe Bridge CS3 2.1.1.9.
According to Adobe, Camera Raw 4.6 supports Nikon D810 NEF files. I have downloaded Camera Raw 4.6 Update. When
I try to open Nikon D810 NEF files, I get Photoshop CS3 error that says
"cannot complete request your because it is not the right kind of
document. These NEF files wont open in Adobe Bridge at all. What am I doing wrong?

Hey,
Before I purchased, let me get your thoughts on another option that just occurred to me which involves:
1)Editing my D810 NEF files in LR 5.6, which I have, then exporting/saving the edited files as JPEGs.
2) Doing any additional editing, as necessary (i.e. that might require layering or selections..etc) , with the JPEGs with Bridge or PS CS3.
This method wont involve any additional software purchase now.. right? Am I missing anything. here? Since my final output to my customers are JPEGs any way, wont this work? Will I be at any disadvantage. Am I missing anything. here?
From: ssprengel <[email protected]>
To: charles cash <[email protected]>
Sent: Monday, October 6, 2014 9:49 AM
Subject: PS CS3, Camera Raw 4.6 Update and Nikon D810 NEF File Reading Issue
PS CS3, Camera Raw 4.6 Update and Nikon D810 NEF File Reading Issue created by ssprengel in Adobe Camera Raw - View the full discussion
You can buy it from here:
http://creative.adobe.com/plans
Please note that the Adobe Forums do not accept email attachments. If you want to embed a screen image in your message please visit the thread in the forum to embed the image at https://forums.adobe.com/message/6795004#6795004
Replies to this message go to everyone subscribed to this thread, not directly to the person who posted the message. To post a reply, either reply to this email or visit the message page:
To unsubscribe from this thread, please visit the message page at . In the Actions box on the right, click the Stop Email Notifications link.
Start a new discussion in Adobe Camera Raw by email or at Adobe Community
For more information about maintaining your forum email notifications please go to http://forums.adobe.com/thread/416458?tstart=0.

VISA read in exe file is not working

Hi all,
I am having problems with VISA read in an exe file created.
I am trying to write to and read from a programmable power supply via RS232. The VI writes a command to the instrument to set the voltage level. It then writes another command, requesting the resulting current value. This value is then read by VISA read
The VI is working fine on the development PC, which has LabVIEW installed. The exe file is also working fine on this PC. However, when I try to run the exe file on another PC (I've tried several) everything seem to work except for the VISA read functions. The voltage level command is sent, as well as the On and OFF commands, but the current is not read back.
I guess there must be something I have missed in the installation. I am working in LabVIEW 8.5. I have created an installer and included
Runtime Engine 8.5.1
VISA runtime 4.5
Is there something else I should do? I am really running out of ideas here...
I hope someone has a clue about this!
Clara

Clara-
1. Have you verified that the COM port settings in Windows (check under device manager) are matching how you initialize them (Baud, bits, parity, and flow control) and that these match the power supply's settings?
2. Also, are you trapping an error message after the attempted Read command (this will make it a lot easier to diagnose).
3. Do you programmatically close the VISA session at the end of the program?
4. You can always post the code to see if the forum members will catch the porblem.
~js
2006 Ultimate LabVIEW G-eek.

VISA Read function Read buffer problem in serial communication

Hi, I use VISA write and read function in serial communication app, the device continuously sends 0x00 if it is not receive a request from Labview program running on PC.
And the request sent by labview is programmable. I met a weird problem, each time the request changes, the VISA read buffer output port still shows the last request firstly, from second time, shows the right request.
It works like: Req code: ... 50, 51,51,51,50....; VISA Read buffer: ...50, 50, 51, 51, 51, 51, 50....
Please refer to the program.
Attachments:
readOne_test.vi ‏21 KB

How are you running this? You don't have a while loop around it. Is it part of a larger VI? Please don't tell me you are using the run continuously button.
You don't have any wait statement between you VISA Write and your bytes at port. So it is very likely the receive buffer is still empty since you didn't give your VI time to wait for the device to turn around and give a reply. If you read 0 bytes, your VISA read string will be empty. How does your decoder subVI (which you didn't include) handle an empty string?

NI VISA read stops at zero character, returning an 0xBFFF003E error

Hi
I’m trying to read some serial data from a UUT using the NI-VISA read function. The data is mostly text but does include some control codes. The first of these appears after the ‘OK’ in the Serial Bytes window on the front panel. More text should follow but for some reason, the read function stops at the first zero character (index 144 in the Byte Array), and returns an 0xBFFF003E (-1073807298) error. I found another thread where someone had a similar problem and I’ve tried the fix for this plus a few other things, but nothing’s worked. If I use Hyperterminal, the entire data block is returned as it should be.
I wondered if this was anything to do with the 7.1 version of Labview I’m using (upgrade is on the cards). The version of NI VISA I’m running is 4.2.
Very much appreciate any thoughts.
Thanks
Bruce

The error code itself is a generic VISA error which often happens with USB to RS-232 interfaces. Does your device connect to the PC through USB as a virtual COMM port? If so what chip and Windows driver is it using?
Also your function somehow looks wrong. The only criteria for the read loop to terminate is if there is an error on the VISA read or the Teststand termination status gets true. Generally if you use VISA Bytes at Serial Port you are almost always doing something wrong! That function does absolutely not synchronize with anything in your data. You will read whatever is there at that moment and that could be a partial message, no bytes at all (LabVIEW is typically many times faster than any serial device even if it is super high speed), or multiple messages.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Visa Read Issue Code -1073807253 - myRIO - PmodGPS

Similar Messages

Maybe you are looking for