Advanced Search

I’m trying to tune my servos but I’m getting around 0.02mm ferror instantly regardless the speed which then quickly drops to a couple microns steady. Can you recommend a way to fix it or is it ok as is?

Oha SEW?
Wenn für dich die 512inc Encoder kein Problem sind und die Analog Ansteuern möchtest.
Kann ich dir meine Anbieten.
MDX61b mit Profibus Karte (dfb21b) komplett mit Kabeln und Motoren.
Könnten auch auf ethercat Hochgerüstet werden
 

Hey Leute,

hat jemand die Idee mit dem ThinkCentre und EtherCAT weiterverfolgt?

Ich habe mein System auf dem Raspi5 konfiguriert bin aber leider Hardwaretechnisch mit 2 Bildschirmen dort an sein ende gestoßen und wollte auf ein ThinkCentre M900 upgraden. Dieses Verfügt über den I219-LM Netzwerk Chip der EtherCAT fähig ist. Als ich jedoch das System oben hatte konnte ich den CAT nicht wie gewöhnlich also so wie ich es beim Raspi getan habe Online bringen. Gibt es Besonderheiten auf die zu achten sind?

Hi, I'm working on an ATC tool changer for a CNC lathe. The videos are in Polish, but you can turn on the dubbing on YouTube [EN]. This may not be a professional tutorial (it may not be in line with the art of writing software). However, I think it's a useful resource because it includes an example written from A to Z. An added bonus is the Stream Deck for tool changing, using talla83 as an example.

The entire series about the tool changer + dubbing [EN]

Part 1 (Mechanics):
Part 2 (Servo and Torque):
Part 3 (Stream Deck)
Part 3 FULL

Maybe my materials will be helpful to someone

Config www.dropbox.com/scl/fo/n8dhp3xcx0qecqnoo...t7y&st=s8xvag3p&dl=0

PCW wrote:

is spindle.0.at-speed  true?Also does the index work?Test by (either in halshow or with halcmd -kf)sets spindle-index-enable truewatch  spindle-index-enable in halshowit should go high with the sets command and then low when you rotatethe spindle past the index position.

 

Some progress, but still not quite there.

The error I was receiving ("Chosen spindle(0) not turning in G76")  when I tried opening my gcode file was occurring because I did not have a M03 (start spindle command), because I start my spindle manually. So now the program opens and runs, just not correctly.

I scoped with an actual scope the index signal as well as the other spindle quadrature signals and they are as expected (not sure on the polarity of the index pulse. It is low for most of a spindle rotation, with a brief blip high once per revolution.The program now runs, however it cuts and retracts in the wrong direction (X wise). It seems that the G76 command thinks more negative X is towards the center of the spindle center line and more positive is out and away from the spindle centreline.Even the graphic, shows -X towards the centerline ie. a deeper cut is more negative X), please see attached. Interestingly the animated graphic, shows the correct motion with a slow cut to the left then retracting out for the non-cutting return  Z movement in the real world -X direction (labeled as positive X in the graphic), and then cutting progressively deeper (real world X, graphic more negative X) on each pass..ngc file is as follows:

(huge 1.25 x 7 coarse external thread)
S100 M3
G90
G0 x-0.002 Z0.1G76 P0.1429 Z-1.0 I-0.0876 J0.005 K 0.0876G0 X -0.05 Z 0.1
M5
M30

---

Answers to your questions:

1) is spindle.0.at-speed  true?  Yes because it's hard set in HAL  (sets spindle-at-speed true)

2) Also does the index work? Yes, it is low for most of the revolution, and blips high momentarily as the magnet passes,See scope capture.
Test by (either in halshow or with halcmd -kf)

3) set spindle-index-enable true watch  spindle-index-enable in halshow it should go high with the sets command and then low when you rotate the spindle past the index position.  It does exactly that.

I think at this point I just need to resolve the backwards X movement.

I also noticed that when I use the cursor keys to jog the X-axis, they are backwards for the X-axis. Up arrow moved the cross slide down and visa versa.

If I flip the polarity of the X scale value in the ini file, the cursor keys are correct, but the actual cross slide move backwards.
Same thing if I flip the direction of rotation in the servo software, I can get the cursor keys correct, but the actual direction is backwards.

As expected flipping both gets me back to where I started.

I'm not sure if the backwards cursor keys have any correlation with the G76 working backwards for X but seems like there might be a link?

If I change the sign of the "I" term from negative to positive (which should change from external to internal thread mode), the program correctly cuts the thread, The graphic representation in axis shows an internal thread being cut, but the actual action is external resulting in a perfect thread.
 

