madbutter

I have a Max-based application that sends serial data to a LED panel using a USB Serial Adapter. I ask my customers to pick the port assigned to the adapter from a umenu populated by sending the serial object the print message, which retrieves the open ports. Usually there is no harm in picking the wrong port, a little handshake routine times out if no data comes back from the LED panel and the customer is encouraged to try another port.

Except now I have noticed that my new PC has a built-in COM1 and COM2 port and that if I send my little ASCII handshake request using either of these ports I get an "error setting port attributes" error in the Max window and the serial object is hosed.

I have a test situation where I can use a splitter to send the data between two programs set to different serial ports on the same PC. When I use two instances of my Bray's Terminal program I can correctly transmit data back and forth, then change the port on one program to go to COM1 and send data (which does nothing) then switch the COM port back to the correct one for the USB serial adapter and the data transmission resumes. When I replace one of the instances of the Terminal program with my simple Max patch with a serial object, setting the port to COM1 generates the "error setting port attributes" error and then it is not possible to change the port to the correct one for the USB adapter. I need to close and reopen the patch. Interestingly when I do try to reset the port and send data, I can see that some data is transmitted, but it is all just a random-sized sequence of hex 00s, not the ASCII sequence I sent. Like the data is corrupted.

Is this a bug that Cycling 74 can look at? Does anyone know a workaround? The "close" message does not reset the serial object in this case, I need my customers to restart my application every time a port doesn't work? Other programs that uses serial data seem to have more robust error handling when sending data to a port that is not actually open. Anyone have any experience with this sort of thing?

I have a Max-based application that sends serial data to a LED panel using a USB Serial Adapter. I ask my customers to pick the port assigned to the adapter from a umenu populated by sending the serial object the print message, which retrieves the open ports. Usually there  is no harm in picking the wrong port, a little handshake routine times out if no data comes back from the LED panel and the customer is encouraged to try another port.
Except now I have noticed that my new PC has a built-in COM1 and COM2 port and that if I send my little ASCII handshake request using either of these ports I get an "error setting port attributes" error in the Max window and the serial object is hosed.
I have a test situation where I can use a splitter to send the data between two programs set to different serial ports on the same PC. When I use two instances of my Bray's Terminal program I can correctly transmit data back and forth, then change the port on one program to go to COM1 and send data (which does nothing) then switch the COM port back to the correct one for the USB serial adapter and the data transmission resumes. When I replace one of the instances of the Terminal program with my simple Max patch with a serial object, setting the port to COM1 generates the "error setting port attributes" error and then it is not possible to change the port to the correct one for the USB adapter. I need to close and reopen the patch. Interestingly when I do try to reset the port and send data, I can see that some data is transmitted, but it is all just a random-sized sequence of hex 00s, not the ASCII sequence I sent. Like the data is corrupted.
Is this a bug that Cycling 74 can look at? Does anyone know a workaround? The "close" message does not reset the serial object in this case, I need my customers to restart my application every time a port doesn't work? Other programs that uses serial data seem to have more robust error handling when sending data to a port that is not actually open. Anyone have any experience with this sort of thing?
Thx, Bob


serial object gets hosed after "error setting port attributes"