Advanced Search

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]