Advanced Search

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.

 

Hi All,I’d like your input on my planned setup.
As I mentioned in my previous post, the latency on my new machine was so high that I had to switch from the parallel port to a Mesa card. Earlier this week, I received a Mesa 7i76EU board. It looks awesome—if a bit overwhelming at first glance!My plan:

• Motors:
  I’m using 3x Longs DM542A stepper drivers, which I plan to connect to Stepper 0/1/2 outputs on the Mesa board, using what I believe is called a “single-ended” wiring configuration. My plan is to connect +5V to the ENA+, DIR+, and STEP+ on each driver, and wire the ENA (5V), DIR-, and STEP- of each driver directly to the corresponding outputs on the Mesa card.
• Spindle:
  I have a Huanyang VFD 1.5KW for spindle control. For now, I’ll keep my Modbus-over-USB setup, which seems to work well enough. I’ve read that getting Modbus running directly on the Mesa board requires a bit more advanced configuration, so I’ll save that for later.
• Homing Sensors (Capacitive, 3x):
  My plan is to connect the +24V supply to the positive (brown) wire, and field ground to the negative (blue) wire of each sensor. I intend to connect the sensor output (black) wires to Input 1, 2, and 3 on the Mesa card.

Questions:

1. Current-limiting resistor for home sensors:
   For the capacitive homing sensors, do I need to add a resistor between the output pin of the sensor and the Mesa input to protect against overcurrent? In the past, I’ve blown a few sensors and started using resistors to protect them, but those were cheap sensors—the Mesa card isn’t!
2. 2-wire touch probe:
   For my two-wire touch-off probe, I plan to connect one side to +24V field power and the signal wire to Input 4. Here too, should I add a resistor to avoid potential shorts or overcurrent situations?

Bonus questions:

• Any recommendations for best practices when wiring sensors and stepper drivers to the Mesa 7i76EU?
• Are there things I should definitely avoid to protect my Mesa card or improve reliability?
• For those who have set up Modbus on the Mesa board, how steep is the learning curve compared to using Modbus over USB?

Thanks for your advice and experiences!