Python interface states of the home switches?

More
25 Mar 2018 10:11 - 25 Mar 2018 10:18 #107803 by newbynobi
If you do use GStat (/lib/python/hal_glib.py) you can connect your GUI to the signal "homed" of gstat and react to the change of the homing state of each joint.
from hal_glib import GStat
self.gstat = GStat()
self.gstat.connect('homed', self._homed)
self.gstat.connect('not-all-homed', self._not_homed)

def _homed(self, object, joint):
    print("Joint {0} has been homed".format(joint))

def _not_homed(self, object, unhomed_joints):
    print("Joints {0} are not homed".format(unhomed_joints))
Norbert
Last edit: 25 Mar 2018 10:18 by newbynobi.

Please Log in or Create an account to join the conversation.

More
02 Apr 2018 12:02 #108257 by mungkie

Sorry i wasn't clear - I haven't pushed the code to master yet.
If you are using 2.7.x then this will never work.
If you are using master I could cherry pick the code and push to master in a day or so.

Chris M


I do not follow linuxcnc dev so not sure how this is going, but a very brief search found no 2.8(do you mean machinkit?) and no cherry pick of this code into master.

Would it be possible for someone to post the code for direct control of hal with python, I have been doing it through
Popen(halcmd .....
for the last 5 years, the new system sounds very useful (could just drop in the file in lib/python/? ).

Please Log in or Create an account to join the conversation.

More
02 Apr 2018 15:00 #108260 by cmorley
2.8 will be the next major release of linuxcnc, there actually is no 2.8 right now.
any reference to 2.8 probably meant the master branch, as that will be 2.8 in the future.

I did not cherry pick the code - It wasn't going to be a solution for anyone using 2.7.
It will be added to master when I merge my QTvcp/QTscreen work.

But if you are using a compiled version of linuxcnc you could cherry pick it in to 2.7.
Or if you intend to use master I can cherry pick it in to master.

The code I added only adds the ability to read pins/signals without connecting to them.
The python module is not a complete replacement for halcmd.
Though it can still do quite a bit.

Chris M

Please Log in or Create an account to join the conversation.

More
03 Apr 2018 01:11 #108277 by mungkie

2.8 will be the next major release of linuxcnc, there actually is no 2.8 right now.
any reference to 2.8 probably meant the master branch, as that will be 2.8 in the future.

I did not cherry pick the code - It wasn't going to be a solution for anyone using 2.7.
It will be added to master when I merge my QTvcp/QTscreen work.
Chris M


Is there a roadmap of possible feature list for 2.8 yet?

if you could easily dump the relevant python code for
hal.get_value()
r any other functions you may have implemented that would be very nice to peruse.

I have never bothered to check the files in lib/python/ to see how the low level implementation is done for the hal.py interface but may do that eventually.

How did you implement your hal access are you using ctypes or an alternative?

I did some work on a web based hal interface that was very much an axis ripoff but only 80% feature complete, I got other projects that became more important and so its been in a drawer for almost 2 years now, but when I get back to it would be very interested to simplify some of the stuff that was implemented with popen calls to halcmd.

Please Log in or Create an account to join the conversation.

More
03 Apr 2018 05:22 #108289 by cmorley
here is a patch file that will apply to 2.7 if you wish.

Chris M
Attachments:

Please Log in or Create an account to join the conversation.

More
04 Apr 2018 12:01 #108369 by mungkie

here is a patch file that will apply to 2.7 if you wish.

Chris M


Many thanks for posting code, I appreciate your effort though unfortunately not sure it was what I was hoping for.

I did find 2.8 on git, seems it is a tag not a branch??? github.com/LinuxCNC/linuxcnc/tree/v2.8.0-pre1

Anyways I posted 10 years ago about what future of cnc maybe, but seems the post is erased from the forum?

I know it is too easy to chitchat bluesky and I am doubtful going to do the required to implement thoughts.

But would be nice if linuxcnc 2.8 had some sort of roadmap and maybe push ideas to the college kids to implement as final projects.

I have been sort of hoping that hal could be implemented as some standard C api/abi library as that would simplify other language bindings to hal control (compile halcmd as position independant code).

Lots of other ideas, maybe I should start a wiki page, though I doubt my ideas are worth mentioning, last one that google finds is wiki.linuxcnc.org/cgi-bin/wiki.pl?Topics...sionAt_EMC_Fest_2005

Machinekit did some amazing work, but I hate for see linuxcnc fork, and I am not certain machinekit is optimal, I wonder where everything is going?

Please Log in or Create an account to join the conversation.

More
04 Apr 2018 12:06 #108370 by mungkie
Oooh wait google sucks, its already in the wiki....

wiki.linuxcnc.org/cgi-bin/wiki.pl?Lncnc_3_Idea_Whiteboard

Please Log in or Create an account to join the conversation.

More
05 Apr 2018 12:48 #108445 by andypugh
Quite a lot of that wish-list has happened. (Or was already there).

I think we have had loadable interpreters for quite a long time, it is just that nobody seems to ever use the feature.

Joint-Axes has been merged.

We have many-line lookahead.

I have a patch that supports multiple spindles, I will merge it _after_ 2.8 is out.

We chose Asciidoc rather than Doxygen. But the effect is much the same.

Please Log in or Create an account to join the conversation.

More
23 Jun 2019 21:23 #137672 by lorenzn
I see Chris checked in the enhancement (Nov 2018) to get the value of any pin from Python. I tested this with the 2.8 branch. Very useful. I have a list of pins in pc.pins. I tested that I can access the value of each pin with hal.get_value().:
    for p in pc.pins:
        print('{} = {}'.format(p.pinname, hal.get_value(p.pinname)))

The odd issue I haven't solved is that calling <thecomponent>.getitem() fails:
    for p in pc.pins:
        #this is OK
        print('{} = {}'.format(p.pinname, hal.get_value(p.pinname)))

        print('this is my hal component = {}'.format(pc.h))
        #this fails
        print('this fails: {} = {}'.format(p.pinname, pc.h.getitem(p.pinname)))

result:
panelinterface.pyvcp.rapid-machine-zero = False
this is my hal component = <hal component panelinterface(71) with 4 pins and params>
Traceback (most recent call last):
File "/home/lorenzn/cnc2/platform/bin/../bin/panelinterface.py", line 84, in <module>
print('this fails: {} = {}'.format(p.pinname, pc.h.getitem(p.pinname)))
AttributeError: Pin 'panelinterface.pyvcp.rapid-machine-zero' does not exist
Shutting down and cleaning up LinuxCNC...


In summary I have a workaround in using hal.get_value(). I don't know why accessing the pin value from the component fails.

Please Log in or Create an account to join the conversation.

More
23 Jun 2019 21:43 #137677 by lorenzn
I see my mistake. Here is an example of get_value usage vs accessing the pin value from the component:
    for p in pc.pins:
        # get the value of a pin usiing hal.get_value
        print('(get_value): {} = {}'.format(p.pinname, hal.get_value(p.pinname)))

        # get the value of a pin from the userspace component
        # in my case pc.h is the component
        pinname = p.pinname.replace('panelinterface.','') #strip off the component name 
        print('(from comp): {} = {}'.format(p.pinname, pc.h[pinname]))

result:
(get_value): panelinterface.pyvcp.rapid-machine-zero = False
(from comp): panelinterface.pyvcp.rapid-machine-zero = False
(get_value): panelinterface.pyvcp.rapid-g5x-zero = False
(from comp): panelinterface.pyvcp.rapid-g5x-zero = False
(get_value): panelinterface.pyvcp.touchoff-xy = False
(from comp): panelinterface.pyvcp.touchoff-xy = False
(get_value): panelinterface.pyvcp.touchoff-xyz = False
(from comp): panelinterface.pyvcp.touchoff-xyz = False

Please Log in or Create an account to join the conversation.

Time to create page: 0.279 seconds
Powered by Kunena Forum