Access Modbus pins directly with Python - doable?

andypugh wrote: it sounds like your HAL file needs to "loadusr" your Python program and wait for it to finish loading (loadusr -W) then the HAL file can carry on and connect up all the pins.

That is exactly what I did. below are the actual command lines.

halcmd loadusr -w /home/sfs/LinuxCNC/nc_files/inturncell.py

The folllowing line (in a script) executes from linux fine and nets the pins:
halcmd -f /home/sfs/LinuxCNC/configs/sim.axis/inturncel.hal

The problem is with the python program. If both lines are put together in the same script (filename is: "inturncelNetLoader.sh") there is no error message. The terminal says "starting Python" and the cursor moves to the lext line at the far left (no prompt) and blinks.

If the -w is changed to a -W, then there is an error message that stays "waiting for component 'inturncel' to become ready".
The line h.ready() is in the program as per the example in the docs.

Interestingly, before hanging (waiting to 'become ready') the Python does run and create the pins. If the script is run again, the Python errors out (duplicate component name) which bypasses the hang and then the .hal runs

ie, the Python script creates HAL pins, the HAL file connects the pins together.

You probably _can_ connect the pins from inside the Python script, but that depends on pin names never changing.

How would I go about connecting the pins using Python? That would solve at least some of the problem.

You can not (in HAL, or by any other means) connect pins to more than one net.
If you want to programmatically connect pins that are already in a net at that point then you need to connect to the _signal_ not the pin.

I understand, but I am not trying to do this.

This typically uses a "net" command with the prexisting signal name.

We would be able to guess what was going wrong a lot more readily if you pasted the error messages into your messages rather than saying "nope that doesn't work" and leaving us to guess what you did, what you expected to happen, and what actually did happen.

My apologies, Andy. Its not just LinuxCNC, but Linux itself that's all new to me. It takes me a while to figure out how to do anything and I don't want to waste people's time with questions that I can find on my own by doing some homework.

The reason I have not provided a lot of details to resolve the problem is that I first wanted to find out if this is even the right approach. i.e why waste everyone's time fixing a problem with a method that I should not even be using.

I can see where it may seem that I'm not really trying to fix the problem because I guess I am not being clear enough with my questions.

I probably have 90% of the porting task completed and PyVCP and a couple of BASH macros have taken care of all that. If I could use macros for this last part, I would, but the cel system has to be active while G-code is running, and so cannot rely on macros.

Everything was great up that point. I ran into a wall with Python because, unlike BASH, there is no access to the pins without using different libraries, jumping back and forth from Python to hal and creating 'surrogate pins and netting all sort of stuff together. My thinking was that surely I just don't know the right way to do this, and someone's going to say 'why are you doing it THAT way, dummy?"

If this is the only way to get stuff done in LinuxCNC, then so be it and I'll VERY much appreciate the help in getting the various pieces to load with LinuxCNC (that is the only problem, everything is actually working).

Having said that, wouldn't it be better to improve the process? I don't know how this community works or what it takes to get a project going, but if it's doable, I would think that combining these library fragments together would vastly improve LinuxCVC from a developer's perspective. Seems like the big advantage of open source is being able to make improvements.

For example, can the pin access that BASH has be added to the Python 'linuxcnc' library? What would be needed to make that happen? If that is doable, then count me in. I'll contribute in whatever way I can.

Meanwhile, if anyone has a suggestion on how to get h.ready() to work in the Python component library, please share. THANKS!

Simpson36 wrote: Meanwhile, if anyone has a suggestion on how to get h.ready() to work in the Python component library, please share. THANKS!

Well, firstly, what is "h" and does code execution reach the "ready" line?

You can get the symptoms you describe if the file name and the component name don't match. The HAL component name and the name of the file that creates the component need to be the same, I think (or, if they don't, you need to take special steps)

SO . . . this python propram has to run first . . THEN the last hal to do the netting. :woohoo:

Please publish you complete config folder with all needed files, otherwise I can not help. Have you taken a look at plasma.py from sim gmoccapy gmoccapy_plasma?

You can just include a complete python program in the _init_ part and the handlers will do the math.

Norbert

How would I go about connecting the pins using Python? That would solve at least some of the problem.

Did you read the links I posted in your other thread?

From src/hal/halmodule.cc

and many other functions which echo the C access functions, which are what halcmd and the other parts of HAL call.

Unless you let people see what you are doing, ie attach your files, this is a rather pointless exercise.
We are just trying to guess what you are doing.

Well, firstly, what is "h" and does code execution reach the "ready" line?

Sorry, my bad. "h" is the component name. The line is from the example file in the docs, which is what I started with.

You can get the symptoms you describe if the file name and the component name don't match. The HAL component name and the name of the file that creates the component need to be the same, I think (or, if they don't, you need to take special steps)

Andy, I know it gets to the h.ready() line because the remainder of the program is a TSR that remains running after the program exit.

In any case, I figured it out and everything is loading now!

The problem *seems* to be that the component WAS ready, but was not being recognized as such. I added a second "h.ready()" line to the python code and got an 'already ready' error . . right before the 'its not ready' error :blink:

I added a parameter to the command line and that fixed it up. I could them move that command line back to the postgui and stick the net commands further down in the same file so that the pins are created before the net occurs.

Thanks so much for all of your patience and help, Andy. I'm off now to do battle with Python file handling.

newbynobi wrote:

SO . . . this python propram has to run first . . THEN the last hal to do the netting. :woohoo:

Please publish you complete config folder with all needed files, otherwise I can not help. Have you taken a look at plasma.py from sim gmoccapy gmoccapy_plasma?

You can just include a complete python program in the _init_ part and the handlers will do the math.

Norbert

Thanks for more great info. I have added this stuff to my ever fattening note on LinuxCNC. I did not want to burden people with fixing a particular issue until I was at least fairly sure I was even attempting to do things the correct/best way. So my focus was more on learning if I was on the right track before trying to attack specific problems that were cropping up with what I was doing. Hope that made sense.

I was able to track down the loading problem and everything is working now and I have a lot of new stuff to look at from you and others. Hopefully there is a much better way to go about things than it currently covered in the available docs on LinuxCNC.org.

Thanks much for the help.