Announcement

Collapse
No announcement yet.

Recover from Serial 4D Library reports error

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • dskogman
    replied
    The AltSoftSerial appears to have solved the problem with some rewiring of the pins. A few more errors are in the received data but nothing significant so I'll call it fixed.
    The USB issue was some kind error between the 4duino and Windows. Had to connect it to my Mac and download a simple program to reset it somehow.
    Thanks for the help . That was a strange problem and took way too much time to fix.

    Leave a comment:


  • dskogman
    replied
    I can't change the baud rate of the scale so I'm trying the AltSoftSerial now. I got it working but somehow my USB connection got corrupted on the PC. I'll continue to test and see what happens.

    Leave a comment:


  • tonton81
    replied
    Please note that in order to use altsoftserial as well, the current ITEAD library for the esp8266 officially only supports hardwareserial or softwareserial. You may download a supported version from here into your arduino's libraries. You must compile your INO sketch (supplied from workshop) in arduino itself as workshop compiles from the original ITEAD branch copy. This should get you up and running with altsoftserial. Let me know if you have issues.

    I added the attachment below for you.

    Erm sorry your not referring to the wifi softwareserial or just an extra serial? If you want an extra serial port omit what I said above and disregard this upload.
    If your having issues getting AltSoftSerial to work with pins 5 and 13, let me know

    Thank you

    Tony
    Attached Files
    Last edited by tonton81; 28 March 2017, 11:02 PM.

    Leave a comment:


  • Noel
    replied
    dskogman,

    I discovered that lowering the baud rate to 9600 of the software serial (mySerial) used to
    read the scale resolves the error. Another solution, is to use altsoftserial
    which can handle a baud rate of 19200 with no problem. However, please take
    note of the hardware pins used by altsoftserial since they are fixed.
    The pins for alsoftserial for arduino leonardo is compatible for 4Duino.

    For 4Duino, Transmit is 5 and receive is 13.

    Best regards,

    Leave a comment:


  • dskogman
    replied
    It's definitely some interaction with the Display and software serial after a period of time. I tested with no motors connected and no serial input and it ran fine. I then executed the different code paths using the buttons again with no motors or serial input and it ran fine. I then started the scale generating serial input and it failed after a short period. If I slow down the screen updates it runs longer but still fails and once it fails it does not recover. I also checked the temperature of the chips using an IR sensor and nothing was over 105 deg F.

    Leave a comment:


  • dskogman
    replied
    Go To, Break, Return will all work. There is no stack issue with any of them. They are all just a jump in the machine code in the end.

    I have run run this with and without power to the motors as stated above without any change in behavior. When debugging with the terminal the 4Duino is running off the USB connected to a laptop running off a battery which is effectively an isolated power source.

    Mark from your support team has duplicated it without any shields or servos as well so I fail to see any correlation with the issue.

    Leave a comment:


  • Noel
    replied
    dskogman,

    In your latest code, you used GOTO to exit the while loop, However, if you search
    the Web, you can see that many programmers do not recommend to use GOTO aside from creating
    spaghetti code, it is not used for structured programming. Exiting
    a while loop with out a BREAK instruction will cause a STACK
    overflow since the STACK was not updated by POPs when it exits the while loop.

    Equally important please understand that the motors are injecting electrical noise
    to the supply that is why the CMOS IC Particularly the ATMEL MCU is latching.
    You can verify this if the ATMEL MCU or the Picaso becomes hot once the error appears.
    As you know, your code runs perfectly without the scale and the motors.
    If you check the 4Duino Error log, you can see it occurs when a Dump Pan is executed. This is
    because, the SERVO Motors may not have clamping diodes.
    Please try the protection circuit and you can replace the battery with a power
    supply. The DC to DC converter is a switch mode power supply. The power supply
    in place of the battery may power power the motors and use a DC to DC converter
    ti isolate the 4Duino.


    bool read_scale()
    {
    bool found = false;

    // read scale
    nbytes = mySerial.available();

    while( nbytes > 0 )
    {
    ibuf[icnt] = mySerial.read();

    if(ibuf[icnt] == 0xA) // message terminator = /n
    {
    if( icnt == 16 ) //full message (16 instead of 17 since icnt not incremented yet)
    {
    ibuf[15] = 0; // strip CRLF
    Serial.println( ibuf);
    cload[9]=0;
    strncpy( cload, &ibuf[3], 9);
    load = atof( cload );
    ibuf[3] = 0;
    strncpy( scale_status, ibuf, 4 );
    found = true;
    Display.txt_MoveCursor(1,20);
    Display.print(F(" "));
    icnt = 0;
    }
    else //error
    {
    Display.txt_MoveCursor(1,20);
    Display.print(F("BAD"));
    Display.txt_MoveCursor(0,10);
    ibuf[15] = 0;
    Display.print( ibuf );
    Serial.print("Bad - ");
    Serial.println( ibuf);
    nbytes = mySerial.available();
    for( int n=0; n<nbytes; n++) // flush the buffer
    {
    mySerial.read();
    }
    icnt = 0;
    goto SKIP2; //<---------------- used GOTO to EXIT while loop, not recommended by programmers must insert BREAK
    }
    }
    else
    {
    icnt++;
    }
    nbytes--;
    }

    SKIP2:
    return found;
    }

    Best regards,
    Last edited by Noel; 25 March 2017, 05:12 PM.

    Leave a comment:


  • dskogman
    replied
    Thought that fixed it (work around not a fix) but it just took a lot longer to fail. Some kind of timing issue maybe, took out a lot of writes so it just takes longer.....

    Leave a comment:


  • dskogman
    replied
    Thanks for isolating it, does not appear to be some weird hardware interaction at least. I took all the Display and Serial writes out of the read_scale loop to eliminate interrupts (ACK/NAK) in the software serial processing. So far it seems to be running OK but maybe it just takes longer now. I'll run it some more and see what happens.

    Leave a comment:


  • ESPsupport
    replied
    If I change the start of read_scale() to
    Code:
    //    while( nbytes > 0 )
        if (!(millis() % 500))
        {
    //        ibuf[icnt] = mySerial.read();
            ibuf[icnt] = "ST,-00008.88 GN\r\n"[icnt] ;
    The the program pretty much runs forever.

    However, if I use the 'serial input' (actually a Programming cable with TX attached to sw serial's RX) to inject some bytes, with the above code still there, things can get broken again.

    So I suspect this has something to do with SW serial in some way, but I don't know how and it doesn't make sense as we have used sw serial lots of times before without this sort of issue.

    Leave a comment:


  • ESPsupport
    replied
    I set up your software stack on a 4Duino, with essentially nothing else connected. The display ran for a long time.

    I added some serial input to 'put' some data into the software serial port so as to simulate that part of the software and then I found I was getting errors occasionally.

    The errors, if I can describe them seem to revolve around these two lines of code
    Code:
        Display.txt_MoveCursor(1,20);
        Display.print(F("   "));
    The commands sent to the display are
    0xffe9 0x0001 0x0014 (Display.txt_MoveCursor(1,20))
    0xfffe 0x0020 0xfffe 0x0020 0xfffe 0x0020 (Display.print(F(" ")), or, as it is used 3 x Display.putCh(' '))

    When the error occurs this is what is sent
    0xffe9 0x0001 0x0014 (Display.txt_MoveCursor(1,20))
    0xfffe 0x0020 0x32 0x32 0x39 0x20 0x20 0x32 0x32 0x30 0x00 (Display.putCh(' '), followed by an ascii string "229 220")

    The movecursor seems to identify very closely the line of code being executed. Why arduino stuffs up sending the Display.print(F(" ") part way through, or the significance of the "229 220" (which changes but always seems to be of the format "nnn nnn") I have no idea.

    I will keep looking later

    Leave a comment:


  • dskogman
    replied
    It appears the Display errors start in the same place in the code although the timing is inconsistent. I added some additional logging and it is after the dump servo is run followed by the stepper motor and before the scale is read again.

    Update weight
    ST,+00007.10 GN <---- scale data read from software serial
    ST,+00007.10 GN
    ST,+00007.10 GN
    ST,+00007.10 GN
    ST,+00007.10 GN
    ST,+00007.10 GN
    ST,+00007.10 GN
    ST,+00007.10 GN
    Dump Pan
    24 07.10 19:44:07 3/23/17 <- history of last 10 runs
    23 07.34 19:43:44 3/23/17
    22 07.32 19:43:18 3/23/17
    21 06.98 19:42:41 3/23/17
    20 06.96 19:42:08 3/23/17
    19 07.22 19:41:47 3/23/17
    18 06.82 19:41:10 3/23/17
    17 07.06 19:40:41 3/23/17
    16 05.24 19:40:05 3/23/17
    15 05.24 19:39:49 3/23/17
    Loads Saved
    Dumped <--- servo finished run
    ST,+00007.10 GN <--- scale data read from software serial
    ST,+00007.10 GN
    ST,+00007.10 GN
    Stepper run <--- stepper finished run
    4D Err = NAK returned data= 21 <--- Display errors start
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    Bad - ST,+00007.10
    N
    Starting fill pan
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21
    4D Err = NAK returned data= 21

    Leave a comment:


  • dskogman
    replied
    Click image for larger version

Name:	IMG_6018.JPG
Views:	50
Size:	851.6 KB
ID:	56888
    Display after errors start

    Leave a comment:


  • dskogman
    replied
    I have attached a log of the debug output. It is every scale reading as well as button events for dumping the pan, running the stepper, running the vibrator, etc.You can see the overflows when the servos/steppers run and the recovery after. At the bottom you can see where the Display starts generating errors.
    Attached Files

    Leave a comment:


  • ESPsupport
    replied
    It's not clear how you can be so sure of that. Can you attach your full current code, so I can try and run it?

    Leave a comment:

Working...
X