debugging serial instability


    Jan 08 2020 | 4:57 pm
    Hi, quick question (with lots of details and specifics following): are there any tools or workflows for debugging usb/serial stability issues? (Windows 10, app built from Max 7) either in Max, external software, or is there something I can learn from Windows logs?
    I know there are about a million forum questions about serial errors, but I haven't been able to find any that cover the problem I've run into: initial correct operation, with delayed failure.
    I have a computer running a max patch for an art installation. It's been installed and operating correctly for 2 months, but in the last week, serial errors have begun occurring. Not at startup, but at seemingly random intervals through the day: sometimes 30 min, sometimes 5 hours.
    The error message isn't a lot of help: serial - error writing to serial port
    the serial object sends values every ~5 seconds. Once this error occurs, it continues to occur on every subsequent attempt to send values until I close and reopen the serial port in max with the following steps: -send "close" message to serial object. -get new error: "serial: error resetting port attributes" -send "close" message again -send "open" message
    I've hacked together a temporary fix that automates the above process using [error] and some [route] and [delay] objects, but I need to diagnose the underlying problem and find a true fix. Added complication: the installation is about 5000 km away. I have remote access to computer via teamviewer, but can't fiddle with the physical usb port/cable/etc. Any ideas appreciated!

    • Apr 22 2022 | 4:22 pm
      Hi, I'm having a very similar problem. I'm trying to use an arduino based sequencer with MAX. The serial communication works just fine from arduino to MAX but when I'm trying to send serial data from MAX (not even to arduino yet, just testing the serial communication with MAX console printing), MAX gets somehow jammed and starts banging "error writing to serial port"
      What I'm trying to do is to send metronome clock to arduino to light leds to indicate which sequenced note is being played. I'm using serial communication at 9600 baud. Tried with the default 4800 baud and it's a bit more stable. with @dtr 1 the serial is also a little bit more stable, but gets jammed in the way as DAILYTLJ explained.
      Anyone able to help?
    • Sep 02 2022 | 6:05 pm
      I have the same problem and need it to work for an art installation in two weeks! Did anyone find a solution for this problem?
    • Sep 04 2022 | 11:15 am
      Hi Django, this is not really an answer to your questions. I am merely sharing some thoughts and experiences. When it comes to installations that need to run (unsupervised) over a long period of time I usually avoid using serial connections. In general my recommendation would be, to see if there is an other protocol that you could use. Besides occasional stability issues that the serial protocol has, I find it also problematic because if accidentally unplugged the port usually needs to be closed, then reconnected and opened again. In this process the serial port may show up with a different ID on your computer. In that case ports need to be rescanned... These are in my experience too many steps for museum/gallery personnel and require some specialised technical knowledge. If possible you may want to consider if using e.g. MIDI or OSC is a viable option for your work. Both have the advantage that they reconnect automatically when unplugged and they are usually far more stable over a longer period of time.
    • Sep 04 2022 | 3:23 pm
      Your absolutely right Jan. I used Teensy 4.1s with ethernet connections for installations and it is a joy to work with.
    • Sep 10 2022 | 12:39 pm
      I’ve also found that - worst case scenario - you can usually reset (Close open etc) serial port in the background after a certain amount of time (using some logic to make sure nothing important is going through the serial port at the time). You can even make a stand-alone just with the serial object which you open and close with the shell object, and use udp to talk to it from your main patch.
      This doesn’t work in all cases but can be a solution if you’re in trouble. I’ve had installations running for years with serial objects doing this.