Advanced Search

It seems very strange to me because it works perfectly fine for me on several machines where I've installed potentiometers to control those two speeds. I honestly don't know the resolution of the ADCs on the card you're using. In my case, the control is very linear between 0%, 100%, and 200%, which is the range in which I have those two overrider speeds programmed. Could you please repost your configuration so I can try to help you?

I've put together that userspace component to get the temperatures, and it works just fine.

andrax wrote:

As I see it, and hopefully I have understood correctly, the drives are put into homing mode (0x6060 = 6).
The servos perform the homing independently. 
The homing status can be read via 0x6041 bit 15.
The evaluation is performed by cia402homecomp.comp and reports Linuxcnc homing completed.
Is that correct?

 

That sounds correct.

I just put together a robot that homes using the drives. I didn't want a separate home switch, so I home each axis using the negative overtravel switch, and method 1 (Feed negative until negative overtravel goes logic high, then feed positive to the next index pulse).

All you must do is connect your negative overtravel switch to DI2. Home switch signals don't go through HAL in this application.

You might try the cia402 component from github.com/dbraun1981/hal-cia402. It has homing built in, and you don't need to touch the controlword register yourself.

It's the same for all EoE-enabled slaves, not just this one.

Ethercat master creates a handler, documentation page 104 docs.etherlab.org/ethercat/1.6/pdf/ethercat_doc.pdf

Creation of EoE Handlers
During bus scanning (see section 5.4), the master deter-
mines the supported mailbox protocols for each slave. This is done by examining the
“Supported Mailbox Protocols” mask field at word address 0x001C of the SII. If bit
1 is set, the slave supports the EoE protocol. In this case, an EoE handler is created
for that slave.

The queue in the EoE handler needs to be processed by the EoE state machine. And that is what doesn't happen.
The queue gets filled up and everything stops. Lcec should process the queue regularly when
in cyclous mode, to get packets in and out. That's the code that need to be in place and I think
that is what grok and Chatgpt both are proposing. And also kworm identified that.
Three out of three, majority win right?, so I think that's what's needs to be done.

There is no disabling of EoE support in the Ethercat master code. As in the quote above, if byte 0x38 (word 0x1c) is "1"
in the right place, EoE handlers are created, queue gets built up and everything stops.

What people do are 
1. Read out the eeprom and change that "1" in byte 0x38 to "0" and write back the new eeprom contents to the drive.
Ethercat master will then identify no support for EoE and go on with that track.
2. Disable EoE altogether in the Ethercat master with ./configure --disable-eoe during build.
The outcome is the same as above. No EoE processing, no queues that build up.

So what is broken and what isn't? Don't fix what isn't broken. It looks like the Ethercat master is broken, but that is not the case.
It is doing its part. Lcec on the other hand doesn't do what it should do to make EoE work. Lcec should regularly
process the EoE queue that are being built up. That's what needs to be added.

I have looked at what I have and I don't have any equipment with EoE to practice on. 
I can always buy one, it's an interesting enough task, but EoE servo drives seems to cost multum.
And I haven't really found one. Looks like I'll be standing on the sidelines cheering.


 

By "shutdown" I mean what the clearpath's enable signal does - the power supply is still running but the drive does not try to hold position any more, so the axis is able to move freely. Shutting down servo drives on following error allows humans to manually move the machine, potentially a life-saving ability, but at least it takes pressure off whatever it hit.

All my power supplies themselves are hooked into the estop chain, but that's for a different type of emergency

My point with modern step-servos is that, WHEN you shut it down / disable it, you no longer know what the machine's position is, because there's no position feedback to linuxcnc. The machine can move without linuxcnc knowing, hence the VOLATILE_HOME.

With "old style" servo configurations, linuxcnc had direct access to the encoders, so could track non-powered motion too.

Normally it will only need to switch once when he selects a different speed. Google: "cvt mill belt drive"

Never mind, a misunderstanding on my end.

I see you already answered my question. That motor is powered by two contactors fwd/rev. Good enough. It also shows a spindle speed sensor with two wires. Is that perhaps some proximity sensor?

I can see possibly configuring that with hal and/or a custom hal component by using mesa card outputs to trigger the two contactors (via relays, probably).

Use this ISO
www.linuxcnc.org/iso/linuxcnc-2.7.14-wheezy.iso
Boot the PC from it and run the tests in Live mode, meaning do not install, see if it hangs.

LinuxCNC has not lost any ability to shut off anything, there is no need to shut the power down for stepper and brushless servo drives on normal faults, that was for DC brushed servo systems and even for those normal enable/disable drive was and is used, leme give it a try:
-stepper motors and brushless servo motors do not go into runaway if an output mosfet shorts, they just lock in one place and burn slowly if the drive fails to blow a fuse or trigger a full shutdown
-brushed motors do run at full speed in one direction in such an event, hence the necessity to have another set of "extreme" limit switches on both side of any axis that cut all power to drives
-older brushless servo drives had two separate power inputs, one for the drive stage and one for logic, most new ones only have a single power input
In general, drive power should be cut only on e-stop event, in normal operation drive enable/disable should be used.
-
If you are OK with using e-stop, wire (in hal) the drive enable signal to e-stop out, that should do what you want, but i have no clue if your machine agrees with that.

Can you find any specs on the motor that drives the CVT adjuster? Maybe even a pic. of its nameplate. I suspect something should be available for it. Using a VFD for speed control a person can gain some low end torque using closed loop speed feedback and PID, but the CVT on my Wilton mill certainly has a lot more low speed torque than I was able get with just a vfd on another project.

Hi all,

I've just pushed MetalHeadCAM v0.3.0 to cam.metalheadcnc.com. I'd love to hear any and all feedback you have.

Just import a DXF file, then click the Add button in the operations panel. After that you should be able to simulate and export Gcode.

Since the last release:
- Much improved performance
- Added spot operations

I'm still not maintaining backwards compatibility, so if you've tried it before be sure to go to the hamburger menu in the top left corner > Settings > click Reset Application before use.

 

I will add that, with the invention of "servos with a step/dir interface", linuxcnc has lost the ability to shut off the servo power yet still keep track of where the machine *is* for when power is restored

My thinking is that once you have the machine dialed in you will never get this error.

Agreed; I wired my servos this way for when I get a hard crash.  the "fault" includes following errors in the clearpaths, and I really want the machine to stop and release the servos and spin down the spindle.  The hard crash might be a fleshy crash.  I realized the servos were going to lose position, added the VOLATILE_HOME, and discovered this bug...

Hi.
I have mini pc that i tried to install linuxcnc ( latest version) but horrible latency above 100000.
So i put Debian 12 and install kernal RTai 5.4.258 and linux cnc 2.9.3.
All is good, latency test is like max 24000 with default settings in the bios ( remove everything from the bios i got about 16000 after 2 hours).
The problem sometime the mini pc freeze when running tests (latency-test) so i have to restart.
I thought the bios settings was the culprit so i restore bios to default but the same.
Should i use i different distro or kernel?