Advanced Search

Yes that is what i thought. I find it so strange that i can have ludicrous speeds in the wizard. Not sure what kind of magic is happening there

I have stepgen's maxaccel and maxvel 25% bigger than the linuxcnc maxaccel
and maxvel settings. Also i have to figure out what i can set of DIRSETUP, DIRHOLD, STEPLEN, STEPSPACE realistically for my stepper-driver. A Longs DM542A driver is probably not the best driver in the world. 

This is the max i can do without getting errors:

#******************************************
[AXIS_X]
MAX_VELOCITY = 200.0
MAX_ACCELERATION = 200.0
MIN_LIMIT = -0.01
MAX_LIMIT = 750.0

[JOINT_0]
TYPE = LINEAR
HOME = 0.0
FERROR = 10.0
MIN_FERROR = 1.0
MAX_VELOCITY = 200.0
MAX_ACCELERATION = 200.0
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 250.00
STEPGEN_MAXACCEL = 250.00
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 0.0
# these are in nanoseconds
DIRSETUP   = 10000
DIRHOLD    = 10000
STEPLEN    = 5000
STEPSPACE  = 5000
STEP_SCALE = -400.0
MIN_LIMIT = -0.01
MAX_LIMIT = 750.0
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = -30.000000
HOME_LATCH_VEL = -2.500000
HOME_FINAL_VEL = 0.000000
HOME_USE_INDEX = NO
HOME_SEQUENCE = 2

hm2_7i76e: 0.stepgen.00.maxvel is too big for current step timings & position-scale, clipping max possible.
hm2_7i76e: 0.stepgen.01.maxvel is too big for current step timings & position-scale, clipping max possible.
hm2_7i76e: 0.stepgen.02.maxvel is too big for current step timings & position-scale, clipping max possible.

These warnings are because its not physically  possible to generate the required step rate because
the rate cannot be faster than 1/(steplength+stepspace). You can increase the maximum step rate
by reducing steplength and stepspace or using a lower micro-step ratio in the drives.

Following errors during installlation/setup are often because the stepgen maxaccel and maxvel
values do not leave enough headroom from LinuxCNCs joint/axis maxvel and maxaccel values, so check
that the stepgen maxaccel and maxvel values are at least 25% greater than LinuxCNCs joint/axis values

Hi all,

Thanks for all your input—everything is working fine again! There’s still some tweaking to do, but I’m getting there.

For the inputs, I made a small PCB breakout with terminal blocks, each protected by a pair of 0.5W resistors (2x 3K in parallel, so 1.5K total) to protect the Mesa card inputs. This limits the input current to a maximum of 0.016A (16mA) and 0.384W per pair.

I do have one last question. When testing my axis with the PNCconf wizard, I was able to achieve insane speeds—acceleration around 2500 and a max velocity of 15,000 (even higher values just made it wait or go slower). This seemed very promising. However, those values didn’t end up in the generated .ini file.

In reality, I had to limit my velocity to 200 to avoid errors in LinuxCNC, specifically:

hm2_7i76e: 0.stepgen.00.maxvel is too big for current step timings & position-scale, clipping max possible.
hm2_7i76e: 0.stepgen.01.maxvel is too big for current step timings & position-scale, clipping max possible.
hm2_7i76e: 0.stepgen.02.maxvel is too big for current step timings & position-scale, clipping max possible.

By lowering the timing values like this:

DIRSETUP = 6000
DIRHOLD = 6000
STEPLEN = 3000
STEPSPACE = 3000

(from the original 10,000 / 10,000 / 5,000 / 5,000), I could push the velocity up to 250, but then I started getting joint following errors.

So, I think I must be missing something fundamental, because the speeds I got in the wizard are nowhere near what I see in actual LinuxCNC. I don’t need crazy speeds for milling, but jogging 20cm takes a bit too long right now. Is there a way to make it faster, or can someone explain why the wizard speeds were so much higher than what’s actually possible in LinuxCNC?

Thanks!

So, change made, AC power component is gone and first small test job ran successfully. Hoping for the best . Thank you again!

Ah-ha! The 24V field power GND is not connected to earth ground, I was not sure that it should be. That probably explains it then.

