Hello I have been trying to get theses stepper drives configured along with a beckhoff EK1100 and have had no luck at all. I have followed the Ethercat step by step instructions and seem to have hit a wall. Any help would be appreciated. Attached is my pdos and ethercat slaves

 

 

grandixximo wrote:

The CiA 402 standard provides feedforward objects exactly for this: 0x60B1 (velocity offset) and 0x60B2 (torque offset). The master can send position plus velocity feedforward so the drive can anticipate acceleration. This is the standard's solution, it just needs to be mapped in lcec.
Also, good drives interpolate internally. The servo loop runs faster than the bus cycle (Maxon runs 0.4ms internal vs 1ms bus). The drive doesn't jump between positions, it interpolates. That's what 0x60C2 configures.
 

Can we explore this on another topic when I get to it? I wanted to rewrite dominic's cia402 component to make it easier to maintain and properly deal with homing so it comes into line with the custom homing that wasn't around when it was written. So it would be perfect for inclusion. Could the new TP have output pins that could be taken as input to calculate these?   Or how would we do it? Any conversion/massaging would be done in the revised component.

COFHAL wrote:

Thanks, I had an error in the rules file, that's why that error appeared.

Thanks COFHAL! You're right, I found the typo in the README and demo files. I missed a curly bracket in the part of the udev rule.I've just pushed the fix to the repository. This is exactly why community feedback is so important! Now everything should set up correctly with a simple copy-paste.

Could you post your CoreDC.hal file? I am trying to setup a gantry router with steppersonline ethercat drives. and have hit a wall with this setup

Dear tommylight, well, I didn't try that until now. I will have that in mind if I get back to my machine at better temperatures. Actually, I have something around 8°C thats not very comfortable for sitting and fiddeling in my garage.
I will come back asap.

Moin Andrax, die Idee ist super. Tatsächlich habe ich beim Servo den zugehörigen Bremswiderstand aber immer angeschlossen gehabt.
Dagegen spricht, dass ich die gleichen Abweichungen beim Tausch auf einen 3,5 Nm CL Stepper auch hatte.
Momentan hab ich noch Winterpause, meine Garage mit der Fräse ist nur 8° kalt, das ist zu ungemütlich um da große Diagnostik zu machen.

Was ich schon vorbereitet habe ist der (vorübergehende) Wechsel von LCNC zu einer Estlcam Controller Karte, bei der man nichts verfusen kann an Motoreinstellungen. ICh will wissen, ob ich weiter an der MEchanik suchen muss oder in der Konfig von LCNC. Aber auch dafür brauche ich etwas mehr Temperatur im Raum. Danke für Deinen Input,ich melde mich wieder!

Hi Andrax, that's a great idea. Actually, I always had the corresponding braking resistor connected to the servo.
The downside is that I had the same deviations when switching to a 3.5 Nm CL stepper.
I'm currently on winter break, and my garage with the milling machine is only 8°C, which is too uncomfortable to do any major diagnostics.

What I have already prepared is the (temporary) switch from LCNC to an Estlcam controller card, where you can't mess up the motor settings. I want to know whether I need to continue looking at the mechanics or at the LCNC configuration. But for that, I also need a slightly warmer room temperature. Thanks for your input, I'll be in touch!

unknown wrote:

So.....you are wanting testers for a closed source hardware project
What's in it for the testers ?

 

I don't want you to be my free testers. image missing /media/kunena/emoticons/smile.png
To do this project I came up with, I first experimented on a breadboard and then created the PCBs with the features I wanted. Unfortunately, I made some youthful mistakes in hardware development... trivial but significant...
I redid the PCB designs but haven't ordered them from the service yet. For now, I've already spent enough money on a "gamble." image missing /media/kunena/emoticons/ermm.png
If you want, there are some kits that need fixing, so it would arrive with various jumpers soldered on the fly.
In any case, the eval version is fully functional like the final one, but it doesn't have all the peripherals enabled. image missing /media/kunena/emoticons/cool.png

Hi all,I’m currently having trouble setting up a tool presetter in LinuxCNC. My setup consists of a Raspberry Pi 5 running LinuxCNC, three Leadshine servo motors, and a Beckhoff unit handling the toolsetter input.

