Pure Simulator on Ubuntu 14.04 LTS = True

Hallo..!

I just wanted to report that I just made a successful "Pure Simulator" installation of LinuxCNC on my new, but not quite fresh, Ubuntu Gnome 14.04 LTS. I did install a "bunch" of apps before this one. Ubuntu was installed with the "Gnome flavour" of Ubuntu from start (not the normal "Unity" desktop version, as I can't stand Unity. I really tried, but I failed...).

"Successful" in the meaning: No major issues when building. And I can run LinuxCNC with Axis GUI, home all, and run the demo code. That is how far I have tested it at the moment. So don't take that statement for a fact...

The installation of LinuxCNC was made according the instructions to " Build A Simulator Manually " in the wiki, using the Ubuntu 12.04 section, which gave me LinuxCNC in version 2.7.0-pre0. Two versions ahead of the main release..! Maybe someone could complement the wiki with some instructions on how to get the "current" version?

The installation worked fairly clean, but with there was one issue of which I can't determine its significance. When running the check for dependencies, there was a stated dependency to the packet "libgnomecanvas2-dev" that can't be satisfied. The packet is missing in the Ubuntu repository for 14.04 (while existing in 13.10). I simply ignored the missing dependency, and went ahead compiling without it.

This is the list of missing packages that had to install prior compiling:

$ sudo apt-get install libpth-dev dvipng texlive-extra-utils texlive-latex-recommended texlive-fonts-recommended texlive-lang-french texlive-lang-spanish texlive-font-utils bwidget blt libxaw7-dev libncurses-dev libreadline-dev asciidoc source-highlight dblatex groff libglu1-mesa-dev libgl1-mesa-dev autoconf libboost-python-dev texlive-lang-cyrillic texlive-lang-german libmodbus-dev libusb-1.0-0-dev

I saw no errors or warnings related to the missing package, but I could certainly have missed it. The only warning I noticed Was this:

Compiling emc/task/emctaskmain.cc
emc/task/emctaskmain.cc: In function ‘int emcSystemCmd(char*)’:
emc/task/emctaskmain.cc:346:18: warning: ignoring return value of ‘int setuid(__uid_t)’, declared with attribute warn_unused_result [-Wunused-result]
setuid(getuid());
^

But according to my (very limited) experience of compiling, warnings should not be taken too seriously..?

Anyhow - LinuxCNC seams to run without issues - I'm happy...

Oh yes - one more thing...
The last part in the instructions on the wiki-page, about adding LinuxCNC to your PATH isn't correct.
It says:

export PATH=$PATH:[path to the linuxcnc dir]/linuxcnc/scripts/rip-environment

but should be:

export PATH=$PATH:[path to the linuxcnc dir]/linuxcnc/scripts/

("rip-environment" is a script-file and a file can not be included in the PATH)

And the command to run LinuxCNC only works if your current folder is ~git/linuxcnc/
If you have set your PATH as above you can start LinuxCNC from anywhere, just by typing: linuxcnc

The wiki should be updated here...

Yes, I read the instructions after I made that post. I was curious to see if I could... but I failed in guessing the "mascot name". Could anyone send me a message?

And I'd still like some confirmation that my suggestions isn't just as wrong as I believe the wiki is - or worse...
John, if you implied something like that in your post, I didn't get it...


Meanwhile I made a not quite as successful attempt to install a simulator from the v2.5_branch in git. I got it working, but not without some shortcomings.

I made a copy of my linuxcnc folder in ~/git, so that I can have both the master and the 2.5 versions on my system. Both versions will then use the same preferences files in my home root, and this could perhaps cause some problems?

This time I had both dependencies problems and compiling errors. The 2.5 version depends on tcl tk 8.4 but installing those didn't work since Python Tkinter in my system requires tcl tk 8.6.
So I ignored the tcl tk 8.4 dependency and tried to compile with tcl tk 8.6. Two files failed:

• emc/usr_intf/emcsh.cc
• emc/usr_intf/axis/extensions/_toglmodule.c

Both with basically the same error: ‘Tcl_Interp’ has no member named ‘result’

Compiling emc/usr_intf/emcsh.cc
emc/usr_intf/emcsh.cc: In function ‘int emc_pendant(ClientData, Tcl_Interp*, int, Tcl_Obj* const*)’:
emc/usr_intf/emcsh.cc:3290:22: error: ‘Tcl_Interp’ has no member named ‘result’
sprintf(interp->result, "%i %i %d %d %i", inBytes[0],
^
make: *** [objects/emc/usr_intf/emcsh.o] Fel 1

As I'm not much of a programmer, so I can't really analyse the problem. But I'm curious... So I compared the lines of code that gave the errors, with the corresponding files in the "master" git branch (that I already have successfully compiled for the 2.7 version). The difference is small. Just for fun, and having absolutely no idea of the outcome, I decided to snatch the relevant code lines from the 2.7 files and paste them into the 2.5 version files, and then compiled - and it went trough..!

Success..? well... I think one have to expect a bunch of problems from using tcl tk 8.6 in stead of 8.4, and some problems from the files I manipulated. So I think there is very limited use for this installation. To me it seems unlikely it would be worth the effort to fix the broken dependency. On a dedicated system one could perhaps downgrade Python Tkinter to accept tcl tk 8.4, but on a dedicated system I wouldn't use Ubuntu 14.04...

Apart from that, I can now start LinuxCNC v2.5.4 with Axis, load a profile and run a program. The defects I have come across so far is perhaps a bit unexpected (or not...), and is probably related to the faulty tcl tk version. Clearly indicating that this build isn't operational.

• The "Preview" screen doesn't sow any "offset" values when "Show offsets" is selected in the "View" menu.
• The values in the "DRO" tab doesn't update its position values unless the machine is moving while the tab is selected.

The master requires tcl8.5 / tk8.5

Whether you can downgrade to 8.5 without causing huge problems is another matter, depends how much stuff on your system relies upon 8.6

tcl and tk are near the end of their shelf life, hopefully to be replaced with something altogether better before too long

regards

So I shouldn't expect proper functionality of my master v2.7 build running with tcl tk 8.6?
Even though there were no reported conflicts, as I had for v2.5.

And thanks for the password... I've only heard of him as "Tux"

So I shouldn't expect proper functionality of my master v2.7 build running with tcl tk 8.6?
Even though there were no reported conflicts, as I had for v2.5.

The error sounds rather as though there is a backward incompatibility between the lib versions.
Tcl_Interp has been changed.

You could try installing 8.5 using synaptic and then see what it tells you would be removed if you ask it to remove 8.6

The chances are however that it will be an unacceptably long list which relies on it, so you may already have the best solution for you.

regards

If you want to fix in a programmatic way.

It looks like instances of sprintf(interp->result,........)
can be replaced with
sprintf(Tcl_GetStringResult(interp),....................)

There is quite a lot on line about similar problems, I got this from taking apart somones patch for another project with the same error.

would automate it for each dir (use with caution, perhaps on a spare copy, because this substitutes in-line)

regards

see:

commit 37c70c2e346a74a465a446cd425b1c3ba60c5a5e
Author: Jeff Epler <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Wed Oct 9 08:06:23 2013 -0500

emcsh: don't directly write to interp->result

This has been defined as not working for quite a long time. It looks
like this routine is probably unused, but fix it anyway. (sfbugs#332)

git.linuxcnc.org/gitweb?p=linuxcnc.git;a...e7aca2e65711c83b0729

I'm afraid I made a mess of this topic when I brought in another version of LinuxCNC to the discussion. I'm sorry...

Maybe I got you all wrong ArcEye, but I think you mixed up which version that had errors.

• Building and compiling the master branch (v2.7.0) with tcl/tk8.6, gave no errors or dependency problems, and I've seen no issues when running LinuxCNC with Axis (still very limited testing).
• It was when I switched to the v2.5_Branch, and compiling with tcl/tk8.6 I got the errors about Tcl_Interp. One of the changes I made in the code to make it work, was exactly the same as in the commit dgarrett linked to.

ArcEye, I guess both your last posts relate to fixing the "problems" with the master 2.7 version? Problems that might not exist, or at least, I haven't observed - yet...
But I did check out the possibility to downgrade tcl/tk from 8.6 to 8.5 in my system as you suggested. And it turned out to be quite doable. Only 4 packages would "break".

• bwidget - Extension widgets for Tcl/Tk
• expect-dev - Automates interactive applications (development)
• libtk-img - Extended image format support for Tcl/Tk (runtime)
• ssvnc - Enhanced TightVNC viewer

If the master v2.7 branch is designed for tcl/tk 8.5, downgrading might not be such a bad idea.

By the way - would you generally recommend to avoid the master branch v2.7 for the moment, in favour for the v2.6 branch? (regardless of Ubuntu version) Supposing v2.6 to be a bit more stable version for testing? Jumping all the way to v2.7 seams to be a bit... excessive?

Maybe I got you all wrong ArcEye, but I think you mixed up which version that had errors.

Yes I think there was some scope for confusion

Only 4 packages would "break".

bwidget - Extension widgets for Tcl/Tk
expect-dev - Automates interactive applications (development)
libtk-img - Extended image format support for Tcl/Tk (runtime)
ssvnc - Enhanced TightVNC viewer

You might find bwidget was enough to be fatal unless you can get around it with the earlier lib, and I seem to remember libtk-img is required as well

By the way - would you generally recommend to avoid the master branch v2.7 for the moment, in favour for the v2.6 branch?

That entirely depends what you want to do.

If you are just running a simulator it would probably be sensible to keep it as simple as possible,
but on the other hand 2.7 at present is just 2.6 with bits that should be in it but were left out, like ubc3, new TP etc.

regards