Announcement

Collapse
No announcement yet.

TROUBLESHOOTING - Common Issues and their resolutions (ARDUINO and 4D Display)

Collapse
This topic is closed.
X
This is a sticky topic.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • TROUBLESHOOTING - Common Issues and their resolutions (ARDUINO and 4D Display)

    Hello All,

    We have seen our fair share of customers applications now and have a good idea of the common problems people encounter, so here is a bit of a list of things which can cause problems and their solutions, which might save you a bit of time.

    1. No Comms, Arduino will not talk to Display

    a) Check your Baud Rates are the same in your Arduino, and in the Display.

    b) Check you are using the correct Serial Port on the Arduino, and on the Display, so they match where you have actually plugged them into the two devices.

    c) Ensure you are not doing any Serial.prints or similar using the same Serial Port as you are using to talk to the Display. Depending how many you do and how often you do them will either make the comms not work at all, be extremely intermittent, or just cause slowness of the whole system. You cannot do Serial.print statements to the same serial port as you use to talk to the display. Big no-no.

    d) Ensure you have the Reset Code in your sketch, for the Arduino to reset the Display Module at startup, so the display and Arduino are in sync and both are in a known state. Without this code, your program may not work at all, the display may appear to be not communicating, or you may have seemingly slow comms. Please refer to the Demo which comes with the Genie Arduino library, and implement the Reset logic in your sketch.

    e) If you have a large program in WS4, you may need to increase the delay after your reset code in your setup() routine, from 3500ms to 5000ms or even higher. If the Arduino starts talking to the Display before the Display is ready, then it can flood the library and get the two out of sync and cause all sorts of grief.

    f) Depending on which Arduino you are using, will determine how many serial ports (UARTs) it has available. Arduinos like the Uno only have one Hardware Serial UART, and it is shared with the USB Programming port of the Arduino. So when you are programming the Arduino and you also have your display connected to Serial (Serial0), then you must unplug your display from the Uno in order to program it, or you will get a conflict and programming will fail. If you have a Mega2560 for example, it has 4 serial ports. By default the 4D Arduino Adaptor Shield uses Serial0, which is what the USB for programming uses on the Mega also, so if you want to change it to another Serial port, such as Serial1, Serial2 etc, then you can remove the jumpers on the 4D Arduino Adaptor Shield and place a jumper wire from the center pin of that header, into the desired serial pins on the Arduino headers. Please refer to our Application Notes for more information. There are so many Arduinos and combinations available, the Shield uses the Serial Port which suits the majority, however with a little creativity, it is possible to change the Serial Port quite easily, even to use Software Serial.

    g) Ensure you are only talking to objects which exist. You cannot have Arduino code talking to String0 for example, if String0 does not exist in your WS4 application. This will result in data being written to RAM on the display which is either unallocated, or allocated to something else, resulting in failed comms, corruption or weird behavior. Ensure you only write to objects which you have on the display.

    2. Corrupt Graphics on the display, or Red X's through gauges, Display restarting etc.

    a) Corrupt graphics are commonly caused by getting the Arduino to write to objects/widgets which do not exist on the Displays application. For example, if you are doing a genie.WriteObject to a LED Digit, say LED Digit 3, and you only have LED Digits 0, 1 and 2 in your application, then this will cause problems. You cannot write to something which doesn't exist. This can cause your entire program to fail!

    b) Red X's are caused by you writing something from the Arduino to the display, which is outside the range of what that object is configured to accept. For example, you are writing the value of 123 to an LED Digit which is only 2 digits long and can therefore only accept a value from 0 to 99.

    c) Your brand of microSD Card. Not all microSD cards are created equal. Some available on the market are cheap copies, and some are just not compatible with our display modules. Our modules (ALL of our modules) require microSD cards which are SPI compatible. This is why we sell microSD cards ourselves, as we know the manufacturer and buy direct from them. There are a number of brands of cards which just do not work, one in particular is Transcend. For some reason, virtually all Transcend cards do not work in our modules, and if they do they may not work for long. There are other brands also. Please stick with known good quality cards, or buy from us directly as our cards work.

    d) If you are using a larger display, such as a 4.3" or a 7.0", you need to ensure you are supplying enough power to the display. The 7.0" draws around 500mA of current at 5V just by itself. This is right on the limit of what most computers can output. If you have an Arduino connected to the same USB port, or you are trying to supply power to the Display via the Arduino using USB, then you are likely to run into problems of the 7.0" display restarting over and over. Either supply power separately to the display using the Arduino Adaptor Shield H2 (refer to its Datasheet), or supply power to the Arduino via its Barrel Jack. Take note that if you are going to use the Barrel Jack on the Arduino, don't put in a voltage over 12V as the Linear Regulator on the Arduino will have to dissipate all that heat and it will likely shut down. 12V may even be too high in some cases. Do the maths.

    3. Comms are slow, why?

    a) Check question 1 above

    b) Do you have any delays in your Arduino code? If you do, remove them. Delays are Blocking and prevent the display from talking to the Arduino as the Arduino is sitting in a paused state and not listening to anything anyone says. If the display is trying to send information to the Arduino when the Arduino is in a delay, the information will be lost. Depending how long the delay is, it can prevent the application working at all, or can cause the system to crash due to comms getting out of sync. If you need a delay, consider using the method descibed in the 'Blink without delay' example that comes with the Arduino.

    c) is the genie.DoEvents() function allowed to run every single loop, without restriction? This is the doorway for the Arduino to talk to the Display. This function must be allowed to run each loop so the library can then be relieved of its buffered communications from the display. Please, don't put delays in the loop and don't put this genie.DoEvents in some conditional statement unless you 100% know what you are doing.

    d) Try a faster baud rate, such as 200000 Baud, on both the Display and the Arduino. Depending how much information you are sending between the display and the Arduino, may warrant a faster baud rate.

    e) see g) above in section 1.

    This list will be updated as new 'problems' are discovered and solutions found.
    James
Working...
X