Smoothie Ethernet connect problems

[Marius Liebenberg]

Hi

I switched from using USB with my Smoothie to make the load less on the USB. The smoothie IP is visible and the web interface is working. I get this error when I try to connect. Any suggestion please.

2019-01-07 16:44:52 Main DEBUG: Bienvenue, Bienvenido, Willkommen, Hello, Namaskar, Welkom to OpenPnP version 2018-11-08_06-46-50.7a1b10c.
2019-01-07 16:44:52 Scripting TRACE: Scripting.on Startup
2019-01-07 16:44:52 OpenPnpCaptureCamera WARNING: No camera found with ID USB 2.0 Camera usb-0000:00:1a.0-1.4 for camera TopCamera
2019-01-07 16:44:52 CameraView DEBUG: Failed to load camera specific reticle, checking default.
2019-01-07 16:44:52 CameraView DEBUG: No reticle preference found.
2019-01-07 16:44:52 OpenPnpCaptureCamera WARNING: No camera found with ID USB 2.0 Camera usb-0000:00:1a.0-1.4 for camera TopCamera
2019-01-07 16:44:53 CameraView DEBUG: Failed to load camera specific reticle, checking default.
2019-01-07 16:44:53 CameraView DEBUG: No reticle preference found.
2019-01-07 16:44:53 OpenPnpCaptureCamera WARNING: No camera found with ID USB 2.0 Camera usb-0000:00:1a.0-1.4 for camera TopCamera
2019-01-07 16:49:59 ReferenceMachine DEBUG: setEnabled(true)
2019-01-07 16:50:00 GcodeDriver TRACE: [tcp://192.168.1.155:23] << Smoothie command shell
2019-01-07 16:50:00 GcodeDriver DEBUG: sendCommand(null, 250)...
2019-01-07 16:50:01 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.155:23 null, 250) => [Smoothie command shell]
2019-01-07 16:50:01 GcodeDriver DEBUG: sendCommand(null, 250)...
2019-01-07 16:50:01 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.155:23 null, 250) => []
2019-01-07 16:50:01 GcodeDriver DEBUG: sendCommand(G21 ; Set millimeters mode, 5000)...
2019-01-07 16:50:01 GcodeDriver TRACE: [tcp://192.168.1.155:23] >> G21 ; Set millimeters mode
2019-01-07 16:50:01 GcodeDriver TRACE: [tcp://192.168.1.155:23] << > ok
2019-01-07 16:50:06 MessageBoxes DEBUG: Enable Failure: Timeout waiting for response to G21 ; Set millimeters mode

[Marius Liebenberg]

It would seem that the response in not understood??

[Marek T.]

Hi Marius,

Maybe it's not this but:

Answer from Smoothie over serial is just alone "ok"

2019-01-07 16:17:59.823 GcodeDriver TRACE: [serial://COM11] << ok
while you have "> ok"

2019-01-07 16:50:01 GcodeDriver TRACE: [tcp://192.168.1.155:23] << > ok


I would check whether command_confirm_regex is ok in your setup. However maybe it is only other driver displaying for TCP.

[Marius Liebenberg]

Marek I did not change anything just changed over to TCP. I would have thought that the protocol would be the same but I see what you say about the acknowledge being incorrect. That must be from Smoothie side.

Must there be some other setting on OpenPnp for TCP connection?

[Marek T.]

I bought the crossed-cable but didn't try to connect Smoothie over it yet, so I don't know.

How do you connect the Smoothie to Openpnp, directly or through the router? If directly - have you found you need "special" cable not typical ethernet like for pc<->router?

[Jarosław Karwik]

I have not seen router without AutoMDX feature ( co it does not matter if you have cross or not )

Most likely you can see extra '>' character as Ethernet connection connects you to terminal like command line.

So you may have to delete it - for any communication you get.

[Marek T.]

You haven't understood me well probably. Read from "please note":

Wiring

To access your Smoothieboard, you need to connect it to your network.

To do so, you plug an Ethernet cable into the Smoothieboard at one end, and into your Ethernet router at the other end.

Please note that you can't connect a Smoothieboard directly to your computer ( not unless you use a special type of cable and a special type of configuration on your computer ). You want to use a router for this.

Once configured and plugged in, reset the Smoothieboard and wait for it to connect to the network.

http://smoothieware.org/network

[Mark]

Hi

 

It seems the

 

> ok

 

comes back, so it can’t be a connectivity problem.

 

See the log:

2019-01-07 16:50:01 GcodeDriver TRACE: [tcp://192.168.1.155:23] << > ok

 

I guess the COMMAND_CONFIRM_REGEX is missing or wrong:

https://github.com/openpnp/openpnp/wiki/GcodeDriver#regular-expressions-receiving-responses

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7d1669ac-6969-41ee-9a48-14e5c4a1ddd5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marek T.]

Marius, I have just connected Openpnp to the TCP server to simulate Smoothie.

OpenPnp works "normally" if I send just "ok" finished with 0D as regex, and is not working if I send "> ok"...

So it means Smoothie is sending other confirmation over USB than Ethernet or it's driver behaviour.

Anyway if you change confirm_regex to "> ok.*" then it works ok...

[Marius Liebenberg]

I can see the Smoothie on Ethernet as I can log into the web interface of the Smoothie. I am connecting via a port expander.

[Marius Liebenberg]

I will try that. I wonder if this is a bug or done by design

[Marius Liebenberg]

it must be a bug because it only happens on the first command

2019-01-07 19:25:05 ReferenceMachine DEBUG: setEnabled(true)
2019-01-07 19:25:05 GcodeDriver ERROR: Read error
2019-01-07 19:25:05 GcodeDriver TRACE: [tcp://192.168.1.155:23] << Smoothie command shell
2019-01-07 19:25:06 GcodeDriver DEBUG: sendCommand(null, 250)...
2019-01-07 19:25:06 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.155:23 null, 250) => [Smoothie command shell]
2019-01-07 19:25:06 GcodeDriver DEBUG: sendCommand(null, 250)...
2019-01-07 19:25:07 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.155:23 null, 250) => []
2019-01-07 19:25:07 GcodeDriver DEBUG: sendCommand(G21 ; Set millimeters mode, 5000)...
2019-01-07 19:25:07 GcodeDriver TRACE: [tcp://192.168.1.155:23] >> G21 ; Set millimeters mode
2019-01-07 19:25:07 GcodeDriver TRACE: [tcp://192.168.1.155:23] << > ok
2019-01-07 19:25:07 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.155:23 G21 ; Set millimeters mode, 5000) => [> ok]
2019-01-07 19:25:07 GcodeDriver DEBUG: sendCommand(G90 ; Set absolute positioning mode, 5000)...
2019-01-07 19:25:07 GcodeDriver TRACE: [tcp://192.168.1.155:23] >> G90 ; Set absolute positioning mode
2019-01-07 19:25:07 GcodeDriver TRACE: [tcp://192.168.1.155:23] << ok
2019-01-07 19:25:12 MessageBoxes DEBUG: Enable Failure: Timeout waiting for response to G90 ; Set absolute positioning mode

[Marek T.]

You have mobilized me to work, thank you ;)

So I just have connected MKS1.3 (that I keep at home for different experiments) with actual Smoothieboard firmware to some laptop with TCP client.

Interresting that I see an answers from the Smoothie as pure "ok" without any prefix! It answers ok{0D}{0A}.

And I can confirm that I have used crossed-cable for the direct pc<->smoothie connection.

[Marek T.]

After the connection I get answer:

Smoothie command shell{0D}{0A}> and promting.

If I send for it a command G21{0A} I get ok{0D}.

Possible there is something expected by Smoothie to get as answer from client (Openpnp) after the connection is established, and maybe it's just missing?

[Marius Liebenberg]

So the log shows that there are two extra characters "> " in the return string but you dont see that in the raw comms. Could be a bug in OpenPnp then?

[Marek T.]

Now I have connected Smoothie to the Openpnp and I see the same like you:

2019-01-07 18:53:31.627 ReferenceMachine DEBUG: setEnabled(true)
2019-01-07 18:53:32.647 GcodeDriver DEBUG: sendCommand(null, 250)...
2019-01-07 18:53:32.900 GcodeDriver DEBUG: sendCommand(serial://COM15 null, 250) => []
2019-01-07 18:53:32.901 GcodeDriver DEBUG: sendCommand(M805.1 ; CONNECT_COMMAND: DownCamLight ON, 2000)...
2019-01-07 18:53:32.901 GcodeDriver TRACE: [serial://COM15] >> M805.1 ; CONNECT_COMMAND: DownCamLight ON
2019-01-07 18:53:34.479 GcodeDriver TRACE: [serial://COM15] << ok
2019-01-07 18:53:34.480 GcodeDriver DEBUG: sendCommand(serial://COM15 M805.1 ; CONNECT_COMMAND: DownCamLight ON, 2000) => [ok]
2019-01-07 18:53:34.595 GcodeDriver TRACE: [tcp://192.168.1.222:23] << Smoothie command shell
2019-01-07 18:53:35.511 GcodeDriver DEBUG: sendCommand(null, 250)...
2019-01-07 18:53:35.767 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.222:23 null, 250) => [Smoothie command shell]
2019-01-07 18:53:35.768 GcodeDriver DEBUG: sendCommand(null, 250)...
2019-01-07 18:53:36.041 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.222:23 null, 250) => []
2019-01-07 18:53:36.042 GcodeDriver DEBUG: sendCommand(G21 ; CONNECT_COMMAND: Set millimeters mode, 20000)...
2019-01-07 18:53:36.044 GcodeDriver TRACE: [tcp://192.168.1.222:23] >> G21 ; CONNECT_COMMAND: Set millimeters mode
2019-01-07 18:53:36.099 GcodeDriver TRACE: [tcp://192.168.1.222:23] << > ok
2019-01-07 18:53:56.210 MessageBoxes DEBUG: Enable Failure: Timeout waiting for response to G21 ; CONNECT_COMMAND: Set millimeters mode

It seems be some bug in driver but let's wait for Jason.

[Marius Liebenberg]

I looked at the code and it seems that the buffer is cleared every read unless java does it in some other way. The variable line is created new every read. Jason will have to help.

public String readLine() throws TimeoutException, IOException {
        StringBuffer line = new StringBuffer();
        while (true) {
            try {
                int ch = input.read();
                if (ch == -1) {
                    return null;
                }
                else if (ch == '\n' || ch == '\r') {
                    if (line.length() > 0) {
                        return line.toString();
                    }
                }
                else {
                    line.append((char) ch);
                }
            }
            catch (IOException ex) {
                if (ex.getCause() instanceof SocketTimeoutException) {
                    throw new TimeoutException(ex.getMessage());
                }
                throw ex;
            }
        }
    }

[Arthur Wolf]

I think I've seen this for some other host one time. I *think* ( don't quote me ) that the > is normal, but might be sent a bit later after the welcome message, so if openpnp recognizes the welcome message and moves on, the > might then get added to the buffer, and cause trouble when reading the ok next.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/530fe47c-00f0-49a5-9968-913803a09da3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

[Marek T.]

Hi Arthur,

So do you suggest we should add some delay after the port is opened but before the first command sending to Smoothie?

[Arthur Wolf]

Not sure actually. Octoprint and Pronterface are the reference "best" Smoothie interfacers, we worked a lot with them on making sure everything works very well, but I'm not sure how they handle this. I think they might send a command at boot, like "version" or the standard Reprap status command ( don't remember which it is ), which would swallow the > in this case here so the first "real" command would have no trouble.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4402aa56-801c-4971-a90c-407b6ffa31a7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Marek T.]

Well, so I have made a dummy operation...

I have added "version" request as the first line of the connect_command and modified confirm_regex to (^5 axis|^ok).*

Then it works...

2019-01-07 20:10:50.020 ReferenceMachine DEBUG: setEnabled(true)
2019-01-07 20:10:50.129 GcodeDriver TRACE: [tcp://192.168.1.222:23] << Smoothie command shell
2019-01-07 20:10:53.043 GcodeDriver DEBUG: sendCommand(null, 250)...
2019-01-07 20:10:53.301 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.222:23 null, 250) => [Smoothie command shell]
2019-01-07 20:10:53.301 GcodeDriver DEBUG: sendCommand(null, 250)...
2019-01-07 20:10:53.559 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.222:23 null, 250) => []
2019-01-07 20:10:53.559 GcodeDriver DEBUG: sendCommand(version ;, 5000)...
2019-01-07 20:10:53.559 GcodeDriver TRACE: [tcp://192.168.1.222:23] >> version ;
2019-01-07 20:10:53.629 GcodeDriver TRACE: [tcp://192.168.1.222:23] << > Build version: feature/soft-endstops-76540a01NOMSD, Build date: Oct 20 2017 12:10:30, MCU: LPC1768, System Clock: 100MHz
2019-01-07 20:10:53.629 GcodeDriver TRACE: [tcp://192.168.1.222:23] << NOMSD Build
2019-01-07 20:10:53.629 GcodeDriver TRACE: [tcp://192.168.1.222:23] << 5 axis
2019-01-07 20:10:53.629 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.222:23 version ;, 5000) => [> Build version: feature/soft-endstops-76540a01NOMSD, Build date: Oct 20 2017 12:10:30, MCU: LPC1768, System Clock: 100MHz, NOMSD Build, 5 axis]
2019-01-07 20:10:53.637 GcodeDriver DEBUG: sendCommand(G21 ; Set millimeters mode, 5000)...
2019-01-07 20:10:53.637 GcodeDriver TRACE: [tcp://192.168.1.222:23] >> G21 ; Set millimeters mode
2019-01-07 20:10:54.129 GcodeDriver TRACE: [tcp://192.168.1.222:23] << ok
2019-01-07 20:10:54.129 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.222:23 G21 ; Set millimeters mode, 5000) => [ok]
2019-01-07 20:10:54.129 GcodeDriver DEBUG: sendCommand(G90 ; Set absolute positioning mode, 5000)...
2019-01-07 20:10:54.129 GcodeDriver TRACE: [tcp://192.168.1.222:23] >> G90 ; Set absolute positioning mode
2019-01-07 20:10:54.629 GcodeDriver TRACE: [tcp://192.168.1.222:23] << ok
2019-01-07 20:10:54.629 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.222:23 G90 ; Set absolute positioning mode, 5000) => [ok]
2019-01-07 20:10:54.629 GcodeDriver DEBUG: sendCommand(M82 ; Set absolute mode for extruder, 5000)...
2019-01-07 20:10:54.629 GcodeDriver TRACE: [tcp://192.168.1.222:23] >> M82 ; Set absolute mode for extruder
2019-01-07 20:10:55.129 GcodeDriver TRACE: [tcp://192.168.1.222:23] << ok
2019-01-07 20:10:55.129 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.222:23 M82 ; Set absolute mode for extruder, 5000) => [ok]

[Marek T.]

Pay attention on difference:

Over TCP/IP, simple G90 operation takes 500ms:

2019-01-07 20:10:54.129 GcodeDriver TRACE: [tcp://192.168.1.222:23] >> G90 ; Set absolute positioning mode
2019-01-07 20:10:54.629 GcodeDriver TRACE: [tcp://192.168.1.222:23] << ok

Over USB, the same operation takes 7ms:

2019-01-07 20:50:55.034 GcodeDriver TRACE: [serial://COM11] >> G90 ; CONNECT_COMMAND: Set absolute positioning mode
2019-01-07 20:50:55.041 GcodeDriver TRACE: [serial://COM11] << ok

So I don't know where is the delay reason but this TCP speed is not acceptable for me, I stay with USB.

[Jarosław Karwik]

Ethernet is much more stable and gives galvanic isolation - which USB does not.

In case of P&P machines it may be not really important, but in my CNC business USB was getting suck or burned once a while.

The connection should be made using simple UDP, not TCP which is very heavy. Especially that it is simple text protocol

[Arthur Wolf]

Have any Wifi in the loop ?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8cd1e1f5-2947-4b1c-b56d-dcb814b2b3c7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mark]

> Ethernet is much more stable and gives galvanic isolation - which USB does not.

 

Except if you have an isolator like on the Azteeg X5 GT 32, also with Smoothieware (this should be a MUST for controllers, really). You can also add one externally, like this one (just as an example).

 

Note that the cameras live on the USB ground and supply only. They should not be grounded to the machine. The ELP camera mounting holes are not grounded BTW, I checked, so it’s OK to mount these to metal structures with metal screws.

 

If you use a hub at the machine, it should come before the isolator. The isolator is also too slow for the cameras (except for very expensive ones).

 

For more on grounding, see here (comments welcome).

 

_Mark

 

[Arthur Wolf]

On Mon, Jan 7, 2019 at 9:33 PM Mark <ma...@makr.zone> wrote:

> Ethernet is much more stable and gives galvanic isolation - which USB does not.

 

Except if you have an isolator like on the Azteeg X5 GT 32, also with Smoothieware (this should be a MUST for controllers, really). You can also add one externally, like this one (just as an example).

My understanding is that the Azteeg boards had a lot more USB problems than is usual for Smoothie-based boards ( see forums ), they couldn't find the core reason ( probably some design problem ), and they were backed into the corner of having to use money to solve the issue. Isolators are super expensive.

 

Note that the cameras live on the USB ground and supply only. They should not be grounded to the machine. The ELP camera mounting holes are not grounded BTW, I checked, so it’s OK to mount these to metal structures with metal screws.

 

If you use a hub at the machine, it should come before the isolator. The isolator is also too slow for the cameras (except for very expensive ones).

 

For more on grounding, see here (comments welcome).

 

_Mark

 

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/040101d4a6c8%242f9f3520%248edd9f60%24%40makr.zone.

For more options, visit https://groups.google.com/d/optout.

[Mark]

> Isolators are super expensive.

 

Guess it’s all relative :-)

https://www.digikey.ch/product-detail/de/analog-devices-inc/ADUM3160BRWZ-RL/ADUM3160BRWZ-RLCT-ND/3897186

 

Expensive for you as a board maker. Cheap for the guy who fried his computer’s motherboard :-)

 

Personally I don’t think you can do it without, if you are also concerned for your own safety, meaning you must ground a metal PNP machine, including cable shields. Some notebooks (Apple) are not grounded (doubly isolated PSU), then it’s probably OK, but most Computers are grounded and you might get problems through the mains ground loop.

 

I fried my motherboard once, by plugging in an external USB Hub auxiliary power supply into a different powerstrip on a long extension cable.

 

_Mark

 

 

[Arthur Wolf]

On Mon, Jan 7, 2019 at 11:10 PM Mark <ma...@makr.zone> wrote:

> Isolators are super expensive.

 

Guess it’s all relative :-)

https://www.digikey.ch/product-detail/de/analog-devices-inc/ADUM3160BRWZ-RL/ADUM3160BRWZ-RLCT-ND/3897186

 

Expensive for you as a board maker. Cheap for the guy who fried his computer’s motherboard :-)

Tens of thousands of smoothieboards in the wild, still to hear of a report of that. Don't think it's worth users paying $5 ( more with our sweet sweet margin ) on each of the tens of thousands of boards :)

 

Personally I don’t think you can do it without, if you are also concerned for your own safety,

Safety as in physical harm to the user ? That sounds outside the bounds of the conversation here ...

meaning you must ground a metal PNP machine, including cable shields. Some notebooks (Apple) are not grounded (doubly isolated PSU), then it’s probably OK, but most Computers are grounded and you might get problems through the mains ground loop.

 

I fried my motherboard once, by plugging in an external USB Hub auxiliary power supply into a different powerstrip on a long extension cable.

Yep, ground loops suck, and users should be educated on them, definitely.

 

_Mark

 

 

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/042b01d4a6d5%24c9032b60%245b098220%24%40makr.zone.

For more options, visit https://groups.google.com/d/optout.

[Marius Liebenberg]

For that matter then I can just change the confirm_regex to (^> |^ok).* That should work always then?

[Marius Liebenberg]

Ok so I changed the regex to be ^> ok.*|^ok.* Now it goes further but another error appears. It send out data successfully and in the end fails because it could not find the port name. Does not make sense.

2019-01-08 08:17:38 ReferenceMachine DEBUG: setEnabled(true)
2019-01-08 08:17:39 GcodeDriver TRACE: [tcp://192.168.1.155:23] << Smoothie command shell
2019-01-08 08:17:39 GcodeDriver DEBUG: sendCommand(null, 250)...
2019-01-08 08:17:39 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.155:23 null, 250) => [Smoothie command shell]
2019-01-08 08:17:39 GcodeDriver DEBUG: sendCommand(null, 250)...
2019-01-08 08:17:40 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.155:23 null, 250) => []
2019-01-08 08:17:40 GcodeDriver DEBUG: sendCommand(G21 ; Set millimeters mode, 5000)...
2019-01-08 08:17:40 GcodeDriver TRACE: [tcp://192.168.1.155:23] >> G21 ; Set millimeters mode
2019-01-08 08:17:40 GcodeDriver TRACE: [tcp://192.168.1.155:23] << > ok
2019-01-08 08:17:40 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.155:23 G21 ; Set millimeters mode, 5000) => [> ok]
2019-01-08 08:17:40 GcodeDriver DEBUG: sendCommand(G90 ; Set absolute positioning mode, 5000)...
2019-01-08 08:17:40 GcodeDriver TRACE: [tcp://192.168.1.155:23] >> G90 ; Set absolute positioning mode
2019-01-08 08:17:40 GcodeDriver TRACE: [tcp://192.168.1.155:23] << ok
2019-01-08 08:17:41 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.155:23 G90 ; Set absolute positioning mode, 5000) => [ok]
2019-01-08 08:17:41 GcodeDriver DEBUG: sendCommand(M82 ; Set absolute mode for extruder, 5000)...
2019-01-08 08:17:41 GcodeDriver TRACE: [tcp://192.168.1.155:23] >> M82 ; Set absolute mode for extruder
2019-01-08 08:17:41 GcodeDriver TRACE: [tcp://192.168.1.155:23] << ok
2019-01-08 08:17:41 GcodeDriver DEBUG: sendCommand(tcp://192.168.1.155:23 M82 ; Set absolute mode for extruder, 5000) => [ok]
2019-01-08 08:17:41 MessageBoxes DEBUG: Enable Failure: Port name - ; Method name - openPort(); Exception type - Port not found.

[Marius Liebenberg]

Ignore this error my second driver board was not plugged in :(

It seems to be working now with the regex workaround

[Mark]

> Safety as in physical harm to the user ? That sounds outside the bounds of the conversation here ...

 

I’m talking about grounding the exposed metal parts of the device to AC ground. Which only then leads to the ground loop problem.

 

> Tens of thousands of smoothieboards in the wild, still to hear of a report of that.

 

Glad to hear you’re that successful! :-)

 

I guess the “ten thousands” are “9’999”s of 3D printers that still 99.9% of the time just print off the SD card and are not USB connected to the computer except perhaps for the initial setup. With Smoothieboard’s nice SD card firmware update / config.txt feature there is no reason to keep a USB connection after that.

 

Plus 3D printers have documented crappy safety, I doubt many of them have proper AC safety / grounding. The many, many documented instances of burning the house down are probably more related to runaway heating elements but failure to ground the device properly can also cause fires, because the fuse (or MOSFET) won’t blow, if a faulty AC (or high current DC) wire touches the wrong stuff and causes sparks and heat.

 

Somewhat related:

https://www.youtube.com/watch?v=3jYZDLOV4Jc

 

_m

 

[Marek T.]

Marius, what the version of the openpnp do you use? Why it doesn't show milliseconds in the log? It was added many weeks ago as standard code.
Asking because I'm surprised why your communication seems work much faster for you than at me. And is it Linux or Windows?

[Marius Liebenberg]

Marek I synced with develop about three weeks ago and did a build of the jar. I am running from command line on Linux.  So I hope it is recent but I will have to see about that.

[Arthur Wolf]

On Tue, Jan 8, 2019 at 7:35 AM Mark <ma...@makr.zone> wrote:

> Safety as in physical harm to the user ? That sounds outside the bounds of the conversation here ...

 

I’m talking about grounding the exposed metal parts of the device to AC ground. Which only then leads to the ground loop problem.

 

> Tens of thousands of smoothieboards in the wild, still to hear of a report of that.

 

Glad to hear you’re that successful! :-)

 

I guess the “ten thousands” are “9’999”s of 3D printers that still 99.9% of the time just print off the SD card and are not USB connected to the computer except perhaps for the initial setup. With Smoothieboard’s nice SD card firmware update / config.txt feature there is no reason to keep a USB connection after that.

Nope, it's about 60% 3D printers, and the rest is a distribution of CNC mills, laser cutters, and a few trailing % are other machine types. Printing from the SD card is definitely in the minority, and the vast majority of machines are USB-connected ( most lasers and cnc mills are, you can't even get he full featureset without USB on those ), with panel control second, and ethernet third.

 

Plus 3D printers have documented crappy safety, I doubt many of them have proper AC safety / grounding. The many, many documented instances of burning the house down are probably more related to runaway heating elements but failure to ground the device properly can also cause fires, because the fuse (or MOSFET) won’t blow, if a faulty AC (or high current DC) wire touches the wrong stuff and causes sparks and heat.

 

Somewhat related:

https://www.youtube.com/watch?v=3jYZDLOV4Jc

 

_m

 

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/045a01d4a71c%2454f62f50%24fee28df0%24%40makr.zone.

For more options, visit https://groups.google.com/d/optout.

[Jarosław Karwik]

I have several hundreds of industrial CNC machines with my CNC controller. It has been developed for several years in three different generations - USB, USB with galvanic isolation and latest with Ethernet.

These machines vary from styro cutters, to CNC mills and laser /plasma cutters.

Following results ( over last 5-8 years):

- Machines with USB were sufffering from : USB lockouts ( needs machine reboot as I have seen both hardware issues as well as stack crashes),  burnt processors, even series resistors an USB lines.

While software issues were common ( USB stack), electrical issues were happening mainly when disturbances were high ( like lasers/plasma cutters ) or when grounding was crappy.

- Machines with USB galvanic isolation : surprisingly less software issues , but I have seen several isolators burned to the ground ( most likely grounding issue )

- Machines with Ethernet  - not even single one came back with problems ( ~ 300 with customers)

So there is big difference in reliability, even if all solutions work well in average environment. 

So 5$ matters once you have angry client with expensive machine which destroyed his working piece.  

[Marius Liebenberg]

I concur. I have built many plasma cnc machines and we could never get any USB device to be reliable and successful when used on plasma machines. The noise on the ground, even when grounded well is detrimental to USB.

[Marek T.]

Hi Jason,

Could you see this short discussion and give an answer how it is about the openPNP to the Smoothie communication over tcpip done? Maybe we need get some some more details from @wolfmanjm about it?
It's not matter to start some improvement at once until some facts are not confirmed, but could be worth just to collect information. https://groups.google.com/forum/m/#!topic/smoothieware-support/J0ZOZxkceeQ

[Jason von Nieda]

Hi Marek,

I have a brief discussion with wolfmanjm, which I've reproduced below. The summary is basically that TCP is slow on Smoothie and may not be a good choice for OpenPnP.

[12:53:43]  <vonnieda>    Hey wolfmanjm, I am reading your response on this thread regarding OpenPnP and was wondering if you could clarify your point about the ping pong protocol? https://groups.google.com/forum/m/#!topic/smoothieware-support/J0ZOZxkceeQ
[12:54:03]  <vonnieda>    By ping pong do you mean like send command, wait for "ok"?
[13:08:46]  <wolfmanjm>    yes
[13:09:02]  <vonnieda>    Okay, can you clarify that for me a bit? Why can't I use that protocol?
[13:09:20]  <wolfmanjm>    becuase TCP/IP has its own flow control protocol
[13:09:30]  <wolfmanjm>    if you wait for ok then it is very very very slow
[13:09:52]  <wolfmanjm>    look at how pronterface hanbdles it, there is an optin to stream over tcp/ip
[13:10:10]  <vonnieda>    The issue is that OpenPnP doesn't "stream" per se. It needs to send commands and wait until they are finished.
[13:10:16]  <vonnieda>    It's not just blowing out a pile of Gcode
[13:10:59]  <wolfmanjm>    basically you just send the gcode as fast as yo ucan, however yo MUST read the returning oks otherwise it will deadlock, so the read channel needs to be in a separate thread. There is an example python script in the github repo of smoothi eware,
[13:11:46]  <wolfmanjm> https://github.com/Smoothieware/Smoothieware/blob/edge/smoothie-stream.py
[13:11:53]  <vonnieda>    I can't do that. I need to know that the machine is done moving, or has finished turning on a MOSFET, etc. so that I can process the results.
[13:12:03]  <vonnieda>    (I do read in a separate thread, that's no issue)
[13:12:14]  <wolfmanjm>    smoothie simply does not support that model
[13:12:36]  <vonnieda>    The simple case for OpenPnP is: Move to X,Y. Wait for machine to stop moving. Take a picture. Move to somewhere else.
[13:12:47]  <wolfmanjm>    you woul dneed to eitehr rewrite smoothie or follow EVERY comamdn with M4000 and wait for ok
[13:12:59]  <wolfmanjm>    M400
[13:13:07]  <wolfmanjm>    it will be very very slow
[13:13:08]  <vonnieda>    Yea, that's basically what we do. We send M400 after pretty much every command. Certainly after every move command.
[13:13:32]  <wolfmanjm>    i don;t think that model will work over tcp/ip then
[13:13:42]  <wolfmanjm>    you will need to use either USB serialk or uart serial
[13:14:04]  <vonnieda>    Okay, can you help me understand why? TCP is a stream of bytes, right? Does the Smoothie send the "ok" over TCP differently than it sends it over serial?
[13:14:16]  <wolfmanjm>    also yo uneed to turn off the planning queue wait for buffer full when empty
[13:14:29]  <wolfmanjm>    tcp/ip on smoothi eis a hack
[13:14:47]  <wolfmanjm>    it is not recommended (by me) to be used so basically it is already very slow
[13:14:55]  <wolfmanjm>    due to memory limitiation
[13:15:06]  <vonnieda>    I see
[13:15:23]  <wolfmanjm>    and it is a cobblled tcp/ip protocol where every packet has to be acck'd before the next one can be sent
[13:15:47]  <wolfmanjm>    so if on top of that you wait for an ok, it will be terribly slow
[13:16:23]  <vonnieda>    Okay, fair enough. Thank you for the clarification.
[13:16:31]  <wolfmanjm>    also if you are expecting every single g code to execute immediately you need to set in config ...
[13:16:56]  <vonnieda>    FWIW, hundreds of people use Smoothie in exactly this way with OpenPnP, including myself, over USB. We're just starting to explore TCP.
[13:17:06]  <wolfmanjm>    queue_delay_time_ms 0
[13:17:38]  <wolfmanjm>    well from you results I suspect TCP/IP won't work for you
[13:17:54]  <wolfmanjm>    BTW yo need to set queue_delay_time_ms 0 in config even for USB
[13:18:15]  <wolfmanjm>    otherwise every commadn will wait for 300ms before being executed.
[13:18:37]  <vonnieda>    Interesting. I don't see that behavior at all. But maybe it's been set by default and I didn't notice.
[13:18:59]  <wolfmanjm>    it may be 100ms
[13:19:01]  <vonnieda>    I'll check my config and let others know about that.
[13:19:28]  <wolfmanjm>    under normal conditions it needs to allow the planner queue to fill up before executing so it can actually plan the acceleration and deceleration properly
[13:20:00]  <vonnieda>    Makes sense. Does that hold true if we're ending an M400 too? Perhaps that shortcuts it?
[13:20:06]  <vonnieda>    sending*
[13:20:14]  <wolfmanjm>    the MKS maybe very slow for other reasons so yo need to test on  real smoothieboard
[13:20:28]  <wolfmanjm>    no M400 will not shortcut it
[13:20:48]  <wolfmanjm>    it will just wait for the queue to empyty and the motors to stop turning
[13:20:54]  <vonnieda>    okay
[13:21:17]  <vonnieda>    FWIW, I only use real Smoothie's and I recommend others do too. But people love their cheap knockoffs 😊
[13:22:40]  <vonnieda>    Thanks again for the help. I appreciate you taking the time. I'll pass this conversation on to Marek.

Thanks,

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b27af49c-e5cc-4d19-a833-151c24d7e983%40googlegroups.com.

[Marek T.]

Great Jason, thx for your time spent on it. Now we know where we stand on with this. I really hoped we can have usb of Smoothie abandoned and use all the bandwidth power for cameras only. But it looks is not a way :-(.
I'll check how it works with orig Smoothie for me and let know what the difference is.

[Brynn Rogers]

Hi Jason,

Jason,

As one of my projects is to create a controller system with some resemblence to SmoothieBoard 2,  I have been believing that the correct way to handle communication is over ethernet - but apparently not how the smoothieboard does it.   The protocol to use is what the industrial world is using on ethernet, EtherNet/IP.  And the OpenSource version of it is called OpENer.   This WhitePaper  I think documents what it is to some extent.

Now unfortunately it seems like EtherNet/IP is complicated, but I think they may have solved all the latency problems you might see with the smoothieboard.   And until a hobbyest level controller (like the one on my drawing board) exists, there might not be a point to implementing it in OpenPnP.

Does eventually using EtherNet/IP in OpenPnP make sense to you?

Brynn

[Jason von Nieda]

Hey Brynn,

I won't say it's not worth trying, but I don't personally see the point. The problem is not Ethernet or OpenPnP, the problem is that Smoothie has a ton of latency in it's IP implementation.

I don't think we're going to see an issue where network latency is an issue. For example:

> ping 192.168.10.203
PING 192.168.10.203 (192.168.10.203): 56 data bytes
64 bytes from 192.168.10.203: icmp_seq=0 ttl=64 time=0.062 ms
64 bytes from 192.168.10.203: icmp_seq=1 ttl=64 time=0.109 ms

That's me pinging the gateway on my network, over WiFi. I can send and receive 64 bytes in the order of 100 *nanoseconds*.

Now, OpENer appears to be a protocol running on top TCP/IP, and it probably makes a lot of sense for managing large networks of industrial gear, but OpenPnP is more or less a point to point system and due to the necessities of pick and place we'll pretty much always need to be able to send a command, get notified that it's done, and then do the next thing.

Personally, I think it's worth keeping it simple. There are lots of cheap chips these days that can easily handle networking at a reasonable rate. I work with ESP32 every day and I think it would make a great motion controller brain.

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b6875a68-31fa-415f-aaf1-2fc5aa1ff8da%40googlegroups.com.

[Brynn Rogers]

Hey Jason,

   So I think your saying that a simple TCP/IP socket passing the Gcode commands and OK responses is really all that is needed, assuming the controller doesn't add any kind of delays- right?

Brynn

[Jason von Nieda]

Yep! :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/782db50d-a9af-48f7-ab7b-1f199df0b42c%40googlegroups.com.

[Mark]

> That's me pinging the gateway on my network, over WiFi. I can send and receive 64 bytes in the order of 100 *nanoseconds*.

 

That’s microseconds, but still awesome! I had no idea, always thought Wifi sucks. But my gigabit Ethernet pings at awful 15ms!

 

 

_Mark

 

[Jason von Nieda]

Ah, right you are!

15ms?! Might be time for a new router :)

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/01a501d4a9f7%242cf90300%2486eb0900%24%40makr.zone.

[Mark]

Yeah… router’s quite new but there is a power saving “green” switch in between… hmmm.

 

_m

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jx8JqbVBxDMAp%2BOKywM-%3DtCdieVT8Vv4srebufyaZi74g%40mail.gmail.com.

[Mark]

Yep, definitely the switch (D-Link green).

 

Directly attached, always 1ms (Windows 7 does not seem to show less than 1ms).

 

Thanks for the hint :-)

 

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/01bb01d4a9fd%24690bd470%243b237d50%24%40makr.zone.

[Brynn Rogers]

We have gigabit switches at the office, but the cabling is still cat 5 or 5e.  And I know my openpnp machines computer gets horrible throughout,  and when trying to try transfer large files (gigabytes)  it often fails the download completely.     All because it does not have cat6 cables.  At least I think that is the only problem ;-)   

I wonder if you have cat 5 or cat6 cables...

Brynn 

--

[Bernd Walter]

On Fri, Jan 11, 2019 at 02:31:50PM -0600, Jason von Nieda wrote:
> Hey Brynn,
>
> I won't say it's not worth trying, but I don't personally see the point.
> The problem is not Ethernet or OpenPnP, the problem is that Smoothie has a
> ton of latency in it's IP implementation.

Maybe this isn't new to you and already implemented, but it wasn't mentioned
yet.
I can't speak for the smoothie side, but generally TCP delays transfers in
favour of aggregating to bigger packet sizes.
Gcode lines are too small to be send without delay if that feature is active.
In a transaction related situation, such as the case of non streaming gcode,
as done with OpenPNP, the delay has to be disabled.
In C this is done with the following code:
int val, res;
val = 1;
res = setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &val, sizeof(val));

This is very similar to setting canonical mode on a TTY interface, but unlike
TCP, where more or less unknown trigger values are used, a TTY defaults to
operate in line mode, which works well for textline based gcode.
TCP_NODELAY changes sending data, but it isn't negotiated with the other side,
which can still do a delay, but many tiny embedded IP stacks don't implement
this feature.
In any case you reduce one delay, which is better than having two delays.

--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

[Michael Anton]

CAT5 is rated for 100Mbps, CAT5e for 1Gbps, and CAT6 for 10Gbps.  CAT6 is only rated to 10Gbps for up to 164 ft, and above this length it drops down to 1Gbps speed.  So, CAT5e on a gigabit network should be fine, which is what I've always found, since that's how I cabled my house, and a number of offices.

[Jarosław Karwik]

I do not know Smoothie protocol stack - but does it support UDP ?

My professional CNC controllers are built around really small IP stack ( old good uIP - https://github.com/adamdunkels/uip ). Very small , only few kB for both code and data.

While it supports only limited functionality , the ping time as well as response time are below 1ms.

The stack basically drops everything except pings, arps and my socket communication.

For fast response and reliability I almost exclusively use it on separate ethernet connection - do not connect it to my office network ( often on USB/ethernet converters), I also use static IP for it.

Because these are UDP packets  ( which might be lost), but in such configuration it basically never happens ( although I do have re-transmission after timeout). I still think it is easier to deal like that then with TCP mysterious state machines.

[Marius Liebenberg]

I looked at the Smoothie source and it would seem that they use uip.

from the a header

* This file is part of the uIP TCP/IP stack
 *
 * $Id: uip-conf.h,v 1.6 2006/06/12 08:00:31 adam Exp $
 */

/**
 * \file
 *         An example uIP configuration file
 * \author
 *         Adam Dunkels <adam@sics.se>
 */

[Jarosław Karwik]

From the docs:

The basic uIP TCP implementation only allows each TCP connection to have a single TCP segment in flight at any given time.

Because of the delayed ACK algorithm employed by most TCP receivers, uIP's limit on the amount of in-flight TCP segments seriously reduces the maximum achievable throughput for sending data from uIP.

The uip-split module is a hack which tries to remedy this situation. By splitting maximum sized outgoing TCP segments into two, the delayed ACK algorithm is not invoked at TCP receivers. This improves the throughput when sending data from uIP by orders of magnitude.

The uip-split module uses the uip-fw module (uIP IP packet forwarding) for sending packets. Therefore, the uip-fw module must be set up with the appropriate network interfaces for this module to work.

I have implemented small uIP app  which handles UDP socket instantly - TCP in uIP is very limited and may have issues when pressed . 

[Marek T.]

I didn't find any info as Smoothie has UDP implemented.

Does anybody have some tcpip client with timestamps logging? Could be good to send some gcode to Smoothie using other soft than OpenPNP and compare the delays if are identical as at OpenPNP case or not.

[Marius Liebenberg]

It was always my standpoint that one must use UDP when it comes to direct links that does not really require big network savvy.

What will it take to do a UDP link on Smoothie?

[Jarosław Karwik]

No much  :-)

You would need to add in int  uip_init_stack(void) call to init function:

DBG("uIP: Init DataStream UDP\r\n");

datastream_init();

Also in uip-conf.h

  

#define UIP_CONF_UDP             1    

The code is executed from uip.c ( my patch - few places to get fast reponse - see my uip code - look for UIP_UDP_APPCALL )

Then the binding

void datastream_send(const char * data, int length);

extern void datastream_receive(const char * data, int length);

The second function - gets called when you get something. This would be the call with GCodes. Then you can send response with second function.

On PC you just open UDP socket - and write / read to it

[Bernd Walter]

On Sat, Jan 12, 2019 at 04:50:12AM -0800, Marius Liebenberg wrote:
> It was always my standpoint that one must use UDP when it comes to direct
> links that does not really require big network savvy.

Using UDP is stupid.
Not every command can be repeated in case of packet loss.
TCP works perfect for that use case, unless used wrong.
My machine runs using multiple TCP streams to several different controllers,
but using PTY since OpenPNP had no TCP support back then.
uIP isn't my first choice, but should do the business and it has no
delay problem at all, which means it is OpenPNP at fault for not disabling
Nagle on the TCP sockets.
I don't know how difficult it is to setup TCP_NODELAY in the Java world,
but this is what has to be done.

> What will it take to do a UDP link on Smoothie?
>

> On Saturday, January 12, 2019 at 10:49:57 AM UTC+2, Jaros??aw Karwik wrote:
> >
> > From the docs:
> >
> > The basic uIP TCP implementation only allows each TCP connection to have a
> > single TCP segment in flight at any given time.
> >
> > Because of the delayed ACK algorithm employed by most TCP receivers, uIP's
> > limit on the amount of in-flight TCP segments seriously reduces the maximum
> > achievable throughput for sending data from uIP.

Delayed ack may be an issue, but I doubt it since whenever OpenPNP
has a new request it sends a packet and this automatically includes the ack.
Nevertheless, delayed ack should have been disabled with TCP_NODELAY as well.
It might be that there is a very theoretical issue with an ack packet send
and a packet with a new request directly behind.
uIP will process the ack and can't take the request, but the interface buffers
should be big enough, unless your local network is shitty and full of broadcast
packets, which would be bad all by itself.

> >
> > The uip-split module is a hack which tries to remedy this situation. By
> > splitting maximum sized outgoing TCP segments into two, the delayed ACK
> > algorithm is not invoked at TCP receivers. This improves the throughput
> > when sending data from uIP by orders of magnitude.

Seriously - a line with OK\n isn't that big to trigger any kind of such issues.
And latency isn't bandwidth.

> > The uip-split module uses the uip-fw module (uIP IP packet forwarding) for
> > sending packets. Therefore, the uip-fw module must be set up with the
> > appropriate network interfaces for this module to work.
> >
> >
> >
> > I have implemented small uIP app which handles UDP socket instantly - TCP
> > in uIP is very limited and may have issues when pressed .

I can't dissagree with this and this is the reason why I prefer using the
Ethernut IP stack in my own projects.
Nevertheless, I doubt that in this case it has anything to do with the delays
seen.
But how about, instead of assuming and guessing, just run a packet tracer, such
as Wireshark and see if smoothie responds in time or delayed...

> >
> >
> > W dniu sobota, 12 stycznia 2019 08:49:26 UTC+1 u??ytkownik Marius
> > Liebenberg napisa??:

> >>
> >> I looked at the Smoothie source and it would seem that they use uip.
> >> from the a header
> >>
> >> * This file is part of the uIP TCP/IP stack
> >> *
> >> * $Id: uip-conf.h,v 1.6 2006/06/12 08:00:31 adam Exp $
> >> */
> >>
> >> /**
> >> * \file
> >> * An example uIP configuration file
> >> * \author

> >> * Adam Dunkels <ad...@sics.se>

> >> */
> >>
> >>
> >>
> >> On Saturday, January 12, 2019 at 8:32:04 AM UTC+2, Jaros??aw Karwik wrote:
> >>>
> >>> I do not know Smoothie protocol stack - but does it support UDP ?
> >>>
> >>> My professional CNC controllers are built around really small IP stack (
> >>> old good uIP - https://github.com/adamdunkels/uip ). Very small , only
> >>> few kB for both code and data.
> >>> While it supports only limited functionality , the ping time as well as
> >>> response time are below 1ms.
> >>> The stack basically drops everything except pings, arps and my socket
> >>> communication.
> >>>
> >>> For fast response and reliability I almost exclusively use it on
> >>> separate ethernet connection - do not connect it to my office network (
> >>> often on USB/ethernet converters), I also use static IP for it.
> >>>
> >>> Because these are UDP packets ( which might be lost), but in such
> >>> configuration it basically never happens ( although I do have
> >>> re-transmission after timeout). I still think it is easier to deal like
> >>> that then with TCP mysterious state machines.
> >>>
> >>>
> >>>
> >>>

> >>> W dniu sobota, 12 stycznia 2019 05:28:33 UTC+1 u??ytkownik Michael Anton
> >>> napisa??:

> >>>>
> >>>> CAT5 is rated for 100Mbps, CAT5e for 1Gbps, and CAT6 for 10Gbps. CAT6
> >>>> is only rated to 10Gbps for up to 164 ft, and above this length it drops
> >>>> down to 1Gbps speed. So, CAT5e on a gigabit network should be fine, which
> >>>> is what I've always found, since that's how I cabled my house, and a number
> >>>> of offices.
> >>>>
> >>>> On Friday, January 11, 2019 at 5:10:56 PM UTC-7, Brynn Rogers wrote:
> >>>>>
> >>>>>
> >>>>> We have gigabit switches at the office, but the cabling is still cat 5
> >>>>> or 5e. And I know my openpnp machines computer gets horrible throughout,
> >>>>> and when trying to try transfer large files (gigabytes) it often fails the
> >>>>> download completely. All because it does not have cat6 cables. At
> >>>>> least I think that is the only problem ;-)
> >>>>>
> >>>>> I wonder if you have cat 5 or cat6 cables...
> >>>>>
> >>>>> Brynn
> >>>>>
> >>>>> On Fri, Jan 11, 2019, 3:47 PM Mark <ma...@makr.zone wrote:
> >>>>>

> >>>>>> *> That's me pinging the gateway on my network, over WiFi. I can send
> >>>>>> and receive 64 bytes in the order of 100 *nanoseconds*.*
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> That???s microseconds, but still awesome! I had no idea, always thought

> >>>>>> Wifi sucks. But my gigabit Ethernet pings at awful 15ms!
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _Mark
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>>
>

> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/60b58a60-d42c-4ea0-b5df-2ffd26e3fcab%40googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[Jarosław Karwik]

I admit that trying to fix OpenPnp is smarter then using UDP ( in my product loosing packets does not cause any harm, but with GCodes it may be disaster )

Try  to put java.net.Socket.setTcpNoDelay()  in driver ( TcpCommunications.java )

    public synchronized void connect() throws Exception {

        disconnect();

        clientSocket = new Socket(ipAddress,port);

        clientSocket.setTcpNoDelay(true);

        input = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));

        output = new DataOutputStream(clientSocket.getOutputStream());

    }

[Jason von Nieda]

Hi all,

Adding no delay is trivial, as Jarosław mentioned. If someone would like to test it and see if it makes a difference, please do, and I'll be happy to add it.

With that said, I'd ask that you re-read my conversation with wolfmanjm, who is the lead developer for the Smoothie firmware:

[13:14:16]  <wolfmanjm>    also you need to turn off the planning queue wait for buffer full when empty

[13:14:29]  <wolfmanjm>    tcp/ip on smoothie is a hack
[13:14:47]  <wolfmanjm>    it is not recommended (by me) to be used so basically it is already very slow
[13:14:55]  <wolfmanjm>    due to memory limitiation

[13:15:23]  <wolfmanjm>    and it is a cobblled tcp/ip protocol where every packet has to be acck'd before the next one can be sent
[13:15:47]  <wolfmanjm>    so if on top of that you wait for an ok, it will be terribly slow

[13:16:31]  <wolfmanjm>    also if you are expecting every single g code to execute immediately you need to set in config ...

[13:17:06]  <wolfmanjm>    queue_delay_time_ms 0

He seems to believe this is a Smoothie issue, not an OpenPnP one.

But either way, if we can make some improvements, let's do it. I'd also suggest testing the `queue_delay_time_ms 0` change in the Smoothie config, too.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9870530b-da70-46dd-aba0-8b443f5cda22%40googlegroups.com.

[Marek T.]

I'll check it in the night with MKS board. It's not Smoothie but if the difference will appear it must be good also for it.

[Marek T.]

Applied and tested. Given nothing, it's MKS but lattency is absolutely identical as before the change - perfectly 500ms for each no-tion command.

I still think we should test it using other client to check if the delays does not just come from the board.

2019-01-12 19:42:21.669 GcodeDriver TRACE: [tcp://192.168.1.222:23] >> G90 ; Set absolute positioning mode
2019-01-12 19:42:22.169 GcodeDriver TRACE: [tcp://192.168.1.222:23] << ok
2019-01-12 19:42:22.169 GcodeDriver TRACE: [tcp://192.168.1.222:23] >> M82 ; Set absolute mode for extruder
2019-01-12 19:42:22.669 GcodeDriver TRACE: [tcp://192.168.1.222:23] << ok

[Marek T.]

[...]for each no-MOtion command[...]

[Jason von Nieda]

Hi Marek,

To be clear, you added the clientSocket.setTcpNoDelay(true); line to OpenPnP, and you added `queue_delay_time_ms 0` to Smoothie config?

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/acb8c3b3-211d-491c-829e-d430dc512da0%40googlegroups.com.

[Jarosław Karwik]

Could you record ethernet traffic using Wireshark ( https://www.wireshark.org ) - and post the log ? This would give fast answer who is responsible

[Marek T.]

So I must have missed a part about Smoothie.
I have only added a line to the openPNP.

[Marek T.]

I'm out of home already now. Will play with smoothie config and traffic logging later in the night or tomorrow.

[Marek T.]

Came back for the momment. Added queue 0ms to the config.

Wireshark later.

2019-01-12 20:36:11.718 GcodeDriver TRACE: [tcp://192.168.1.222:23] >> G90 ; Set absolute positioning mode
2019-01-12 20:36:12.204 GcodeDriver TRACE: [tcp://192.168.1.222:23] << ok
2019-01-12 20:36:12.219 GcodeDriver TRACE: [tcp://192.168.1.222:23] >> M82 ; Set absolute mode for extruder
2019-01-12 20:36:12.704 GcodeDriver TRACE: [tcp://192.168.1.222:23] << ok

So it's better now. Only 485ms instead of 500 priorly ;)

[Marek T.]

Hi

Jarek what kind of log you think is best to export from wireshark?

"Eksportuj prezentacje pakietow jako tekst" should be ok or some other option will be more convenient?

[Marek T.]

ok, one of attached should be ok...

[Jarosław Karwik]

No export - just save in native format. This allows opening it in my Wireshark to dissect it

[Marek T.]

I made both and attached, native pcapng and text for those who don't want the wireshark to have :-)

[Marek T.]

2019-01-14 12:47:01.848 GcodeDriver TRACE: [tcp://127.0.0.1:23] >> G90 ; Set absolute positioning mode
2019-01-14 12:47:02.029 GcodeDriver TRACE: [tcp://127.0.0.1:23] << ok

2019-01-14 12:47:02.040 GcodeDriver TRACE: [tcp://127.0.0.1:23] >> M82 ; Set absolute mode for extruder

2019-01-14 12:47:02.197 GcodeDriver TRACE: [tcp://127.0.0.1:23] << ok

I have connected Openpnp to the software TCP/IP server and returned "ok" manually, it looks I'm quite fast :-)

It shows that if ack comes quick enough it is received by Openpnp without some overkilling delay (if any at all). There is only 150-180ms delay instead of 500ms occuring in case of Smoothieboard.

Well, the difference is it is over local 127.0.0.1 and we don't go through ethernet hardware or cables. However it rather says clearily the problem is not Openpnp, isn't it?

[Jarosław Karwik]

Hmmm,

TCP is much alive ( in Smoothie)  .... just the Telnet protocol is lazy.

Something seriously wrong in Smoothie