dailytlj

Hi, quick question (with lots of details and specifics following):

are there any tools or workflows for debugging usb/serial stability issues? 

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 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:

-get new error: "serial: error resetting port attributes"

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. 

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!

Hi, quick question (with lots of details and specifics following):
are there any tools or workflows for debugging usb/serial stability issue

debugging-serial-instability

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.

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?

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?

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.

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. 

Your absolutely right Jan. I used Teensy 4.1s with ethernet connections for installations and it is a joy to work with.

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.

Same problem. i have no problem with comunication from Arduino to Max , but if i try the opposite max print the same error message.

Same problem. i have no problem with comunication from Arduino to Max , but if i try the opposite max print the same error message.
- Arduino in port " f : COM6 "
- I use the object " serial f 9600 "

Can one track that serial problem to specific OS or Max version ?

I never had any problems on Mac, but was allways using either custom made USB cables in case longer ones were needed, and taking baud rate into account in that respect.

Interesting is that all reports state that it works for some period of time, and then suddenly starts droping out.

Would mean something has changed in the meantime,

or OS keeps some COM port logs which get corrupt ? who knows.

In case it is a problem of max serial object itself, it might be

worth trying jasch comport object instead, which also was allways reliable for me.

I never had any problems on Mac, but was allways using either custom made USB cables in case longer ones were needed, and taking baud rate into account in that respect.
Interesting is that all reports state that it works for some period of time, and then suddenly starts droping out.
Would mean something has changed in the meantime,
or OS keeps some COM port logs which get corrupt ? who knows.

In case it is a problem of max serial object itself, it might be
worth trying jasch comport object instead, which also was allways reliable for me.

debugging serial instability