Hal and python3.
I'm writing a Python GUI to interface with HAL only, and I'm doing it with python2.7, because python3 is not importing hal module.
But now and then I'm looking at how to do it, because soon or later I want to (have to) use python3.
Hal, alone, should be simple to port to python3, and I would like to help in this, but I'm not the Master, so I'm hitting my first wall..
when importing (in python3) the resulting error is:
dab@dab-lcnc-vm:/usr/lib/python3.5/dist-packages$ python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hal
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.5/dist-packages/hal.py", line 34, in <module>
import _hal
ImportError: No module named '_hal'
>>>
#!/usr/bin/env python3
The problem is that I really don't know why _hal module is not found at all..
obviously if doing 'import hal' from python2 consolle it import it without problems.
Do you have some hint about it?
Since I cannot find _hal.i386-linux-gnu.so into the source code on github, my question is: is it created at compile time, during installation? what source is it compiled from?
Thanks, Davide.
Please Log in or Create an account to join the conversation.
I myself added an experimental branch that uses cython to add python3 HAL to linuxcnc.
There was a post today about another attempt:
github.com/LinuxCNC/linuxcnc/issues/403#issuecomment-547125870
I have never seen a file named: _hal.i386-linux-gnu.so
it should be _hal.so and be in lib/python (in a RIP project)
Chris
Please Log in or Create an account to join the conversation.
I'm working on a virtualized copy of my working system, which is last 2.9 installed in Debian Stretch. to be honest I don't remember if I downloaded an already cooked iso (probably) or if I installed kernel and lcnc on my own, but there's no _hal.so and no /lib/python folder at all!I have never seen a file named: _hal.i386-linux-gnu.so
it should be _hal.so and be in lib/python (in a RIP project)
Chris
dab@dab-lcnc-vm:~$ uname -a
Linux dab-lcnc-vm 4.9.0-9-rt-686-pae #1 SMP PREEMPT RT Debian 4.9.168-1+deb9u5 (2019-08-11) i686 GNU/Linux
dab@dab-lcnc-vm:~$ sudo locate _hal.i386
/usr/lib/python2.7/dist-packages/_hal.i386-linux-gnu.so
/usr/lib/python3/dist-packages/_hal.i386-linux-gnu.so
dab@dab-lcnc-vm:~$ sudo locate _hal.so
dab@dab-lcnc-vm:~$
Please Log in or Create an account to join the conversation.
Chris
Please Log in or Create an account to join the conversation.
I can report that importing hal works with python3, but since I've built the code as run-in-place, I had to add:
sys.path.append('/home/dab/linuxcnc/lib/python/')
another issue with rip is that when closing the window, I have to call
halrun -U
halrun_U = "/home/dab/linuxcnc/scripts/halrun -U"
os.system(halrun_U)
Anyway, it seems to me that a lot of good work has already been done on that branch, as I've tried also Axis and it seems to work (in sim mode), and as python 2 has to be left behind, I think this should be one of the main lcnc developers targets. As far as I can I'll help with this too.
Thanks, Davide.
Please Log in or Create an account to join the conversation.
another issue with rip is that when closing the window, I have to call
With a RIP build, you must source the rip-environment
script in *every* shell attempting to run LinuxCNC, or
halrun, or any other LinuxCNC-specific scripts or
executables. The script is also needed to set
environmental variables for locating scripting language
modules/libraries.
The script establishes the correct environmental
variables for:
1) PATH (used for locating executables)
2) PYTHONPATH (for locating python modules)
3) TCLLIBPATH (for locating tcl libraries)
4) etc.
Example session (on buster testing dgarr/py3):
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
$ which python
/usr/bin/python
$ python --version
Python 3.7.3
$ python
Python 3.7.3 (default, Apr 3 2019, 05:39:12)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hal
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'hal'
>>>
$
$ # fix by sourcing rip-environment in your linuxcnc-dev directory:
$
$ source /home/git/linuxcnc-dev/scripts/rip-environment
$ python
Python 3.7.3 (default, Apr 3 2019, 05:39:12)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hal
>>> dir(hal)
['HAL_BIT', 'HAL_FLOAT', 'HAL_IN', 'HAL_IO', 'HAL_OUT', 'HAL_RO', 'HAL_RW', 'HAL_S32', 'HAL_U32', 'MSG_ALL', 'MSG_DBG', 'MSG_ERR', 'MSG_INFO', 'MSG_NONE', 'MSG_WARN', 'Param', 'Pin', '_ItemWrap', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', '_hal', 'component', 'component_exists', 'component_is_ready', 'connect', 'error', 'get_msg_level', 'get_value', 'is_kernelspace', 'is_rt', 'is_sim', 'is_userspace', 'item', 'new_sig', 'pin_has_writer', 'sampler_base', 'set_msg_level', 'set_p', 'stream', 'streamer_base']
>>>
NOTE: If a system has both RIP build and a deb install, things can
get *very* confusing if you are not careful. I usually uninstall
LinuxCNC debs when testing RIP builds.
Please Log in or Create an account to join the conversation.
if doing:
rip_cmd = ('source /home/dab/linuxcnc/scripts/rip-environment')
print(subprocess.call(rip_cmd, shell=True))
import hal
/bin/sh: 1: source: not found
...
A workaround I used in the meantime is this:
sys.path.append('/home/dab/linuxcnc/lib/python/')
rip_cmd = '/home/dab/linuxcnc/scripts/rip-environment'
import hal
halrun_U = rip_cmd + " halrun -U"
os.system(halrun_U)
..or..
launch_halcmd = rip_cmd + ' halcmd -v -f halga.hal'
os.system(launch_halcmd)
Please Log in or Create an account to join the conversation.
Unfortunately it doesn't work from python
The 'source' (equivalently '.') command is a shell
(/bin/bash) *builtin*. You need to 'source' the
rip-environment script in the terminal *BEFORE*
invoking your python script in order to populate the
environmental variables needed to find LinuxCNC
executables and the modules or libraries used for its
scripting languages (python,tcl). The environmental
variables created by sourcing the rip-environment
script will then be available to child processes (eg
python scripts) of the terminal process.
Example (using /home/git/linuxcnc-dev as the root directory for a
LinuxCNC RIP build):
$ source /home/git/linuxcnc-dev/scripts/rip-environemnt
$ python
...
>>> import os
>>> os.environ.get('PYTHONPATH')
'/home/git/linuxcnc-dev/lib/python'
Ref:
For modern Linux distributions, the default shell used
in a terminal is bash (/bin/bash)
$ man bash
...
SHELL BUILTIN COMMANDS
...
. filename [arguments]
source filename [arguments]
Read and execute commands from filename in the current shell en‐
vironment and ... (much more)
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
I run my code from inside pycharm.
I don't know anything about pycharm but find it suprising
that it doesn't propagate a shell environment. Perhaps
you start pycham from a menu -- if so, you could try
starting pycharm in a terminal *after* sourcing rip-environemnt.
If that guess is unhelpful, you would need to set all the
the paths required by LinuxCNC within your python program.
You can ascertain which items are set or updated by
rip-environment by comparing the environment before and
after sourcing rip-environment. Example:
$ # new shell before sourcing rip-environment
$ env >| before.txt
$ source /home/git/linuxcnc-dev/scripts/rip-environment
$ env >| after.txt
$ diff before.txt after.txt
Please Log in or Create an account to join the conversation.