Hurco BMC 30 AP

Hi,

we worked with the hal scope today.
 

OK that looks like exponential runaway which is an indication that the
feedback loop is backwards (positive rather than the desired negative feedback)

If the encoder feedback is in the correct direction, the fix is to change the sign
of the PWM scale value:

[JOINT_0]
TYPE = LINEAR
HOME = 0.0
FERROR = 10
MIN_FERROR = 5.0
MAX_VELOCITY = 200.0
MAX_ACCELERATION = 1250.0
P = 1
I = 0
D = 0
FF0 = 0
FF1 = 0
FF2 = 0

BIAS = -0.0105
############-0.0105 vorher Bias
DEADBAND = 0
MAX_OUTPUT = 10
ENCODER_SCALE = -4000
OUTPUT_SCALE = -10
OUTPUT_MIN_LIMIT = -10.0
OUTPUT_MAX_LIMIT = 10.0

I changed the prefix today, and now the machine no longer moves automatically.

I'd like to know why this is happening. The Debian version and the Linux CNC version have changed. I haven't made any changes to the INI file itself.

I don't think LinuxCNC has changed anything basic like this
it's more likely a hardware, wiring, hal, or ini file change.

5_Zylinder wrote:

I'd like to know why this is happening.

For what it's worth, I once worked on a machine that did a similar thing. I my case it was encoder counts. The entire system was Seimens brand electronics from the 1980's. One day they switched it on and one axis experienced runaway until following error stopped it (nearly instantaneously). We had no documentation for that machine and nothing was labeled. I ended up swapping A and B from the axis feedback glass scale encoder then everything worked again.

We assume a logic fault somewhere in the computer's many circuit boards caused the mysterious fault.

Thanks for your feedback.

The last time the machine was running (the video is a few pages back), I only updated the firmware of the 7I97, from Debian10 to Debian13, and the LinuxCNC software. There were no changes to the wiring, hardware, or the HAL/INI files.

In any case, the handwheel on the machine works, for example.

However, there's still a problem with the homing function, and that also worked the last time the machine was running. The Z-axis moves correctly. The limit switch moves to the cam and then releases itself, reporting a successful homing. Unfortunately, this isn't the case with the X and Y axes. As soon as the limit switch moves to the cam, the axis stops, and after a few seconds, an error message appears. The X, Y, and Z home contacts are displayed correctly.

I then tried manually homing the X and Y axes. I manually pressed the switch, and the machine recognized the command and performed the referencing by moving freely and reporting a successful referencing.

The settings for all three axes are the same; you can see them in my latest .ini file.

Does anyone have any other suggestions?

As soon as the limit switch moves to the cam, the axis stops, and after a few seconds, an error message appears. The X, Y, and Z home contacts are displayed correctly.

What error message?

Do the drives have any direct connection to the limit/home switches?
(some systems disable the drives directly when limits are reached)

Can you do a halscope plot of the say X position and X home switch state while homing?


 

Hello everyone,

Today I recorded data from the Z-axis, which is functioning correctly, and then I tested the X-axis.

The X-axis limit switch moves onto the cam and then simply stops instead of moving freely.
After a few seconds, the following error message appears: joint 0 following error

Unfortunately neither plot shows any motion so it hard to tell what's going on.

Can you post your current hal/ini files?