Version 2.9 .nml file and xemc remote

I noticed that Linuxcnc version 2.9 was not using my custom .nml file from its location in configs-common so I went looking why that was. Linuxcnc 2.9 woked fine with its default linuxcnc.nml but would not run with my x1Mill.nml file.

First I had to make changes to my .nml file due to v2.9 changes within the .nnl file v2.9 update.

Increased value to 8192 in this line, the original 4096 is to small now:
B toolSts SHMEM localhost 8192 0 0 5 16 1005 TCP=5005 xdr

Had to also copy these lines over to my file:
P xemc emcCommand LOCAL localhost W 0 10.0 0 10
P xemc emcStatus LOCAL localhost R 0 10.0 0 10
P xemc emcError LOCAL localhost R 0 10.0 0 10

In script file 'linuxcnc' I see that there is a name change for the server.
EMCSERVER=linuxcncsvr

And in the linuxcnc script file a bit further on there is:
# 2.9. get NML config information
GetFromIniEx NML_FILE LINUXCNC NML_FILE EMC /home/cnc/linuxcnc-dev/configs/common/linuxcnc.nml
NMLFILE=$retval
export NMLFILE

For me the .nml wanted is x1Mill..nml so changed the line to read:
GetFromIniEx NML_FILE LINUXCNC NML_FILE EMC /home/cnc/linuxcnc-dev/configs/common/x1Mill.nml
But still got errors loading that stopped the load process.

Ended up editing my .ini file (x1Mill.ini.expanded) and added the last two lines in the below which solved loading issues with my custom .nml file:

[EMC]
VERSION = 1.1
MACHINE = x1Mill Version 1.0.0.0
EMCSERVER = linuxcncsvr (just a name change here)
NML_FILE = /home/cnc/linuxcnc-dev/configs/common/x1Mill.nml

Not sure if my methods of solving this are 100% correct.

I have been running with this new configuration for some hours now and something is really wrong. My normal network interface is not working anymore and xemc appears to have been hijacked and is being used exclusively to continuously poll the Linuxcnc status buffer at a high rate without me being logged into port 5005.

The Port 5005 hijack appears to make it strictly a localhost port and ties xemc to it from I can tell. See the below.

Starting LinuxCNC...
(time=1570495589.386716,pid=2754): Registering server on TCP port 5005.
(time=1570495589.387484,pid=2754): running server for TCP port 5005 (connection_socket = 3).
iocontrol: machine: 'x1Mill Version 1.0.0.0' version 'unknown'
(time=1570495589.431542,pid=2754): Socket opened by host with IP address 127.0.0.1.
(time=1570495589.431593,pid=2754): read 20 bytes from 4
(time=1570495589.431617,pid=2754): TCPSVR request received: fd = 4, serial_number=1, request_type=12, buffer_number=1

The above line looks similar to my polling request that would normally come ip address 10.10.20.1 but that computer is turned off. Thus it looks like this unwanted polling is coming from inside Linuxcnc itself. Gstat??

My .nml file looks like this right now with the first 3 lines shown commented out..
#P xemc emcCommand LOCAL localhost W 0 10.0 0 10
#P xemc emcStatus LOCAL localhost R 0 10.0 0 10
#P xemc emcError LOCAL localhost R 0 10.0 0 10

P xemc emcCommand REMOTE 10.10.20.1 W 0 10.0 0 10
P xemc emcStatus REMOTE 10.10.20.1 R 0 10.0 0 10
P xemc emcError REMOTE 10.10.20.1 R 0 10.0 0 10
P xemc toolCmd REMOTE 10.10.20.1 W 0 10.0 0 10
P xemc toolSts REMOTE 10.10.20.1 R 0 10.0 0 10

I will look into this a bit more. Forcing a error mentions IPC_STAT which I think is normally hidden.

I have been doing more testing and from what my testing has shown is that xemc can no longer be set to remote without debug showing continues polling of the status buffer. If set to local the polling does not show up at all. It also does not seem to accept any commands except those related to status request. Is this a problem just on my systems or has xemc been taken by gremlins in v2.9 ?

It seems to always open on local host at 127.0.0.1.

For the most part I have traced this problem down to halui.cc which wants to be run at local host with the ID of xemc. Likely all part of the status polling system that GStat uses that listens to messages being sent internally by NML, and uses the them to control how and what a local gui can do. Unfortunately this totally conflicts with commands coming from a network interface.

As an example recently I was doing some testing with my networked gui. For this test I replaced my normal 'dummy' Gui running the Linux computer that interfaces with my milling machine with Gmoccapy which uses Gstat a lot. I switched my networked gui running on a windows machine to auto mode and send the commands to load a file and run it. As soon as I did this Gmoccapy changed from its initial mode screen to its auto mode screen and followed along, including displaying the file I loaded with my remote gui and also tracing it out in its preview display. It should be noted that my commands are sent directly to the NML interface via the network on port 5005 and not tied to Gmoccapy in any way.

I think there needs to be a way to completely disable Gstat but I'm thinking that as it is built right now it might take halui with it. My networked gui does its won polling directly from the status buffer and has no use for Gstat.

In version 2.9 the size if the status buffer reply has increased substantially from 8244 bytes to 9196 bytes but I have found no information on what is placed in the added area or a map on how to access what ever is there by byte offset..

Andy,

The reason I use a custom NML file at times is so my remote TCP addreses do not get wiped out if I happen to make new clones of Linuxcnc or other changes that may install a new copy of a .nml file.

Usually I would assign the name xemc to the remote but now in 2.9 that name is assigned to localhosts. So I used my own process name when assigning remote addresses. I also rename the NML file so I can be assured that It loads the configuration that I expect for sure instead of the Linuxcnc defaults that may not have remote TCP addresses or incorrect addresses..