Advanced Search

i just updated the instructions and we did some reverting on a few things as we were able to reproduce the bug.. should be resolved if you follow the instructions here:

kcjengr.github.io/probe_basic/stable_develop_branch_change.html

Also, home 0 with home_offset 0 and min limit 5 will most probably not work, you have those for X and Z axis.

Hi Scott,
thank you for the hint. I'm loading the right version, just renamed it to keep overview.

I increased the values as my new attached INI configuration. I increased the [TRAJ]MAX_LINEAR_VELOCITY to a large value.
The P gain that worked best is 1000 (similar to a mesa configuration). I set the FF1 gain to 0.95, which gives reasonable results.

Now, the error comes not immediately, but for after 3-4 seconds, most often at the end of a jog move.
 

In this example, I'm jogging alternatively in positive and in negative directions. The following error has some very large sudden spikes.I made the spike filter parametric and experimented with different values, but they do not make any difference (n=2,4,8, m=500).

Here is the latest INI.
 

still having the error when powering off linuxcnc:
Exceeded POSITIVE soft limit on Joint_2 (0.000000)

After turn it on, the axes are homed and not be able to move a joint, neither homing again ewen if I unhomed the machine. So I have to shut it down, open lcnc again and now I can homing. But when it runs, never run into soft limit error, just very very close to limitswitch. 

Actually I tought the AXIS is soft limit, JOINT is hard limit, but not that case. I need something to have when softlimit is smaller area than hardlimit and machine not even close to limit switch. It is so basic, I'm sure lcnc has to have, and I'm suprised why it is so hard to find.

tjones wrote:

This is less of a LinuxCNC issue and more of a Linux issue.  I am selling my longtime linuxCNC machine and decided to change the computer name and password to the new buyers request.  (Building a new machine)

I first did a password change using: passwd
Then I did a hostname change using: hostnamectl 

I then verified the hostname had been changed and restarted the computer.  Once I restart I can see the hostname changed on the login in screen, but it won't accept any combo of new or old login information.  So I can't get into the system. Any ideas on what I can do to get in?  I did take a backup of my config files before I did any of this, so its not the end of the work to re-install everything and drop the configs back in. 
 

Boot with a live usb system, mount the hard drive and edit /etc/shadow and remove password from the user. Then umount, boot & login without password.
Depending on the linux distribution, you may already have a resque/repair boot option which should give a root shell to fix things.

Hello Eduard!
I am currently fiddling around with a similar system too, just using the EL7 drives instead of the EL8 - but the communication protocols are the same as far as I can see.
You write that you got the drives internal homing routine to work with Marco Reps' el8homecomp - are you sure of that? When I tried his component yesterday I could never see the opmode (pin "opmode-display") change from CSP (value 8) to HM (value 6). And the limits that I had set for homing velocity and homing acceleration were clearly disregarded - the drive would simply drive the axis to zero at 6000rpm and maximum achievable accelleration. Luckily I had nothing connected to the motors shaft...
So currently this problem remains unresolved for me, too.
Have a nice evening!
Paul

Just noticed this in your ini file:

[AXIS_X]
#Softlimit
MIN_LIMIT = 5.00
MAX_LIMIT = 1395.00
MAX_VELOCITY = 400.0
MAX_ACCELERATION = 4000.0

#Joint coordinate. Must be equal or bigger than working coordinates.
[JOINT_0]
TYPE = LINEAR
AXIS = X
#Hardlimit
MIN_LIMIT = 0.00
MAX_LIMIT = 1400.00

Not sure why you chose to use different limits for joint and axis but if your home position is at 0 then you would get a limit violation warning immediately after homing since then the axis limits are enforced and 0 would be outside those.
In my opinion there is no real advantage  in having different values for joint/axis limits in a trivial cartesian machine setup but you may have your reasons.
Also I would use the term 'hard limit' for the position of the limit switches while Joint and Axis limits are both 'soft limits'.

ok I just tested, lower case i makes it go down in increments, and uppercase I makes it go up in increments , and neither make it continuous

so the command....increments through the increments

I have tandem axes, but they are configured outside lcnc, in servo drives gantry function. This is why TRAJ using XYZ.

Thanks,
The first point if fair enough, so I have to disable jogging while it is not homed.
On the second point, Yes, I tried the exact setup, just HOME_ABSOLUTE_ENCODER = 1, since the modified homing will move all the axis, and when it is homed, I need homing without movement. But after the homing, soflt limix reaching kicks in. I dont really understand why, and how soflt limits working in this exact situation.
From manual is clear, the AXES_n are used after the machine homed, and JOINT_n before, in joint mode. But where are the soflimits then?

I meant to be on the stable version, but I think I did a apt upgrade after the split before I knew about the split. I then went back and edited my source file and did another apt upgrade. Is there a way to know which is installed?

LinuxCNC can and will jog before homing, at least it always did, or did something change that i am not aware of ?
ONLY tandem axis will not jog before homing, and even that can be bypassed by removing kinstype=BOTH in the TRAJ section.
Just in case this has changed, i am strongly against it.

Are you uisng the 2.9 version of carousel or the 2.10 version? I think I made some changes in the 2.10 version that might help there.

Late to the party here, but what happens if you connect halui.machine.is-on to halui.home-all, with standard absolute homing configured in the INI?

I _think_ that i and I switch between continuous and incremental, but that was just from glancing at the code.