Gets confused about /dev/ttyUSB0 under linux

[dgtlmoon]

So when I click on the device in port list from chilipepper I get the error

2016/04/16 23:47:05 serial.go:606: Sending err back: We could not find the serial port /dev/ttyUSB0 that you were trying to apply the feedrate override to.

Full debug with -v here

2016/04/16 23:47:04 seriallist_linux.go:227:    .
2016/04/16 23:47:04 seriallist_linux.go:275: Final port list: [{/dev/ttyUSB0 FTDI FT230X Basic UART (ttyUSB0) [] DN010NRM 00 FTDI FT230X Basic UART 6015 0403}]
2016/04/16 23:47:04 serial.go:489: Got metadata on ports:[{/dev/ttyUSB0 FTDI FT230X Basic UART (ttyUSB0) [] DN010NRM 00 FTDI FT230X Basic UART 6015 0403}]
2016/04/16 23:47:04 serial.go:546: About to marshal the serial port list. spl:{[{/dev/ttyUSB0 FTDI FT230X Basic UART (ttyUSB0) DN010NRM 00 false false [] 0  [default timed nodemcu tinyg tinyg_old tinyg_linemode tinyg_tidmode tinygg2 grbl marlin] 1.88 0403 6015 0}]}
2016/04/16 23:47:05 hub.go:122: fro /dev/ttyUSB0 
2016/04/16 23:47:05 feedrateoverride.go:34: Inside spFeedRateOverride arg: fro /dev/ttyUSB0 \n
2016/04/16 23:47:05 feedrateoverride.go:39: [fro /dev/ttyUSB0]
2016/04/16 23:47:05 feedrateoverride.go:48: The port to write to is:/dev/ttyUSB0---
2016/04/16 23:47:05 serial.go:606: Sending err back:  We could not find the serial port /dev/ttyUSB0 that you were trying to apply the feedrate override to.
2016/04/16 23:47:05 feedrateoverride.go:34: Inside spFeedRateOverride arg: fro /dev/ttyUSB0\n
2016/04/16 23:47:05 feedrateoverride.go:39: [fro /dev/ttyUSB0]
2016/04/16 23:47:05 feedrateoverride.go:48: The port to write to is:/dev/ttyUSB0---
2016/04/16 23:47:05 serial.go:606: Sending err back:  We could not find the serial port /dev/ttyUSB0 that you were trying to apply the feedrate override to.
2016/04/16 23:47:05 bufferflow_tinyg_v2.go:141: Just forcibly asked for the fro status

but the device is alive..

[29957.666620] usb 1-2: new full-speed USB device number 6 using xhci_hcd
[29957.802160] usb 1-2: New USB device found, idVendor=0403, idProduct=6015
[29957.802167] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[29957.802171] usb 1-2: Product: FT230X Basic UART
[29957.802174] usb 1-2: Manufacturer: FTDI
[29957.802177] usb 1-2: SerialNumber: DN010NRM
[29957.805766] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
[29957.805840] usb 1-2: Detected FT-X
[29957.806406] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0

I've tried running the program as root, same deal.

Works totally fine with a serial program (minicom) at /dev/ttyUSB) 115200. never had a problem sending commands

Not sure where to go from here

[chilipeppr]

What version of SPJS are you using? These errors were updated to make you not scared. Regardless, these errors can all be safely ignored. Things should work fine. Aren't they?

On Sat, Apr 16, 2016 at 3:01 PM, Leigh notifications@github.com wrote:

So when I click on the device in port list from chilipepper I get the error

2016/04/16 23:47:05 serial.go:606: Sending err back: We could not find the serial port /dev/ttyUSB0 that you were trying to apply the feedrate override to.

Full debug with -v here