Just weird that the machine ran fine for so long.

Thanks, I was getting frustrated with the constantly changing symptoms. I will connect those grounds tomorrow and test again.

Ack!! 40V is a real issue and indicates a grounding problem. This likely
what damaged the step/dir outputs (accidental contact to shield ground would do it)

I would verify that the drive frame grounds connect to earth ground and that the
7I76E ground (24V logic power ground) is also connected to earth ground.

Thanks a lot for your help!

Now that I hooked up an oscilloscope, the problem disappeared completely again - can't reproduce it anymore, at all.

That made generating pulses easier of course, I simply jogged the thing along. The levels of the step+/- pins on the motor side are around 4.8 volts, and -4.8 on a pulse.

I also noticed that the level between STEP- and the cable shield (GND) is around 40 volts AC (50 Hz). I can't say I understand why that would be so. Is that normal/intended?

Perhaps an output is marginal because of previous damage

I would verify full 5V swing on all step/dir pins.

Here is a simple script to toggle all stepgen step and direction pins slowly:

 


Download then

chmod +x stepgens.txt

and

./stepgens.txt to run

Note that this needs a relatively recent mesaflash

github.com/LinuxCNC/mesaflash

Alright, I found out that though the error looks identical, this time the MESA card is NOT the problem. The other good news is that the problem has become reproducible and the Joint Amplifier Failure now always happens immediately during the (attempted) homing procedure.

I can see during the homing attempt that the joint that has the amplifier error attempts to move - the other joint does not. In other words, I think that the servo with the alarm is the good one, and it goes into alarm because it fails to drag the other servo along.

It is still a puzzle though. By swapping port/cables/motors it seems that the common denominator is a port/cable:

 

The red path marks the one that has amplifier error in the different scenarios that I tested.

What puzzles me is that the common denominator in all failure scenarios are panel ports 2 and 3. However, I have measured the every wire several times with an ohm meter (as shown by the green lines in the image), and they are all fine. Since they are also not moving cables I cannot imagine it is a flapping connectivity issue.

So I am a little clueless as to what else I could do now. It seems every potential source of the problem was excluded.

Maybe EMI could have something to do with it, but... why would that suddenly become a reliably reproducible problem after running years with no issue?
Anyway, I also measured all the grounds on the shields of each cable, and they also seem fine/low impedance. (star configuration off of the panel, no loops)

Any ideas what else I can check?

Yes, if the touch probe uses a contact to ground you can use a pull-up
resistor as Andy suggested.

For 7I76XX inputs this needs to be fairly stiff, say 2.2K 1/2W

This is because the 7I76XX input resistance is 11K and needs an input > 14.4V
for a high level at 24V Vfield, and a 10K resistor will not do this.

One way to use a sinking input with a switch-to-ground sensor is to put a resitstor (I would probably try a 10k, choose something that can handle the current that flows when connected between 24V and gnd, anything over 2.5k @ 1/4 W size will be OK). Put one leg of the resistor in the 7i76 input, and connect the other to 24V, The connect the leg of the resistor that is in the input terminal to your switch-to-gnd.
With the switch closed the voltage at the input will be zero, with it open the resistor will pull-up the input and set it true in HAL.

You can invert the sense of the input in the HAL layer to get the right polarity,

Now i think of it, you're probably right. Maybe this is the case. What does imply for my setup / what should i look up so that i don't mess up the connection.

[EDIT]

I think i then have to connect it to GND and input right? (This is more safe, so i can test it first in this setup). I have this simple probe:

www.makerstore.com.au/wp-content/uploads...OOL-TP-V1-6a-NWM.png

Yes, the touch probe should be fine as long as it can be wired this way.

Note that many touch probes have a contact closure to ground, so be careful...
 

Thanks. Yes mine are of the PNP type. And same goes then for the input of the Touch sensor? This is not a PNP. This acts more like a mechanical switch.

That looks basically OK

If you have PNP type sensors, you do not need any additional interface components
that is the sensor output goes directly to the 7I76EU input.

7I76XX inputs are quite rugged, they need no additional protection.