i'm seeing frequent disconnected from the serial port in safari for mac (latest).

i’m seeing frequent disconnected from the serial port in safari for mac (latest). On reconnection, all position data is lost too (which is odd but I think is caused by the open event firing a reset pulse at the board).

any thoughts?

Screenshots help because I’m not sure what you mean. Do you mean the websocket drops and you are no longer connected to Serial Port JSON Server? Or do you mean the serial port disappears from the list? Or do you mean the serial port shows in list but goes from checked to unchecked?

It disconnects. And then is unchecked. Nothing evident in the serial monitor.
Obviously rechecking the box causes a reset signal to be sent (I may stop that from happening.) And then the position to be lost.

I’ve seen it before when the browser gets stressed but this time the mill had been on hold for five minutes whilst i was cleaning acrylic gunk off an end-mill (not able to keep it cold enough to stop it melting on to the bit, even with air being blasted)

A websocket dropping and then you manually reconnecting to the websocket should mean the serial port is still checked. So something else must be happening. Is SPJS restarting?

Serial port not still checked. No restarts showing in the terminal window for sjps. And precious little traffic as the device was in hold.

What version of SPJS?

On the Mac I’m using 1.94 from memory.

this is now happening on both my main laptops (one win and one mac) and in every browser I use. Unfortunately it completely prevents me from being able to mill anything.

So I will need to use CP for the gcode creation and auto levelling. And then export the gcode into a gcode sender of some sort.

the ‘view auto levelled data’ button on the auto-level widget does not seem to be functional at the moment. is there another way of getting the auto levelled and auto generated g-code out of the browser?

If I recall correctly, you’re using your own Grbl workspace, right? Is it possible there’s so much traffic on how you’re talking to Grbl that the traffic is overloading the websocket? I have not heard this happening with anybody else? I’ve seen it only happen in the past when the websocket gets inundated with data back from the device or into the device.

So, for instance, one thing that concerned me on Grbl in the past is that the Grbl workspace had to send a ? query to get position every 250ms. That doesn’t happen on TinyG as it just reports when position has changed. Could that possibly be a reason?

@jlauer ​ the messages are not changed. Nor the frequency. The main difference is how the messages are parsed. We use a suite of regex rather than text matching.
It could be that the regex are overwhelming the browser. Impossible to tell really as there are no errors thrown.

4 times a second a pretty slow and infrequent! It might be better to move that to sjps however.

Have you tried running SPJS on a different computer to see if it works any better for you?

Same behaviour on my two active computers.

I have tracked down the issue (I suspect) for why the coordinates are lost in chilipeppr. I think this is because when the connection to SJPS is lost, the closecontroller event is fired, and this in turn resets the storage arrays for the coordinates. which then has issues later down the line.

I have tried to plug these gaps but there may be more gremlins. please let me know if so.

spoke too soon.

the problem also occurs on sending 0x18 apparently (in this case this occurred whilst auto levelling).

the problem here comes from grbl. It reports that the work coordinates have changed. which is odd but may be a design choice. i will have to investigate.

if this is a design choice, I am not sure what more can be done.

here is a snip from the SJPS logs.

2017/04/22 13:13:00 bufferflow_grbl.go:134: Working on element:<Alarm|WPos:0.000,55.000,0.510|Bf:15,128|FS:0,0|Pn:P|Ov:100,100,100>, index:0

2017/04/22 13:13:00 bufferflow_grbl.go:238: Command Before Break-Apart: “\x18 \n”

2017/04/22 13:13:00 bufferflow_grbl.go:332: Found cmd that should wipe out and reset buffer. cmd:

2017/04/22 13:13:00 bufferflow_grbl.go:107: OnIncomingData() start. data:"\r\nGrbl 1.1e [’$’ for help]\r\n[MSG:’$H’|’$X’ to unlock]\r\n[echo: ]\r\nok\r\n"
2017/04/22 13:13:00 bufferflow_grbl.go:115: arrLines:[ Grbl 1.1e [’$’ for help] [MSG:’$H’|’$X’ to unlock] [echo: ] ok ]
2017/04/22 13:13:00 bufferflow_grbl.go:121: We have data lines to analyze. numLines:6
2017/04/22 13:13:00 bufferflow_grbl.go:134: Working on element:, index:0
2017/04/22 13:13:00 bufferflow_grbl.go:134: Working on element:Grbl 1.1e [’$’ for help], index:1
2017/04/22 13:13:00 bufferflow_grbl.go:437: Pseudo command received to wipe grbl buffer but not send on to grbl controller.
2017/04/22 13:13:00 bufferflow_grbl.go:456: Hit default in select clause
2017/04/22 13:13:00 bufferflow_grbl.go:459: Done consuming sendBuffered cmds. ctr:0
2017/04/22 13:13:00 bufferflow_grbl.go:356: Lock being released in GRBL buffer
2017/04/22 13:13:00 bufferflow_grbl.go:360: ReleaseLock(), so we will send signal of 2 to b.sem to unpause the BlockUntilReady() thread
2017/04/22 13:13:00 bufferflow_grbl.go:465: itemsInBuffer:0
2017/04/22 13:13:00 bufferflow_grbl.go:134: Working on element:[MSG:’$H’|’$X’ to unlock], index:2
2017/04/22 13:13:00 bufferflow_grbl.go:134: Working on element:[echo: ], index:3
2017/04/22 13:13:00 bufferflow_grbl.go:134: Working on element:ok, index:4
2017/04/22 13:13:00 bufferflow_grbl.go:160: We should NEVER get here cuz we should have a command in the queue to dequeue when we get the r:{} response. If you see this debug stmt this is BAD!!!