2016/04/16 23:47:04 seriallist_linux.go:227: . 2016/04/16 23:47:04 seriallist_linux.go:275: Final port list: [{/dev/ttyUSB0 FTDI FT230X Basic UART (ttyUSB0) [] DN010NRM 00 FTDI FT230X Basic UART 6015 0403}] 2016/04/16 23:47:04 serial.go:489: Got metadata on ports:[{/dev/ttyUSB0 FTDI FT230X Basic UART (ttyUSB0) [] DN010NRM 00 FTDI FT230X Basic UART 6015 0403}] 2016/04/16 23:47:04 serial.go:546: About to marshal the serial port list. spl:{[{/dev/ttyUSB0 FTDI FT230X Basic UART (ttyUSB0) DN010NRM 00 false false [] 0 [default timed nodemcu tinyg tinyg_old tinyg_linemode tinyg_tidmode tinygg2 grbl marlin] 1.88 0403 6015 0}]} 2016/04/16 23:47:05 hub.go:122: fro /dev/ttyUSB0 2016/04/16 23:47:05 feedrateoverride.go:34: Inside spFeedRateOverride arg: fro /dev/ttyUSB0 \n 2016/04/16 23:47:05 feedrateoverride.go:39: [fro /dev/ttyUSB0] 2016/04/16 23:47:05 feedrateoverride.go:48: The port to write to is:/dev/ttyUSB0--- 2016/04/16 23:47:05 serial.go:606: Sending err back: We could not find the serial port /dev/ttyUSB0 that you were trying to apply the feedrate override to. 2016/04/16 23:47:05 feedrateoverride.go:34: Inside spFeedRateOverride arg: fro /dev/ttyUSB0\n 2016/04/16 23:47:05 feedrateoverride.go:39: [fro /dev/ttyUSB0] 2016/04/16 23:47:05 feedrateoverride.go:48: The port to write to is:/dev/ttyUSB0--- 2016/04/16 23:47:05 serial.go:606: Sending err back: We could not find the serial port /dev/ttyUSB0 that you were trying to apply the feedrate override to. 2016/04/16 23:47:05 bufferflow_tinyg_v2.go:141: Just forcibly asked for the fro status

but the device is alive..

[29957.666620] usb 1-2: new full-speed USB device number 6 using xhci_hcd [29957.802160] usb 1-2: New USB device found, idVendor=0403, idProduct=6015 [29957.802167] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [29957.802171] usb 1-2: Product: FT230X Basic UART [29957.802174] usb 1-2: Manufacturer: FTDI [29957.802177] usb 1-2: SerialNumber: DN010NRM [29957.805766] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected [29957.805840] usb 1-2: Detected FT-X [29957.806406] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0

I've tried running the program as root, same deal.

Works totally fine with a serial program (minicom) at /dev/ttyUSB) 115200. never had a problem sending commands

Not sure where to go from here

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/chilipeppr/serial-port-json-server/issues/7

[dgtlmoon]

Ah sorry for the lack of obvious information there :) yeah so it's 1.88 as that's the compiled binary I can download. As soon as I click the checkbox - it unchecks itself and I see that warning/error (with -v)

[chilipeppr]

That error is meaningless and is not why it unchecks itself. You simply aren't able to open your serial port. Where's the part of the debug where it tries to open the port and what is returned at that part?

On Sat, Apr 16, 2016 at 3:07 PM, Leigh notifications@github.com wrote:

Ah sorry for the lack of obvious information there :) yeah so it's 1.88 as that's the compiled binary I can download. As soon as I click the checkbox

• it unchecks itself and I see that warning/error (with -v)

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/chilipeppr/serial-port-json-server/issues/7#issuecomment-210913119

[chilipeppr]

You sure you don't have the serial port locked from minicom?

On Sat, Apr 16, 2016 at 3:11 PM, John Lauer jlauer12@gmail.com wrote:

That error is meaningless and is not why it unchecks itself. You simply aren't able to open your serial port. Where's the part of the debug where it tries to open the port and what is returned at that part?

On Sat, Apr 16, 2016 at 3:07 PM, Leigh notifications@github.com wrote:

Ah sorry for the lack of obvious information there :) yeah so it's 1.88 as that's the compiled binary I can download. As soon as I click the checkbox - it unchecks itself and I see that warning/error (with -v)

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/chilipeppr/serial-port-json-server/issues/7#issuecomment-210913119

[dgtlmoon]

