Failure to connect produces Java exception #1341
Comments
|
Note, the comments in G-code COMMANDs, delimited by semicolon, are a feature of the standard G-code syntax, not of OpenPnP. Normally these comments are sent as-is to the controller, that ignores them. There is an option on the Driver to strip them off, but purely as an optimization. However, unlike the COMMANDs, the REGEX need to be verbatim, i.e. they must not contain a semicolon. So you need to remove it. But... Having such a generic COMMAND_CONFIRM_REGEX will likely create problems. Usually a controller has a specific response to confirm a command, usually it contains an "ok" string. Are you sure there is no way to make LinuxCNC respond like this too? Or is "ACK" the keyword to confirm a command for LinuxCNC? Then make sure it is required by the COMMAND_CONFIRM_REGEX. Otherwise, any unsolicited status message by LinuxCNC will be mistaken as command confirmation. OpenPnP will likely become out of sync. For this to work, you would have to be absolutely sure that LinuxCNC never ever sends unsolicited messages, or multiple line responses. There is another option available in OpenPnP: Location Confirmation. However, you need to proceed Issues & Solutions to the Advanced Milestone, for the GcodeAsyncDriver conversion to become available. Only after you have converted, can you enable that option. It would be much better if you found a way to get the "ok" response (or confirm that "ACK" is it). https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#settings _Mark |
|
With the COMMAND_CONFIRM_REGEX as ACK|.* gave Apparently the state machine for the communications is left hanging as the second time the connect command is issued causes the message 2021-12-02 09:01:33.768 GcodeDriver$ReaderThread ERROR: Read error: java.net.SocketException: Socket closed to be issued. So the problem is out of the GcodeDriver and into the message Boxes ... From what I've been able to determine the response of LinuxCNC to any command will be an echo of the command followed by ACK for success and NAK for a failure. As to you question of changing the response of LinuxCNC, a set of programs with a pedigree going back over 30 years, I think I would rather eat nails. No, I would hope that a workable solution lies elsewhere. |
|
The problem might be solved by placing an "Interposer" between the two machines. This could be done by changing the port number of the LinuxCNC from 5007 to lets say 5077. Another Telnet listener at port 5077 translates the responses of one to the other so it listens for ACK on port 5007 and sends it on to port 5077 as ok. |
|
No, you just need to get the REGEX right. I'm no REGEX expert myself, but there are online REGEX explorers, where you can test your responses against them. As I guess, try this for COMMAND_CONFIRM_REGEX:
And this for the COMMAND_ERROR_REGEX:
_Mark |
|
2 down 16 to go:) |
|
It didn't take long to discover that not all commands issue a response, thus generating a timeout error. How does one do a REGEX on nothing? |
|
Looking further I see that in fact the line was echoed. |
|
Suddenly my day improved with the following... including the ability to move the gantry left, forward and back. The following is for a Linux system running LinuxCNC. Those commands that are not listed have not as yet been modified. .NAK. COMMAND_ERROR_REGEX hello EMC X 1.1 CONNECT_COMMAND set enable EMCTOO ENABLE_COMMAND set enable EMCTOO HOME_COMMAND ^.*ACK|set mode mdi HOME_COMPLETE_REGX get abs_cmd_pos GET_POSITION_COMMAND set mdi G0 {X:X%.4f}{Y:Y%.4f}{Z:Z%.4f} MOVE_TO_COMMAND echo ok MOVE_TO_COMPLETE_COMMAND ^SET MDI ACK|ok MOVE_TO_COMPLETE_REGEX |
|
Strange. I thought LinuxCNC was a true G-code interpreter. |
|
In order to remotely connect to LinuxCNC it is necessary to use linuxcncrsh, a remote shell. So while the local host is a true AFAIK G-code interpreter, it is necessary to use an intermediary command language/interface (MDI) that sends commands to the HALCMD that runs in the background. I don't run openpnp on the CNC machine as it is a very old and slow motherboard that still has the parallel printer port native to the motherboard. The two machines are connected via ethernet with the cameras running back to the faster Linux box via an Adnaco fiber optic PCIe bus extender. |
|
Are you sure there is no other way? I'm quite sure, there's tons of software out that expects to be able to speak with LinuxCNC in plain G-code, over a plain socket. _Mark |
|
I'll take two pounds please. Having more than one solution to my problem would certainly be helpful. I know for instance that Machinekit may offer a path to joy. Behind the curtain of Linuxcnc there is a program called halcmd that runs as a os service. The nameless "tons of software" would no doubt make use of that. However, I've boards to build, and precious little time to spend searching for hypothetical solutions. |
|
Am I right to assume this is resolved with your comment here? _Mark |
|
Seems defunct. |
Problem Report
The system consists of two Linux machines one running openpnp the other Linuxcnc.
Two cameras are making nice images in their respective windows.
A telnet to 192.168.0.167:5007 is successful in controlling the CNC. The attached log from a fresh start shows that the first attempt at connect did not result in a recognition of the response HELLO ACK EMCNETSRV 1.1. The second attempt resulted in a Java Socket Exception and again ignoring the response.
Expected result.
So I click the little green button and expect to see NO timeout error and a second line responding to
Actual result.
set EMCTOO ;responds with
set EMCTOO ACK
2021-12-01 16:17:25.675 Main INFO: Bienvenue, Bienvenido, Willkommen, Hello, Namaskar, Welkom, Bonjour to OpenPnP version 2021-11-07_20-21-52.810146e.
2021-12-01 16:17:25.676 Scripting TRACE: Scripting.on Startup
2021-12-01 16:17:27.087 CameraView DEBUG: Failed to load camera specific reticle, checking default.
2021-12-01 16:17:27.087 CameraView DEBUG: No reticle preference found.
2021-12-01 16:17:27.089 CameraView DEBUG: Failed to load camera specific reticle, checking default.
2021-12-01 16:17:27.090 CameraView DEBUG: No reticle preference found.
2021-12-01 16:17:28.699 AbstractBroadcastingCamera TRACE: Camera DownMicroscope thread 34 started.
2021-12-01 16:17:28.702 CameraView DEBUG: Failed to load camera specific reticle, checking default.
2021-12-01 16:17:28.703 CameraView DEBUG: No reticle preference found.
2021-12-01 16:17:29.402 AbstractBroadcastingCamera TRACE: Camera UpMicroscope thread 36 started.
2021-12-01 16:17:29.402 CameraView DEBUG: Failed to load camera specific reticle, checking default.
2021-12-01 16:17:29.403 CameraView DEBUG: No reticle preference found.
2021-12-01 16:17:31.203 AbstractBroadcastingCamera TRACE: Camera WideFieldDown thread 38 started.
2021-12-01 16:18:20.902 ReferenceMachine DEBUG: setEnabled(true)
2021-12-01 16:18:22.287 GcodeDriver DEBUG: [tcp://192.168.0.167:5007] >> hello EMC x 1.1, 1000
2021-12-01 16:18:22.337 GcodeDriver$ReaderThread TRACE: [tcp://192.168.0.167:5007] << HELLO ACK EMCNETSVR 1.1
2021-12-01 16:18:23.337 MessageBoxes DEBUG: Enable Failure: tcp://192.168.0.167:5007 timeout waiting for response to hello EMC x 1.0
2021-12-01 16:19:30.076 ReferenceMachine DEBUG: setEnabled(true)
2021-12-01 16:19:30.078 GcodeDriver$ReaderThread ERROR: Read error: java.net.SocketException: Socket closed
at java.base/java.net.SocketInputStream.socketRead0(Native Method)
at java.base/java.net.SocketInputStream.socketRead(SocketInputStream.java:115)
at java.base/java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140)
at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.base/java.io.InputStreamReader.read(InputStreamReader.java:181)
at java.base/java.io.BufferedReader.fill(BufferedReader.java:161)
at java.base/java.io.BufferedReader.read(BufferedReader.java:182)
at org.openpnp.machine.reference.driver.TcpCommunications.read(TcpCommunications.java:70)
at org.openpnp.machine.reference.driver.ReferenceDriverCommunications.readUntil(ReferenceDriverCommunications.java:91)
at org.openpnp.machine.reference.driver.ReferenceDriverCommunications.readLine(ReferenceDriverCommunications.java:71)
at org.openpnp.machine.reference.driver.GcodeDriver$ReaderThread.run(GcodeDriver.java:1262)
2021-12-01 16:19:33.131 GcodeDriver DEBUG: [tcp://192.168.0.167:5007] >> hello EMC x 1.1, 1000
2021-12-01 16:19:33.454 GcodeDriver$ReaderThread TRACE: [tcp://192.168.0.167:5007] << HELLO ACK EMCNETSVR 1.1
2021-12-01 16:19:34.453 MessageBoxes DEBUG: Enable Failure: tcp://192.168.0.167:5007 timeout waiting for response to hello EMC x 1.0
The regex for CONNECT_COMMAND is
hello EMC x 1.1
set enable EMCTOO
COMMAND_CONFIRM_REGEX is
.*; which has been determined to match with HELLO ACK EMCNETSVR 1.1
SInce the Gcode command strings within GcodeDriverGcodeAsyncDriver are apparently refer to the TinyG. Is there a corresponding set of command strings for LinuxCNC
OpenPnP.log
connectProblem.zip
?
The text was updated successfully, but these errors were encountered: