Advanced Search

I am using a servo motor with an absolute encoder. I have successfully retrieved the encoder data via mb2hal and converted it into the motor shaft angle. Now, I want to use this data solely for homing. The process should be as follows: when a homing command is sent, a serial connection is established, the axis position is set equal to the encoder’s value, and then the serial connection is terminated.
Is this feasible, and how can I implement it?

jairobbo wrote:

scotta thank you so much!

the challenges I face that are left are:

1) homing -> I tried wiring to GND and 3.3v but joint.0.home (maybe it's called different) is never TRUE, I tried using halcmd show pin for that while linuxcnc was running and also live testing the home axis.

[code]27  bit   OUT         FALSE  remora.input.00 ==> X-home   
27  bit   OUT         FALSE  remora.input.01 ==> Y-home   
27  bit   OUT         FALSE  remora.input.02 ==> Z-home   
27  bit   OUT         FALSE  remora.input.03 ==> A-home

[code]I think it's weird that all my inputs are listed as OUT....

2) maybe related maybe unrelated: my A axis (joint3) is continuing to have follow joint problems. I thought maybe the motor or the driver went bad, but I swapped both. I tried several stepgen_maxaccel settings and fooled around with other settings as well.

Of course I appreciate the help so far and yes it's close to working, I was already very happy to see my XYZ axes moving!!!! :)

 

[/code][/code]

Hi, the inputs are "outputs" from the remora-spi component. The way I would approach this is the use halshow to confirm the the inputs are working.

1. ensure you have the inputs in your config.txt file
2. LinuxCNC has come out of eStop so comms are up. You will not see any input state changes unless you are out of eStop
3. Use halshow to monitor your inputs
4. Manually trigger the inputs and that they change state in halshow
5. setup you hal config

Yes, it consistently appears to be around 10ms.

However, I believe I’ve found a workaround. I have noticed, that the EL5101 outputs the encoder period which is an absolutely stable signal. So I wrote a custom component to calculate the frequency based on it, which in turn can be used in PlasmaC. In the attached Halscope screenshot, you can see the troublesome frequency signal with drops from the EL5101 in red, the encoder period in cyan, and the calculated frequency in green.

I did on both machines. No pktuart (only on the location where I copied your files). So the locate command works, but pretty sure that they are not installed anywhere by linuxcnc

github.com/dkogan/libdogleg

Dogleg runs.
You basicly provide the equatation in a callback function. Then it iterates until result is within treshold.

Startvalue a=1
Startvalue b= 1
Increment a= 1
Increment b = 1

10 = 3 + a x b

This will do
result = left hand - right hand
0 = 10 - 3 + 1 x 1
Finally
0 = 0

Woo servos arrived, among other things.

So, now the read adventure begins.

Thank you ill dive into this now, not sure how I hadn't found this before. Cheers.

So did you

sudo ubdatedb

locate pktuart

(no 0 no * just pktuart )

A "RIP" installation is a Run In Place installation from source.
Its built and runs from a directory in the users home directory.
Its handy because it makes it easy to have different versions of
LinuxCNC on a computer at the same time

EDIT:
 I think pktuart may not exist on a binary LinuxCNC version as its built into hostmot2

Whats strange is that neither mesa_modbus or pktuart code has been changed for at least 2 years

How frustrating. All your good advice, no result at my side. No pktuart.0

I took another PC installed Debian bookworm. Installed Linuxcnc via the script as mentioned in Installing Linuxcnc (no binary). Installed Linuxcnc dev; build-essential etc.
Exact the same error as where it al started.
and no pktuart...

What do you mean by RIP installation?

That looks like maybe an electrical/wiring issue with the encoder.

Is differential signaling used?