Bytes missing in serial communication UART - NI Visa READ

hello everyone,
                     I am using NI Visa read to transfer data from microcontroller to laptop using write-to-binary-file.vi... I have observed a very weird phenomenon, in the fact that some bytes appear to be missing from the data-file. this however, does not occur for all laptops... In some laptops, i have never observed a single byte being missed from the data file...
the OS running on laptop with byte missing is win 7, whereas the laptop running perfectly fine has win xp.
has anyone ever experienced such issue before? i am using Silicon Labs CP2102 as UART-USB converter over a baudrate of 921600 bps... the data size is normally in GB's... and the no. of bytes missing is purely random and varies from 2bytes to 32 bytes,... the way i determine if a byte is missing or not is by right clicking the file, check properties and compare size on disk and size of file ... they shud be same to ensure no data loss...
Now on LabVIEW 10.0 on Win7

Oh.. Created by mistake ,.. How to delete this post ???
Now on LabVIEW 10.0 on Win7

Similar Messages

  • Byte missing via Serial Communication

    Hi i am facing a prob of byte missing via serial communication.
    but for some application it's work fine.
    i am using net beans 5.5 ID

    the code that i am using is as under:
    public void connect() {
    ComChoose port = new ComChoose(); // Is used to select from diff port available in system
    CommPortIdentifier portId = port.getCommPort();
    System.out.println("portid"+portId);
    try {
    serialPort = (SerialPort) portId.open("Meter Parameter", 2000);
    } catch (PortInUseException e) {
    JOptionPane.showMessageDialog(this, e);
    try {
    inputStream = serialPort.getInputStream();
    outputStream = serialPort.getOutputStream();
    } catch (IOException e) {
    JOptionPane.showMessageDialog(this, e);
    try {
    serialPort.addEventListener(this);
    } catch (TooManyListenersException e) {}
    serialPort.notifyOnDataAvailable(true);
    try {
    serialPort.setSerialPortParams(4800,
    SerialPort.DATABITS_8,
    SerialPort.STOPBITS_1,
    SerialPort.PARITY_NONE);
    serialPort.setRTS(false);
    } catch (UnsupportedCommOperationException e) {}
    //Closing the serial Port
    public void closesr(){
    if (serialPort != null){
    serialPort.close();
    //Serial Event
    // &Ch[i] is the string array used to store bytes
    public void serialEvent(SerialPortEvent serialPortEvent) {
    switch (serialPortEvent.getEventType()) {
    case SerialPortEvent.BI:
    break;
    case SerialPortEvent.OE:
    break;
    case SerialPortEvent.FE:
    break;
    case SerialPortEvent.PE:
    break;
    case SerialPortEvent.CD:
    break;
    case SerialPortEvent.CTS:
    break;
    case SerialPortEvent.DSR:
    break;
    case SerialPortEvent.RI:
    break;
    case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
    // outputBufferEmpty(serialPortEvent);
    break;
    case SerialPortEvent.DATA_AVAILABLE:
    try {
    int numBytes = inputStream.read(readBuffer);
    for(int i=0;i<numBytes;i++){
    number =readBuffer[i] ;
    if(number<0){
    number=number+256;
    if(number==256){
    number=0;
    String r = Integer.toHexString(number);
    if(r.length()==2){
    ch1[k]=r; //K is an integer value defined globally K=0;
    } else{
    ch1[k]="0"+r;
    // System.out.println(ch1[k]);
    // System.out.println(k);
    k++;
    if(k >=200){
    System.out.println(k);
    k=0;
    serialPort.close();
    flag=true;
    } catch (Exception evt) {
    System.out.println(evt);
    serialPort.close();
    break;
    }

  • Data Missing in Serial Communication

    Hi,
    I am Communicating an Embedded Board with LabVIEW.Data is transfering in 1 Data per second priodically.Problem is Some data are missing in between.I am using simple serial read VI.Can any one suggest me a solution? Data Log file is attached.I crossed check with some other applications in that its working fine.
    :a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100 d) 328 e) 373 f:a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100:a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    :a) 329 b) 400 c) 100 d) 328 e) 373 f) 059 g) 816 h) 000 i) 000 j) 000 k) 01944 l) 000 m) --- n) 0000 o) 00 p) ---- q) --- r) --- s) xx.xx/xx.xx t) 0.35 u) 12
    Please Mark the solution as accepted if your problem is solved and donate kudoes

    Can you share some code?  It would help a lot if we could see how your program is put together.
    Is the embedded board using a termination character?  A termination character is something like an End Of Line character at the end of each message.  If it is sending it, then make sure you are not using the Bytes At Port function.  Just tell the VISA Read to read a huge number and the read will finish when that termination character is found.  This, of course, is assuming you enable the termination character in your program.
    My other guess is that you are constantly opening and closing the serial port.  DON'T DO THAT.  You should open and configure the port before your loop and close it after the loop.  You can send and read data inside as much as you want then.
    There are only two ways to tell somebody thanks: Kudos and Marked Solutions
    Unofficial Forum Rules and Guidelines

  • VISA Read and Bytes at Port Timing Question

    Hi,
    I have a question that doesn't seem to be documented in the VISA Read function help. My application normally queries a serial instrument, waits, and then reads the port (with Bytes at Port property node wired to the byte count input of the VISA Read). However, I also need to be able to handle strings received from the instrument asynchronously without my vi requesting any data. So in the False Case in my vi (the True Case is where I write a command to the instrument) I have a Bytes at Port property wired to the VISA Read function's byte count input without using a VISA Write. This works fine if the \r\n terminated string is sent in one packet. However, sometimes there is a slight delay (only a few milliseconds) between characters. When that happens, the VISA Read returns, but I don't get the entire intended string. (Of course I know I have to keep reading in a loop until I get the \n and then assemble the received characters (sub strings) into my complete string for processing.)
    This is my question: What is the time delay between characters at which the VISA Read terminates? This is not specified. I assume it could be as little as just slightly more than 1 stop bit at the baud rate being used. Does anyone know? NI employees?
    When a string of more than one character (byte) is sent, as soon as the stop bit time has expired, the next start bit is normally sent immediately. Is it possible that if the next start bit doesn't come by, say, the mid-bit position time at the baud rate being used, the VISA Read returns immediately? Or does it wait at least 1 character time (at the baud rate)? This should be documented. Furthermore, for future versions it might be useful to add an input to the VISA Read to specify in milliseconds how long to wait AFTER the 'byte count' number of bytes have been received before returning the string (or character).
    Thanks for your help.
    Ed

    I looked up the PC16550D data sheet (http://www.national.com/ds/PC/PC16550D.pdf). On p. 19 it says:
    When RCVR FIFO and receiver interrupts are enabled, RCVR FIFO timeout interrupts will occur as follows:
    A. A FIFO timeout interrupt will occur, if the following conditions exist:
        - at least one character is in the FIFO
        - the most recent serial character received was longer than 4 continuous character times ago (if 2 stop bits are  programmed the second one is included in this time delay).
        - the most recent CPU read of the FIFO was longer than 4 continuous character times ago.
    The maximum time between a received character and a timeout interrupt will be 160 ms at 300 baud with a 12-bit receive character (i.e., 1 Start, 8 Data, 1 Parity and 2 Stop Bits).
    B. Character times are calculated by using the RCLK input for a clock signal (this makes the delay proportional to the baudrate).
    C. When a timeout interrupt has occurred it is cleared and the timer reset when the CPU reads one character from the RCVR FIFO.
    D. When a timeout interrupt has not occurred the timeout timer is reset after a new character is received or after the CPU reads the RCVR FIFO.
    So, this UART uses 4 character times to determine that no more characters are coming in. And the delay is baud-rate dependent. This makes sense because I see that at, say, 115200 baud I receive more "partial strings" than I do at 9600 baud (where the sending device has more time to send the next character)!
    Kudos for making me investigate this further! Thanks for listening. Hope this may help others in the future.

  • 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?

  • UART and/or serial communication

    Hello, Labview Experts,
    Our sensor node uses UART protocol to communicate.  We are able to convert it to serial signals.  Does anyone know how we can manipulate serial communication in LabVIEW?
    Thanks,
    ck

    Use the VISA vi's. Search for serial and VISA in the labview examples.

  • VISA bug with serial communication on MAC !

    Hello to you all again,
    I have appreciated all feed back from you about a problem encountered with serial communication on the MAC (see earlier questions)
    To situate the problem:
    One can only read 63 bytes back from the serial port using VISA calls (without handshaking). With the old serial VIs you can read everything back. In addition the exact same VIs do not show this problem on windows platform.
    I have now performed extensive tests with a loopback on the serial port and the problem still stand.
    I attach two VIs to an answer to this question (for some obscure reason I can not attach them to the question?) which do the basic loopback, one uses VISA the other the old serial VIs. Please try them out o
    n your computer (for Mac RS422 miniDIN you should connect pin 3 to 5 and 6 to 8 to do the loopback)(for windows RS232 DB9 connect pin 2 to 3) in loopback configuration (see also resource library).
    Please post a message if the described problem also occurs on your MAC.
    Thanks to all of you for your cooperation!!

    here are the VIs a promised
    Attachments:
    serial_loopback_test.vi ‏65 KB
    visa_loopback_test.vi ‏70 KB

  • 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

  • To read 512 bytes using serial communication

    I want to read 512 bytes of data using rs 232 with the timeout of 30ms. I am using "Serial read with timeout -Palm.vi". Is there a limitation of the number of bytes I can specify to this VI?
    Thanks!!
    Attachments:
    Serial_Read_with_Timeout--Palm.vi ‏63 KB

    Hi software enigineer,
    It is not possible to transfer 512 bytes per 30 ms here. To do this would require a baud rate of 136533 (512*8/.03) and the maximum possible baud rate is 115000. The recommend baud rate for a serial transfer is 9600, which would mean transferring at most 36 bytes if the timeout is kept at 30ms. Moreover, there is usually some overhead involved in serial communication, and I would recommend sending a little less than the maximum 36 bytes every time too.
    On another note, I noticed that in your block diagram, you are using the Bytes at Serial Port vi. Definitely use the output of this vi to determine how many bytes to read at a time and read the bytes as they become available in the serial buffer rather than reading in a large buffer
    all at once. Continuously read and append the output until there are no more bytes to be read or until the termination character is read. This will avoid any lost data transmission due to overflow.
    Good luck with your program!
    Kileen Cheng
    Applications Engineer
    National Instruments

  • Intermittent Extra Serial Byte in Visa Read

    Hello All,
    I'm hoping you can help me with a problem that I've been having. The background:
    Using a microcontroller to to gather data from various sources and sending all the data back to Labview via an FTDI virtual COM port. The different types of data sent back in one chunk has a three byte header that tells me (in an abstract way) how many bytes are following for that type of data. This repeats until all the data sources are exhausted and all the data is received. However, occasionally, there is an extra byte in the buffer, which then pushes the headers out of whack and has me looking for bytes that aren't there. I'm attaching screen shots of the serial port config and of the serial port read vi's. I've tried flushing the buffer before I do a data acquisition and ask for data, but sometimes the extra byte happens inside data stream, so again it pushes the headers out of place.
    I have a secondary COM port output on the microcontroller that echoes the data being sent to Labview and is connected to a second PC that is capturing the data. The data is in binary format. I have disabled the termination character requirement from the receive buffer, but enabled it for the transmit (as you should see from the setup). When I review the logs of the captured data on the second PC, the microcontroller is not sending the extra byte. It appears that even though Labview reads the byte from the buffer, it remains there SOMEHOW or I could be way off and it's a bug in my code. I'm hoping that you can help with perhaps seeing something that I'm not seeing.
    As for my serial buffer read, I do recognize that I don't have a timeout in the event that the number of bytes to read exceeds the total bytes in the buffer, this has actually been beneficial in helping with capturing the error as it happens. I didn't use the Bytes at the Port property because speed is important and this property is notoriously slow. Also, that really wouldn't solve the extra byte problem.
    This the serial read vi
    This is the Serial Port Setup
    Attachments:
    Serial Port Setup.png ‏81 KB
    get data.png ‏186 KB

    teejimenez wrote:
    The initialization only happens once when the program starts. There is of course a close VISA session vi used later, when I'm done with the test.
    No! The Initialize Serial Port is inside the loop and executeded on every loop iteration.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Visa error handling in serial communication

    Greetings,
    I have a problem with the serial communication in my Labview program.
    I have made an application that reads from serial port, searches for beggining characters, and later counts data after that beggining characters into variables in Labview program.
    Everything work fine, but problem starts when I unplug the device from computer.
    Program blocks and I could not do anything. Even Visa Close does not do anything.
    I need to restart my computer to make my application works.
    I made some indicators in subVi, and I see that when I unplug the device the error from READ VISA changes.
    My question is:  How to handle this event(error) to restart or unblock my serial device.
    I am attaching a SubVi, that searches for starting characters " KBON,"
    Best regards,
    Chris
    Attachments:
    find_start.vi ‏12 KB

    Hi Chris,
    From the standpoint of VISA capabilities, you should be able to programmatically handle the desconection of the serial port. I am however not certain that your specific serial port hardware is OK with that.
    As to how to handle disconnection using VISA:
    I recommend using the "timeout" pin of the VISA Configure Serial Port VI
    when the timeout is reached and no data is transferred, you will get a timeout error on the error wire.
    You can then programmatically handle this error case in your code in a very similarly to this example.
    I recommend experimenting to see what error codes your application throws, or alternatively you can use the VISA error codes documentation to create the case structures needed to hande these errors.
    In all cases, you should close the VISA reference. Leaving the serial port rescource "open" in your operating system may be the reason why you need to restart your computer every time (as restarting will for sure free up the serial port rescource).
    Best Regards,
    T Simon
    National Instruments
    Applications Engineer
    Certified LabVIEW Developer - Certified TestStand Architect

  • 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 problem from a PIC24's UART port

    Thanks for taking the time to read my post.
    I am using Labview 8 on Win XP CPU 3.4, 2GB RAM PC.
    I am using a microcontroller PIC24 (on the Explorer 16 development board), which I have programmed to acquire an AC singal at a rate of about 4 kHz. The PIC24 has a 10bit ADC and the acquire value is then padded to16bits in total (format: 000000xxxxxxxxxx).
    The serial setting for the pic and my Labview program are 115200, 8 data bits, no parity, 1 stop bit.
    In order to send the acquired value to my PCs serial port (Remember UART = 8-bits of data only) I divide the 16 bit word into MSB and LSB. I then send the MSB and LSB 8-bit value one after the other.
    The total data rate for this communication is about 64kbps.
    The problem is that when I run the code I have written in Labview the CPU usage shoot up to 70% and I also see buffer overruns (a non continuous sine wave). If I a time delay in my while loop the buffer overruns increase.
    Also if I try and use the ‘bytes at port’ VI the data I get is meaningless.
    I would be grateful if someone can look at my code and give me some suggestion as to how I could make the ‘Visa Read’ VI more efficient.
    Regards
    Alex
    Attachments:
    Serial Client for PIC24.vi ‏101 KB

    Dear all,
    I do not know if you have been following my post, but I am still getting buffer overruns (a non continuous sine wave) when using VISA Serial Read.
    The only way to avoid this, is by making the VISA Read VI, read 2-bytes at a time (with no time delay in the main while loop). However, when I do this I see the CPU usage shoot up to around 60% (which is something I would expect anyway, as the main while loop is executing as fast as possible).
    I have attached the working code below and would appreciate ANY comments BIG or small.
    I am still puzzled as to why when I connect the ‘Bytes at Port’ Property Node, the data I get is not correct.
    I have gone through the Labview Examples, as well as the LV Basics 1 course examples (which are similar) and I have also looked in the Labview for Everyone / Labview Graphical Programming books.
    However, I have found the examples to be far too simple, for what I am trying to achieve.
    I am seriously thinking of purchasing the LV Instrument Control Self-Paced Course, but I am not quite certain this would help me much. I have read the Course outline provided by NI, but this did not provide me with more valuable information.
    Can anyone that has ‘done’ this course advice me as to whether the material contains info on ‘high’ speed acquisition using VISA Serial Read/Write?
    The course is slightly price at a cost of around £240(with academic discount) and as far as I understand the courses examples (might) use two HP instruments (Multimeter and Function Generator) and a Tektronix oscilloscope, all of which I am not in direct contact with.
    Regards
    Alex
    Attachments:
    Serial Client PIC24-Serial - Read 2-bytes.vi ‏42 KB

  • OBD1 ALDL communication with Labview VISA

    Hello all,
    I am new to serial communication with labview.
    Task:
    trying to send a command and receive data from a 1987 corvettes ECM using VISA serial block in labview.... and failing hard
    Troubleshooting the problem:
    Hardware: works with EFI live V4 (software that communicates with cars), send and receives data all day long, so my hardware is not the problem
    software: it is something i am doing wrong in my coding
    Example code form EFI live V4:
    37:30.137: Send: $80,$57,$01,$00,$28
    37:30.137: Finished writing frame
    37:30.137: Wait 10 ms after writing, before reading...
    37:30.147: Start reading frame
    37:30.147: Aldl frame header byte: $80
    37:30.147: Aldl frame length byte: $57
    37:30.147: Recv: $80,$57,$01,$00,$28
    37:30.147: Finished reading frame
    37:30.147: MAX232 echo: $80,$57,$01,$00,$28
    37:30.147: Wait 10 ms after writing, before reading...
    37:30.157: Start reading frame
    37:30.160: Aldl frame header byte: $80
    37:30.160: Aldl frame length byte: $95
    37:30.241: Recv: $80,$95,$01,$1E,$5B,$00,$00,$00,$00,$00,$44,$44,$1D,$00,$9C,$D6,$00,$00,$FF,$66,$00,$80,$80,$00,$80,$64,$80,$FF,$00,$80,$00,$27,$27,$00,$00,$00,$77,$00,$3A,$00,$43,$00,$00,$00,$00,$00,$00,$00,$00,$01,$BD,$00,$00,$00,$00,$00,$00,$D5,$2A,$22,$00,$07,$00,$00,$0C,$00,$DE
    37:30.241: Finished reading frame
    Example code protocol i tryed into the visa block in labview:
    $80,$57,$01,$00,$28
    $80,$57,$01,$00,$28\n
    $80,$57,$01,$00,$28\r\n
    $80$57$01$00$28
    $80$57$01$00$28\n
    $80$57$01$00$28\r\n
    80 57 01 00 28
    80 57 01 00 28\n
    80 57 01 00 28\r\n
    8057010028
    8057010028\n
    8057010028\r\n
    VISA read Result:
    i just get an eco back of the same command i sent
    Question:
    is there something simple i am missing in the command protocol or a possible setting i am overlooking?
    also what is the purpose of the “$” in the Hex command?   
    background info:
    vehicle : 1987 corvette
    ECM type: 16198259
    com. protocol : ALDL OBD1
    labview v8.5
    baud rate: 8192
    data: 8 bit
    parity: none
    stop: 1
    buffer size: 256

    Are you actually supposed to be sending hex? You need details on the actual format of the data. I don't think viewing the output of some other program will tell you what is truly being sent and received unless its a sniffer such as portmon.
    You can right click on the string control and select hex display. You also did not include the actual VI so no one knows if you have it set to send \r and \n correctly.

  • Serial communication crashes with blue screen

    Hello,
    I have been troubleshooting an application that consistently kept crashing/hanging after ~1 to 5 minutes. I am communicating with a syringe pump NE1000 from New Era (http://www.syringepump.com). If have finally isolated the problem to a VISA write function.
    Configuration:
    ·         DELL INSPIRON running Win7 64 Bit
    ·         LabVIEW 2011SP1
    USB to Serial RS-232 Adapter [ GUC232A ] http://www.iogear.com/product/GUC232A/
    ·         The driver for the GUC232A has just been updated to the latest version, but the same behavior was observed with the older driver dating back to 2009.
    ·         RS232 to “telephone cable” adapter:
    ·         Telephone cable to RS232 port on syringe pump
    I was running the NI Desktop Execution Trace Kit while running the attached Test NE100X – Query Volume.vi. The log is attached, Trace Test NE100X - Query Volume vi (1_4_2013 _ 17_06_11_423180).ttd.
    When I run the vi at a loop rate of 10ms, it hangs after 15889 events. (Occasionally, Win7 crashes with the Blue Screen of Death.) I did not find anything unusual in the trace report.
    After the vi hangs, it becomes unresponsive. When I attempt to exit LabVIEW, I get the Resetting VI: … message, and LabVIEW is hanging and does not exit:
    If I decrease the loop rate to 50 ms and 75 ms, the vi seems to be running longer, but still crashes after about 52000 events, or 25000 events,respectively. At a loop rate of 100ms, it is was running for 51 min and then I had another Blue Screen Windows crash.
    What confuses me is that the system just hangs without giving me any timeout or error message. This makes the troubleshooting very difficult. A query rate of 10 Hz seems to be rather low. I wonder whether this is a hardware issue or some bug in the software. I appreciate your help in troubleshooting this issue. Thank you.
    Solved!
    Go to Solution.
    Attachments:
    Tech Support Inquiry.zip ‏781 KB

    Hi
    I can see several potential problems with this code. It looks as though what you are trying to do is to send a "DIS" command to the syringe pump and are then trying to read the data that the syringe pump sends back in response to this command.
    1. How many bytes are you expecting to get back in response to the DIS command? You're attempting to read 1024 bytes. If you really are expecting 1024 bytes then you need to calculate how long that would take to arrive. If we assume that you're using a data word consisting of 8 data bits, 1 stop bit and no parity then the number of bytes you will receive per second = 19200 / (8 + 1) = 2133. Therefore 1024 bytes will take 1024/2133 seconds = 0.48 sec. Therefore there is no point having a loop rate of 10msec. 0.5 seconds would be better.
    2. You haven't included the vi that initialises the serial comms so I can't see what timeout value you've assigned. You need to check that it is greater than the time it's going to take for your data to arrive.
    3. If you're not expecting exactly 1024 bytes then you need a different strategy for reading back the data. Possible options are i) counting exactly how many bytes you actually do get and using that number in the byte count input, ii)reading data continuously in a small loop until a terminating character is seen. eg if a CRLF is returned at the end of the data, read continuously until you see this. I've attached a modified version of your vi that shows how to implement this last method.
    regards
    Mike

Maybe you are looking for

  • I need Firefox 3.6. How can I go back? I need it for a web-based software application that I use at work.

    At work (University of Texas at Arlington), I use a vendor-provided web-based application that requires Firefox 3.6. I've uninstalled Firefox and tried to install 3.6, but I got Firefox 6.0. When I start Firefox now, it sometimes automatically update

  • Imports Purchase

    Hi All Currently the imports POs are created by MRP. The planned delivery time and GR processing time are maintained. However the delivery date in the PO required by the customer is based on the Inco terms of the vendor. Also the shipment date,delive

  • Ireport 2.0 doesn't start

    hello everyone: i've just installed jdk1.5 on my pc.when using the java -version command on DOS,it's really the 1.5.0_12 that appears. the problem is that the java web start icon has disappeared on my start menu,not only that the ireport 2.0 applicat

  • BPE Processed IDOCs

    hi There there any log where i can get the status of IDOCs those have been processed through BPE other then sxmb_moni? Thanks Chandra

  • How can your phone support employees be that incompetent and still be hired?

    The number of people you have to talk to and the number of times you have to explain your issue is extraordinarily frustrating. I sign up for a time for a return call and then I am called outside of that time frame and told in a voicemail since I mis