The final goal of my experiments with a remote GUI was to demonstrate a Windows computer in control at NAMES 2002. After downloading tkemc.exe from the NIST web site, matching versions of tcl and tk binaries were installed. The self extracting tkemc archive failed to do so at the first attempt, so another copy was downloaded, this time to be extracted successfully.
Samba will probably have to be set up to allow file sharing in order to prevent problems with opening G-code files. I'm not sure how well the use of '\' by DOS or Windows will convert to '/' used by linux.
With the client emc.nml file edited and the -queryhost flag removed from emc.bat, a connection was made with the EMC server. A serious problem has been found with the GUI in use - The X Y Z data is not being displayed correctly, in fact ``Feed Override'' appears to be used for one of the three axis ! The colours of the axis digits are also out of sync with reality, X is red, Y, green, and Z is shown as yellow. Most odd.
After persuading Don McLean to compile emcsh.exe against the current sources (24th March 2002), using Microsoft Visual C++, another attempt was made. This time all the digits responded to the correct axis and the machined could be homed and jogged. Once again, differences in the operating systems caused problems. This time with the way Tcl/Tk and the underlying OS handles paths. Linux will use /emc/programs/foo.ngc, and Windows, C:\emc\programs\foo.ngc. EMC expects the former format to locate and load a G-code file, and the latter just causes an error. For file browsing to work correctly, the emc/programs directory will have to be ``shared'' with the aid of Samba which will add further to the problem of path names.
In conclusion, Whilst operating EMC across a network is possible, using a Windows computer will require some editing of Tkemc to change the way file and path names are handled.