2017/04/22 13:13:00 bufferflow_grbl.go:107: OnIncomingData() start. data:"<Alarm|WPos:-15.201,31.201,0.471|Bf:15"

just started milling a job (rather than autolevelling). the disconnects make it so bad that i cannot even get past 5mm of traces.

here is a sample of the SJPS debug log for @jlauer . It suggests that it is definitely a problem between SJPS and the arduino. note that I am not seeing any reset event occur on the 'duino.


Working on element:<Idle|WPos:0.000,0.000,0.000|Bf:15,128|FS:0,0|WCO:0.000,0.000,0.000>, index:0
2017/04/22 14:35:08 bufferflow_grbl.go:210: OnIncomingData() end.
2017/04/22 14:35:09 serialport.go:187: Hit end of file on serial port
2017/04/22 14:35:09 serialport.go:193: EOF
2017/04/22 14:35:09 serial.go:141: Unregistering a port: /dev/cu.usbmodem411
2017/04/22 14:35:09 serialport.go:363: Shutting down writer on /dev/cu.usbmodem411
2017/04/22 14:35:09 serialport.go:257: writerBuffered just got closed. make sure you make a new one. port:/dev/cu.usbmodem411
2017/04/22 14:35:09 bufferflow_grbl.go:385: Just wrote 0 bytes to serial: ?
2017/04/22 14:35:09 bufferflow_grbl.go:389: Error writing to /dev/cu.usbmodem411 write /dev/cu.usbmodem411: bad file descriptor Closing port.
2017/04/22 14:35:09 hub.go:122: send /dev/cu.usbmodem411 $I
2017/04/22 14:35:09 serial.go:680: Inside spWrite arg: send /dev/cu.usbmodem411 $I

am now also seeing errors thrown. oddly:

2017/04/22 14:56:56 bufferflow_grbl.go:231: Done consuming b.sem queue so we’re good to block on it now. ctr:0
2017/04/22 14:56:56 bufferflow_grbl.go:87: Blocking on b.sem until told from OnIncomingData to go
2017/04/22 14:56:56 bufferflow_grbl.go:107: OnIncomingData() start. data:"[echo: N554G1X16.3741Y27.2293Z-0.2912]\r"
]017/04/22 14:56:56 bufferflow_grbl.go:115: arrLines:[[echo: N554G1X16.3741Y27.2293Z-0.2912]
2017/04/22 14:56:56 bufferflow_grbl.go:127: Did not find newline yet, so nothing to analyze
2017/04/22 14:56:56 bufferflow_grbl.go:107: OnIncomingData() start. data:"\nerror:22\r\n[echo: N555G1X16.3306Y27.1641Z-0.2902"
2017/04/22 14:56:56 bufferflow_grbl.go:115: arrLines:[[echo: N554G1X16.3741Y27.2293Z-0.2912] error:22 [echo: N555G1X16.3306Y27.1641Z-0.2902]
2017/04/22 14:56:56 bufferflow_grbl.go:121: We have data lines to analyze. numLines:3
2017/04/22 14:56:56 bufferflow_grbl.go:134: Working on element:[echo: N554G1X16.3741Y27.2293Z-0.2912], index:0
2017/04/22 14:56:56 bufferflow_grbl.go:134: Working on element:error:22, index:1
2017/04/22 14:56:56 bufferflow_grbl.go:150: Error Response Received:N554G1X16.3741Y27.2293Z-0.2912
, id:g554

(I should say that that error was one of many many that followed). all looked like well formed gcode to me.

but the error relates to the absence of a feed rate. which suggests that we need to redo the eagle board widget to add a feed rate into each G1 line.

or am I misunderstanding something ?I

I suspect that the overwhelming number of errors could be causing the disconnect however.

and now another issue whether no errors are reported at all, the gcode keeps sending but grbl is reporting idle, as if it is not getting anything from SJPS but still sending.

i think there must be a bad bug in this version of the grbl buffer flow. time to downgrade.