Access Modbus pins directly with Python - doable?
04 Jan 2016 16:10 #67842
by Simpson36
I appreciate that you are willing to spend your time trying to help and I understand it is frustrating when a person is unable to precisely describe a problem using the proper terminology. Usually the shoe is on the other foot, but for now, I am the newbee. We all have our turn in the barrel.
Certainly I saw your posting of source code, but it never occurred to me that this was considered documentation. I don't think it would be a stretch to say Linux/LinuxCNC is pretty geeky stuff, but source code as a manual is a bit over the top.
Not a problem, I'll get used to it. Thanks for the education and I will view source code as a 'manual' of sorts fro here on.
Sorry to frustrate you and thanks for taking time to be frustrated over my problem.
Replied by Simpson36 on topic Access Modbus pins directly with Python - doable?
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
PyObject *connect(PyObject *self, PyObject *args) { char *signame,*pinname; if(!PyArg_ParseTuple(args, "ss", &pinname,&signame)) return NULL; if(!SHMPTR(0)) { PyErr_Format(PyExc_RuntimeError, "Cannot call before creating component"); return NULL; } //printf("INFO HALMODULE -- link sig %s to pin %s\n",signame,pinname); return PyBool_FromLong(hal_link(pinname, signame) != 0); }
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.
I appreciate that you are willing to spend your time trying to help and I understand it is frustrating when a person is unable to precisely describe a problem using the proper terminology. Usually the shoe is on the other foot, but for now, I am the newbee. We all have our turn in the barrel.
Certainly I saw your posting of source code, but it never occurred to me that this was considered documentation. I don't think it would be a stretch to say Linux/LinuxCNC is pretty geeky stuff, but source code as a manual is a bit over the top.
Not a problem, I'll get used to it. Thanks for the education and I will view source code as a 'manual' of sorts fro here on.
Sorry to frustrate you and thanks for taking time to be frustrated over my problem.
Please Log in or Create an account to join the conversation.
04 Jan 2016 20:44 - 04 Jan 2016 20:58 #67875
by Simpson36
Replied by Simpson36 on topic Access Modbus pins directly with Python - doable?
For a first attempt at posting code, here is the inturn_postgui.hal
The solution to LinuxCNC hanging on startup is on line 8 and also below in red. Specifying the component name seems to have made it recognizable to the script, otherwise it was continuously waiting for it to go 'ready' even though it already was.
The offsets and scales are workarounds to deal with s32 and float data types on 16 bit Modbus registers. Joystick values are +50 to -50 so I had to add 50 at the device, xfer over Modbus and subtract (offset) 50 at LinuxCNC to get the negative number back.
Scale is used as a 'down and dirty' way to get an actual float across Modbus. If more than 3 decimal places of accuracy are required, you have to use a more complicated method and use (at least) a pair of 16 bit Modbus registers, but that's a whole other topic..
Hopefully useful to someone.
loadusr -Wninturncel -i /home/sfs/linuxcnc/nc_files/inturncel.py
The solution to LinuxCNC hanging on startup is on line 8 and also below in red. Specifying the component name seems to have made it recognizable to the script, otherwise it was continuously waiting for it to go 'ready' even though it already was.
The offsets and scales are workarounds to deal with s32 and float data types on 16 bit Modbus registers. Joystick values are +50 to -50 so I had to add 50 at the device, xfer over Modbus and subtract (offset) 50 at LinuxCNC to get the negative number back.
Scale is used as a 'down and dirty' way to get an actual float across Modbus. If more than 3 decimal places of accuracy are required, you have to use a more complicated method and use (at least) a pair of 16 bit Modbus registers, but that's a whole other topic..
Hopefully useful to someone.
loadusr -Wninturncel -i /home/sfs/linuxcnc/nc_files/inturncel.py
# Include your custom_postgui HAL commands here
# This file will not be overwritten when you run PNCconf again
loadrt scale count=2
loadrt offset count=2
#loadrt conv_float_u32 count=2
loadusr -Wninturncel -i /home/sfs/linuxcnc/nc_files/inturncel.py
setp offset.0.offset -50
setp offset.1.offset -50
setp scale.0.gain 1000
setp scale.1.gain 1000
addf offset.0.update-output servo-thread
addf offset.1.update-output servo-thread
#addf conv_float_u32.0 servo-thread
#addf conv_float_u32.1 servo-thread
addf scale.0 servo-thread
addf scale.1 servo-thread
#net Xzero pyvcp.X-home => halui.mdi-command-00
net TURN pyvcp.TURN-Mode => halui.mdi-command-01
net INDEX pyvcp.INDEX-Mode => halui.mdi-command-02
net RPM_CMD pyvcp.InTurn_RPMcmd-f => mb2hal.WriteMultiHolding.01
net SFM_CMD pyvcp.InTurn_SFMcmd-f => mb2hal.WriteMultiHolding.00
net MILL_RPM pyvcp.Mill_RPM-f => mb2hal.WriteMultiHolding.14
#note use of radiobutton in pyvcp required the pin name to include the SECOND or LAST choice
net AUTOSPEED pyvcp.InTurn_AutoSpeed => halui.mdi-command-11
net SETSPEED pyvcp.InTurn_SetSpeed => halui.mdi-command-12
net RPM_SPINDLE mb2hal.ReadHolding.01.int => pyvcp.InTurn_RPM
net InTurnSetEncoderToPin mb2hal.ReadHolding.11.float => pyvcp.scale.0.param_pin
net InTurnAutoEncoderToPin mb2hal.ReadHolding.12.float => pyvcp.scale.1.param_pin
net MillEncoderToPin mb2hal.ReadHolding.13.float => pyvcp.scale.2.param_pin
#halui.mdi-command-03 (and any simlar) is in "axis.ini" and contains "MDI_COMMAND = M143 P01 Q1"
#this method runs the macro M143 with passed params
net SPINDLE_ON pyvcp.Spindle-ON => halui.mdi-command-03
net SPINDLE_OFF pyvcp.Spindle-OFF => halui.mdi-command-04
net SPINDLE_DIR pyvcp.Spindle-DIR.Reverse => mb2hal.WriteMultiCoil.14
net Spin_ON_remote mb2hal.ReadCoils.09 => halui.mdi-command-09
net Spin_OFF_remote mb2hal.ReadCoils.04 => halui.mdi-command-10
net LOCK_ON pyvcp.Lock-ON => halui.mdi-command-05
net LOCK_OFF pyvcp.Lock-OFF => halui.mdi-command-06
net ENABLE_ON pyvcp.Enable-ON => halui.mdi-command-07
net ENABLE_OFF pyvcp.Enable-OFF => halui.mdi-command-08
net JogX_offset mb2hal.ReadHolding.08.float => offset.0.in
net JogY_offset mb2hal.ReadHolding.09.float => offset.1.in
net JoyX_fixed offset.0.out => halui.jog.0.analog
net JoyY_fixed offset.1.out => halui.jog.1.analog
setp halui.jog-speed 1
net AxisYtoConvert axis.1.joint-pos-cmd => scale.0.in
net AxisZtoConvert axis.2.joint-pos-cmd => scale.1.in
net AxisYscaleToModbus scale.0.out => mb2hal.WriteMultiHolding.10
net AxisZscaleToModbus scale.1.out => mb2hal.WriteMultiHolding.11
net itemTar inturncel.itemTarget <= mb2hal.ReadHolding.14.float
net itemRe mb2hal.WriteMultiHolding.15 <= inturncel.itemReturn
net command inturncel.cmdReady <= mb2hal.ReadCoils.10
net instruc inturncel.instrCode <= mb2hal.ReadHolding.15.float
net affirm mb2hal.ReadCoils.11 => inturncel.actionAffirm
net acknow mb2hal.WriteMultiCoil.15 <= inturncel.cmdAck
Please Log in or Create an account to join the conversation.
04 Jan 2016 21:19 - 04 Jan 2016 21:22 #67877
by Simpson36
Chris,
I have to wonder whether there is some 'frog in the water' syndrome in the 'old guard'. Now, I'm old myself (62), BUT I have a fresh perspective on LinuxCNC with no pre-conceived notions (other than it is geeky). Maybe the contorted way of doing things has just been around so long it seems 'normal' to people who have been doing it for years.
To me, it just seems like . . REALLY? . . anyway, no disrespect intended to anyone, it just was unexpected. I'm old enough to remember programming when you spent a LOT of time compacting code and data because memory was small and uber expensive. I don't see any justification with modern computers to have a bunch of separate modules. How big would the whole thing be if it was combined, or major parts of it combined.
I just got a bunch of new info to dig thru, including 'source code manuals' and as implied elsewhere, it may be that a lot of this stuff has been accomplished, but just not documented yet. In any case, these are just my 'first impressions', FWIW, which together with 5 bucks will get you coffee at Starbucks.
One question, please; who or what is machinekit?
Replied by Simpson36 on topic Access Modbus pins directly with Python - doable?
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!
So the linuxcnc module in python is for access to linuxcnc (the motion controller)
The hal module in python is for building components in python it allows access to halcmd (which is what you are using in BASH)
We do not want to intermix them.
The hal module is a subset of halcmd (plus a few other things added in)
It was discussed/attempted a long time ago to add the rest of halcmd to the python module.
I forget the exact reason why it failed, but it might be because all of halcmd had to be basically duplicated - a lot of work.
having a python binding to halcmd all on its own would be interesting - it should allow writing HAL scripts in python allowing
all of pythons programing syntactics. I believe machinekit has done this. We have something similar written in TCL
Chris M
Chris,
I have to wonder whether there is some 'frog in the water' syndrome in the 'old guard'. Now, I'm old myself (62), BUT I have a fresh perspective on LinuxCNC with no pre-conceived notions (other than it is geeky). Maybe the contorted way of doing things has just been around so long it seems 'normal' to people who have been doing it for years.
To me, it just seems like . . REALLY? . . anyway, no disrespect intended to anyone, it just was unexpected. I'm old enough to remember programming when you spent a LOT of time compacting code and data because memory was small and uber expensive. I don't see any justification with modern computers to have a bunch of separate modules. How big would the whole thing be if it was combined, or major parts of it combined.
I just got a bunch of new info to dig thru, including 'source code manuals' and as implied elsewhere, it may be that a lot of this stuff has been accomplished, but just not documented yet. In any case, these are just my 'first impressions', FWIW, which together with 5 bucks will get you coffee at Starbucks.
One question, please; who or what is machinekit?
Please Log in or Create an account to join the conversation.
Time to create page: 0.068 seconds