Advanced Search

Yes, you can steal 2 Step/Dir channels to support the 4 differential output signals
that XY2-100 needs. If you don't need the status data back from the galvanometer,
that's all that would be required. If you need the galvanometer status, you could
steal 1 of the 7I95T's RS-422 serial port RX pairs

I can make this firmware if needed
 

Link posted earlier in this thread:
forum.linuxcnc.org/9-installing-linuxcnc...i97t?start=10#342029

I’ve been using Probe Basic for a while, and I was wondering if it’s possible to assign keyboard shortcuts to turn the spindle on and off.

Quadrature A,B and Z should be the standard of the ecodrives position signal.
Could you direct me to some knowledge resources or forum threads related to the setup?

If I were to try doing this with just the galvo hooked up to the 7I95T (no other peripheral steppers), would I still need the daughtercards? Also, where would I be able to find the xy2mod firmware needed for the 7I95T? I saw you had one for the 7I96 board, but it seems this cannot act as a drop-in replacement

Yes, if the the drive can output quadrature (A,B,Z) that can connect directly to the 7I97T's encoder inputs
SSI is also possible but would require an additional daughtercard, so quadrature is easier.

I had the same things happining a while ago when I tested Michels s curve. In the end theese (exactly like your situations) were just "calculation errors" and he solved it by adding allowed dwviations. Pos_out got a allowed deviation of 1e-4 I think.

Like you see in my pictures he had imperfections too. Michels s curve code tested outside linuxcnc when I implemend s curve backlash compensation as a proof of concept.

The ECOdrive DKC11.3 can actually output both Incremental Encoder Output (A/B/Z Emulation) as well as SSI absolute encoder emulation. Will any of these fit the encoder input of mesa7i97?

Its not a 7I97T limitation, it's a system limitation.

Analog servo drives for CNC do not use the analog voltage for position control
but rather torque or velocity control. This means the control system (LinuxCNC in this case)
MUST get position feedback from the  axis or it cannot control the axis position.

Maybe mesa 7i97t will not work without position feedback but it’s far from uncommon that woodworking cncs run this way.

@grandixximo

During further testing, I noticed the following:

A sudden drop in jerkiness during acceleration build-up and deceleration, and a jerk greater than zero where there should be no jerkiness (red circles).
Cause?
tp.c
line 2836
"int need_decel = (margin <= TP_POS_EPSILON) || (dx - moveL <= dlen2);"

A brief exceedance of the maximum jerk value when acceleration ends (blue circles).
Cause?
sp_curve.c
lines 490 to 499
"if ((deltaV < 0 && targetV < v && v + deltaV < targetV) ||
      (0 < deltaV && v < targetV && targetV < v + deltaV)) {
    //nextA = (targetV - v) / t;
    nextA = 2.0 * (targetV - v) / t - a;
    if(nextA >= maxA){
      nextA = maxA;
      targetV = (a + nextA) * t / 2.0;
    }
    //printf("############################  FIXED nextA to be:  %.14f \n", nextA);
    v = targetV;"


I cannot say what is incorrect in the previous calculations.

gruß
Rüdiger

Thanks for the feedback! You’ve raised some classic points about LinuxCNC architecture. Let me clarify my design choices:
1. Why Arduino UNO & Serial Converter? You’re right, native USB (like 32u4) is faster, but the UNO is the most ubiquitous board on the planet. I chose it for the Evaluation to make it accessible to everyone. My dedicated hardware is optimized for the task. Regarding CDC, the driver handles the communication stream to ensure packet integrity without the overhead of complex generic protocols.
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.
3. USB Stability & Real-Time Thread I’m well aware that USB isn't for the Servo Thread. In fact, io_decoder doesn't try to be a motion controller. It’s an HMI driver. The reason it’s written as a component is to ensure that the communication window is synchronized and doesn't suffer from the unpredictable latencies of user-space scheduling.Regarding errors: the driver includes a specific state-machine to handle reconnections much faster than a standard generic serial bridge.
4. The Goal Most 'standard' serial-to-HAL projects are hacks. io_decoder is a finished product. It’s for the user who wants to plug in a board, load a component, and have a 100% reliable, low-latency control panel without writing a single line of Python or C.I invite you to actually test the Eval version.
You’ll see that the 'over-engineering' results in a responsiveness that user-space scripts simply can't match.

The plan is to let the ECOdrive make the encoder loop between drive and motor encoder, and not loop back to LinuxCNC due to the lack of encoder signals hand over from ECOdrive.
So, is there any directions or previous discussions about this topic here in the Forum?

Unfortunately, that will not work, analog commanded  drives require position feedback to LinuxCNC.
 

COFHAL wrote:

I try this bot with the command ls -l /dev/io_decoder show this error
ls: cannot access '/dev/io_decoder': No such file or directory

Go to the "Create a udev Rule" section described in bobwolfrst.github.io/io_decoder-linuxCNC/demo_mode.en
or insert the following in the line that calls the component in the .hal file describing your machine: loadrt io_decoder firmware=255 usb_port_name="[the port address obtained with lsusb]"

Aciera wrote:

A word of caution to anyone testing the new planner on real hardware:

I would strongly recommend to NOT activate the new planner in the ini file.
I dropped my homing velocities to 20% and my real hardware setup still runs into the hard stops on homing.

Users should leave ini.planner_type = 0, home the machine and use halshow to set ini.planner_type = 1.
 

I would echo this warning for the latest master changes

1. Jerk does not seem to be limited nor acceleration:

 

2. Commanded position may take off on random tangents"