Minicom is not running, fuser reports no processes using /dev/ttyUSB0 :(

[chilipeppr]

Can you send all debug output from SPJS.

On Sat, Apr 16, 2016 at 3:15 PM, Leigh notifications@github.com wrote:

Minicom is not running, fuser reports no processes using /dev/ttyUSB0 :(

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/chilipeppr/serial-port-json-server/issues/7#issuecomment-210914791

[dgtlmoon]

Attached here

log.txt

[chilipeppr]

When it opens your serial port it gets an EOF. That's why it's closing.

2016/04/17 00:29:32 serialport.go:373: Inside spHandler 2016/04/17 00:29:32 serialport.go:388: Opening serial port /dev/ttyUSB0 at 115200 baud 2016/04/17 00:29:32 serialport.go:433: Just tried to open port 2016/04/17 00:29:32 serialport.go:442: Opened port successfully 2016/04/17 00:29:32 serialport.go:187: Hit end of file on serial port 2016/04/17 00:29:32 serial.go:132: Registering a port: /dev/ttyUSB0 2016/04/17 00:29:32 serialport.go:193: EOF 2016/04/17 00:29:32 serial.go:141: Unregistering a port: /dev/ttyUSB0 2016/04/17 00:29:32 serialport.go:363: Shutting down writer on /dev/ttyUSB0 2016/04/17 00:29:32 serialport.go:257: writerBuffered just got closed. make sure you make a new one. port:/dev/ttyUSB0

On Sat, Apr 16, 2016 at 3:31 PM, Leigh notifications@github.com wrote:

Attached here

log.txt https://github.com/chilipeppr/serial-port-json-server/files/222436/log.txt

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/chilipeppr/serial-port-json-server/issues/7#issuecomment-210919383

[dgtlmoon]

I'm not sure what todo about that, any suggestions? I'm running TinyG

[chilipeppr]

I've heard that some Linux USB serial port drivers return EOF on connection, which makes the port look closed. See if there are ways to tell Linux to not do that. Or try running TinyG from a Raspberry Pi. Or your local Windows box if you have one.

On Sat, Apr 16, 2016 at 3:44 PM, Leigh notifications@github.com wrote:

I'm not sure what todo about that, any suggestions? I'm running TinyG

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/chilipeppr/serial-port-json-server/issues/7#issuecomment-210919963

[dgtlmoon]

Ahh interesting, yeah this is the second laptop it's had the same problem on, I will change platform completely and get back to you, thanks for the input and hard work!

PS: is it possible to skip that EOF?

[chilipeppr]

Yes, there was code in the old SPJS that looks for the EOF within milliseconds on connecting and if so skips assuming a disconnect. It was commented out because it created other problems on Mac. You could go into the code and uncomment that part and recompile.

On Sat, Apr 16, 2016 at 3:47 PM, Leigh notifications@github.com wrote:

Ahh interesting, yeah this is the second laptop it's had the same problem on, I will change platform completely and get back to you, thanks for the input and hard work!

PS: is it possible to skip that EOF?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/chilipeppr/serial-port-json-server/issues/7#issuecomment-210920110

[dgtlmoon]

Yup exactly :)

I performed a quick hack that you can see below and it seems to resolve my issue.

Perhaps two things could come from this

• When quitting, print the number of milli/seconds ran until EOF was found after connection?
• Provide a config value to be able to set the minimum time to ignore EOF

diff --git a/serialport.go b/serialport.go
index a61d441..23ce168 100755
--- a/serialport.go
+++ b/serialport.go
@@ -181,7 +181,7 @@ func (p *serport) reader() {
                // close and the OS doesn't clear out that buffer on a new
                // connect. This means we'll only catch EOF's when there are
                // other characters with it, but that seems to work ok
-               if n <= 0 {
+               if n <= 0 && false {
                        if err == io.EOF || err == io.ErrUnexpectedEOF {
                                // hit end of file
                                log.Println("Hit end of file on serial port")

[dgtlmoon]

I can confirm that this is no issue with a RaspberryPi but is an issue when running from a laptop

[chilipeppr]

I think it's the version of Linux being used.

On Sun, May 1, 2016 at 6:05 AM, Leigh notifications@github.com wrote:

I can confirm that this is no issue with a RaspberryPi but is an issue when running from a laptop

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/chilipeppr/serial-port-json-server/issues/7#issuecomment-216040831

[dgtlmoon]

wonder what it could bethen? they are both 4.4 kernel versions

[DanielJoyce]

Does laptop hibernate or suspend? This may cause the USB ports to become depowered, leading to the serial port being closed. When running attached to a printer or cnc, or whatever, you will want to disable hibernate/suspend/power management.

In KDE5 you can create a desktop profile and have that profile disable APM. Works great on my laptop. I just switch to that profile when using my printer, and ensure the laptop is plugged in and it works great.

Other desktops may have similar options, or you can use commandline tools.