Advanced Search

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.
 

COFHAL wrote:

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

ENV{ID_MM_DEVICE_IGNORE}

unknown wrote:

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

 

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.

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]

[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]

 

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.

 

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 ?

io_decoder

• 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.

My apologize ...
sorry I can not show same speed test because I am currently weeks out of office but we can just multiply or devide values ... because it is linear dependecy during constant speed movemet ... 

I can just customize current images to show exact difference ...  compensation off ferror = 0.125mm at 15m/min ...  compensation on ferror = 0.00009028mm at 1m/min and multiply it by 15 we get 0,0013542mm which is significantly less then 0.125 ..

What I remember from testing by my short eyes it whas something near 0.001mm during that 15m/min testing was done with bentch top setup without any load presented... just AX5106 with AM8xxx motor 

but I can go home for testing this weekend to create exact speed difference testing if it is neccessary

No apologies needed [img]/media/kunena/emoticons/wink.png[/img]