Sorry für die späte Rückmeldung, ich bin leider nicht früher dazu gekommen, mir alles in Ruhe anzuschauen.

@ andrax :
Ich kann aktuell noch keine Bilder einstellen, da ich mich noch in der Auswahlphase befinde und den Motor sowie das Getriebe noch nicht habe.

Zu diesem Motor benötige ich außerdem noch weitere Motoren im Bereich 1,2 Nm, 4 Nm und 5 Nm. Deshalb überlege ich gerade, ob ich alles von SEW nehme, damit die Treiberwelt einheitlich bleibt. Allerdings ist SEW preislich schon noch einmal eine andere Hausnummer als Moons:
www.moonsindustries.com/c/servo-drives-a0104

Aktuell bin ich da noch hin- und hergerissen.

sivaraj wrote:

Based on the manual (download.sew-eurodrive.com/download/pdf/29194652.pdf), your motor appears to be an 8-pole motor.

Auf Seite 105 (3.7 CM3C100 / 3.7.1 Technische Daten) steht tatsächlich:
Polzahl = 8

Was bedeutet das für mich bzw. für die Auswahl des Treibers konkret?
Heißt das, der Treiber muss speziell zu einem 8-poligen Motor passen?
Oder hat das mit der Anzahl der Motorleitungen nichts direkt zu tun?

sivaraj wrote:

For an 8-pole motor to operate at 4500 RPM, it requires a frequency supply of approximately 300 Hz, which is supported by most modern drives.

Ok, das heißt also:
Der Treiber müsste ausgangsseitig ungefähr 300 Hz sauber liefern können, wenn ich die 4500 rpm überhaupt ausfahren will?

sivaraj wrote:

Please note that the 400 V value refers to the inverter-rated voltage, not the motor's rated voltage. You can find additional details in the following document (see page 44):
download.sew-eurodrive.com/download/pdf/29133866.pdf

Was bedeutet „inverter-rated voltage“ auf Deutsch genau?
Ist damit die Umrichter-Nennspannung gemeint?
Und ist der Umrichter in diesem Fall einfach der eigentliche Servodrive / Treiber, oder ist das noch einmal etwas Separates?

sivaraj wrote:

I found a similar motor with name plate details in this ebay listing:
www.ebay.de/itm/168190225800

Ja, der sieht vom Aufbau her tatsächlich sehr ähnlich aus wie die STEP-Datei, die ich bekommen habe.

sivaraj wrote:

Estimate the torque required

Aktuell schätze ich, dass ich abtriebsseitig im Normalbetrieb etwa 4.500 bis 5.500 Nm benötigen werde.
Alles darüber ist im Moment eher Sicherheitsreserve – und ein Stück weit auch Respekt vor der realen Anwendung.

Viele Grüße
Mücke

Wenn ich mich Recht entsinne, funktieren die BK klemmen nicht.
Die sind das ältere Modell und verwenden ein anderes Protokoll 

Just wanted to report back that since installing grandixximo's fork three weeks ago, I’ve had zero issues. So at least for me and my hardware, that’s the real solution here.

I re-examined the flow of the commands through the components I'm using for temporarily slaving the W to the Z axis.  Then I reshuffled the addf order a little more appropriately and now it seems to be working.  

Thanks.

Here is the hal file that is working better.

 

Hi everyone,I am trying to get a Beckhoff BK1120 (EtherCAT to K-bus coupler) working with LinuxCNC using EtherLab (ethercat-master) and the linuxcnc-ethercat (lcec) driver.I am running into some limitations and hope someone has experience with this.Setup:

• LinuxCNC on Debian Bookworm
• EtherLab master (from openSUSE repo)
• linuxcnc-ethercat (lcec)
• NIC: Intel I210 (working fine)
• Hardware:
  • BK1120
  • KL1104 (digital inputs)
  • KL9010 end terminal

What works:

• EtherCAT master is running and stable (Active: yes, Phase: Operation)
• BK1120 is detected correctly
• Communication is stable (no frame loss, link up)

The problem:
The BK1120 does not expose standard CoE PDOs like typical EtherCAT slaves (for example EL terminals).
Instead it provides a fixed process image for the attached KL modules.Because of this:

• Standard PDO mapping via lcec XML does not work (0x6000 etc.)
• Terminal-based configs (EK1100 + ELxxxx) do not apply to KL modules
• lcec does not seem to support raw domain access for mapping the BK1120 process image directly to HAL pins