The main issue is that when I press “Set Tool Offset PSO,” LinuxCNC does not apply the current machine coordinates. Also, when attempting to perform a tool height setting, nothing happens.
I’m also experiencing problems with manual tool changes. When using the Unload Tool or Load Tool commands, nothing occurs. The only way I can trigger a tool change is by using an M6 T"x" command, which brings up a popup asking for confirmation that the tool has been changed.I have not yet connected the solenoid valve that will actuate the drawbar. 

I’ve attached my HAL and INI files. Any suggestions or ideas would be appreciated. 

meister wrote:

2. Closed Firmware & 'Over-engineering' I respect the Open Source philosophy, but io_decoder is a professional project that includes dedicated hardware. The 'over-engineering' you see in the HAL driver is actually optimization. While a user-space component can work, a dedicated C component ensures deterministic polling and much lower jitter. If you want a 'professional feel' on the handwheel, those milliseconds matter.




ahh, ok, This is what professional code looks like when compiling.

Code:

halcompile --compile io_decoder.c Compiling realtime io_decoder.c MEGACUT [i][i][i][i][i][i]Linking io_decoder.so[/i][/i][/i][/i][/i][/i]

Code:

[i][i][i][i][i][i]“Bare-Metal” Firmware (No Bootloader) We have removed the Arduino bootloader for two critical reasons: Safety: No random pin state changes during startup (typical of bootloaders). Speed: The board is operational within a few milliseconds. what about updates ?[/i][/i][/i][/i][/i][/i]

 

Thank you for alerting me to all those warnings... apparently my system is set up so that I don't see them... I'll try to fix everything in the next few days... they're all warnings for things I left lying around due to closed roads and changes of direction in the program.

As for the choice to remove the bootloader, it's because I didn't want every communication, which occurs every 20ms, to waste time trying to figure out whether it was a new program or a regular message about the work it's doing.
If you want to modify the firmware, you need to use a programmer like tinyusb.
 

COFHAL wrote:

I use Arduino Connector, I really like your project, it's very professional. I don't know if you plan to create matrix-type keyboards to simulate keys or to be used as HAL pins like in Arduino Connector, which gives great flexibility.

 

There's no direct support for a matrix keyboard; I had considered it during the project development phase, but I was too far along and would have had to completely overhaul everything... perhaps in a future version...
However, all the inputs have the keyboard functionality that allows them to send keyboard characters with the physical input pins.
the only difference is that you have to wire all the buttons one wire for each button + the common which must come from the io_decoder board
It's all explained in the docs on GitHub.

Hi,

how can I help you exactly?

USB Stability & Real-Time Thread I’m well aware that USB isn't for the Servo Thread. 

What thread will it run in ? And you suggesting another thread to add to a config ? What period would this be run at ?
How would that affect a config that has a base thread (for software step gen) and a servo thread for other functions ?

To clarify the threading model:
does not run the USB communication inside the Servo Thread.The component spawns its own dedicated asynchronous thread to handle the USB protocol. The interaction with LinuxCNC’s HAL happens via non-blocking data exchange.

• Zero Blocking: The Servo Thread never waits for a USB response. It only reads/writes to a local buffer managed by the driver.
• Base Thread Integrity: Because the USB communication is decoupled, there is no risk of inducing jitter in the software step-generation (Base Thread).
• Responsiveness: This architecture allows us to maintain a high polling rate for the handwheel and I/O without affecting the machine's motion control stability.

This is exactly why it's more stable than a generic HID driver or a simple user-space script.

ciao
Roberto

Have you download to drive the parameter file i attached?Check the manual for the Asda-A2 drive has more detailed infos.

Hello,

I was planning to bore out a disc yesterday and thought I'd handwrite the code. The circular path would be 105 mm in diameter with the center at G54 X0, Y0, and starting at position X-52.5 Y0. Because of my lack of experience, I wrote is as a small program so I could get a preview. But the preview is not what I expected for the: The arc is started from position X-52.5, Y0.

As you can see in the screenshot, the preview shows a strange linear movement and a counter clockwise helix. But when I run the code, the machine makes a 105 mm circle in the XY plane, just as I wanted. The path from this run is visible as well (the red line). I'm guessing I'm doing something wrong, but what?