What I have tried:

• Generic slave configs with and without PDO entries
• Attempted raw mappings (not accepted by lcec parser)
• Minimal configs to bring the master up (works, but no usable I/O)
• Checking data with ethercat CLI (limited without proper domain mapping)

Current conclusion:

• BK1120 with KL modules does not fit well with lcec, which expects PDO-based slaves
• The data exists, but is not easily exposed to HAL

Questions:

• Has anyone used BK1120 with KL modules in LinuxCNC?
• Has anyone managed to access the process image and map it to HAL pins?
• Has anyone written a custom lcec extension or used another approach?

Alternatives I am considering:

• Writing a custom HAL component to read from EtherCAT master directly
• Userspace polling (not suitable for realtime CNC)

Before I give up on the BK1120, I would like to know if there is a workable solution.Any input, configs or experience would be appreciated.Thanks

I didn't make a fix for the spinlock var because restructuring the code to try and implement PIO eliminated it. I'm still working on the PIO code, but "semaphore" needs a "volatile" keyword in front of it:

github.com/scottalford75/Remora-RP2040-W...read/pruThread.h#L31

I don't remember if "execute" also needs it. "semaphore" is intentionally used to synchronize the two CPU cores, so you need to tell the compiler the value can change any time you look at it.

I'm making myself a liar. Just went and commented out everything for the slaving and reconnected the old command and feedback signals and I tried power cycling and homing twice and it didn't error.

So, maybe it is because of that. I really did think that I was having these errors before I started adding the stuff for the slaving. Unfortunately I'm not sure that it is going to be possible to prevent what I need to do to slave the axis temporarily without causing either the position command or feedback data from becoming one or more thread cycles old.

Do you think simply rearranging the thread order could work? Any suggestions for a better order to addf the components?

Hi PWC 

Thank you for the info, greatly appreciated

I thought I would start with double checking the wiring.

I removed some of the wiring, and rewired it, rather than getting confused messing about with it. 

It seems pretty straight forward, up until I get to the gantry wiring. 

I have a question about the wiring of these two Y axis gantry motors

I attach a makeshift collage of my best effort to display the motor info, and the motors together in one place, I am sorry that it's a bit messy.  

Left side of image is the Y2 gantry motor. Left edge of the photo is the front of the machine.

Right side of photo is the Y1 gantry motor (green tape). Right edge of photo is the front of the machine. 

I orientated the motor specification, to the same orientation as each motor. 

From motor connector pin 1 to pin 11 . No matter the motor orientation , the order of these molded motor connectors is black, green, red, white

However , given that the motors are physically facing each other, if I were able to stand behind the machine , and be able to see both the motor connectors at the same time,
In my head , I would expect to see the wiring of the connector following the same (color?) order top to bottom (which they are not)

Should I be thinking of these as “top pair” of each motor connector , and “bottom pair” of each motor connector (Irrespective of the data sheet , or color of wire) so that I am always referring to the same physical winding on each side?

This is so confusing to me. 


************************

The mesa 7i96u axis TB2 0 through 3 connectors are all the same , all straight, each connector has the same color order

Input Signal on DM566 drivers follows mesa outputs. 

For each mesa TB2 connector 0 through 3
Using 0 as an example

Mesa          DM566     color 
Pin 6    not used
Pin 5  dir (+)  -> dir (+) red
Pin4  dir (-) ->  dir (-) green
Pin 3 step (+) -> pul (+) black
Pin 2 step (-) -> pul(-) white
Pin 1  not used


Please ignore DM566 output labeled (High Voltage) in Y2 photo because until I understand y1 and y2 wiring its unlikely to be correct , (it currently homes correctly, but still y2 jogs in the opposite direction). 

************************



 

That’s exactly what I was getting at.
After their extensive testing, they can confirm that the driver works flawlessly.
Anyone who’s still having problems should take a closer look at their hardware. That’s why I brought this up and mentioned Beckhoff. All compatible chips are listed there, but unfortunately, few people know that.
Maybe I just didn’t express myself clearly.
Here’s my thinking.
Many people already have EtherCAT up and running successfully.
We could collect the hardware information and put it in a wiki. 
System requirements:
>PC, network card, cable, EMC filter
>Configuration examples
>Troubleshooting tips
>Explanation of individual functions
That would help many new users get up to speed on the madness of EtherCAT
before they flood the forum with the same questions over and over.

I can’t do that myself. When I start a thread like that, it disappears into oblivion really fast.
Only the admins can do that

Regards, Andrax