Advanced Search

Search Results (Searched for: )

  • ruediger123
  • ruediger123
Today 20:09
Replied by ruediger123 on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

@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
  • bobwolf
  • bobwolf
Today 20:06 - Today 20:07

Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Category: Driver Boards

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.
  • PCW
  • PCW's Avatar
Today 20:05
Replied by PCW on topic Linuxcnc 2.9.4 and Mesa 7i97T

Linuxcnc 2.9.4 and Mesa 7i97T

Category: Installing LinuxCNC

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.
 
  • bobwolf
  • bobwolf
Today 20:03

Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Category: Driver Boards

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]"
  • PCW
  • PCW's Avatar
Today 19:38
Replied by PCW on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

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"

 
 
  • HansU
  • HansU's Avatar
Today 19:37
Replied by HansU on topic Gladevcp pin does not exsist

Gladevcp pin does not exsist

Category: GladeVCP

Please post your HAL file to be able to help you.
  • endian
  • endian's Avatar
Today 18:36 - Today 18:44
Replied by endian on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

@endian I discussed this with YangYang who attends the EtherCAT consortium meetings. AitalMAC is part of the consortium and we design I/O for EtherCAT, so we're not guessing here.
The standard already solves this problem. You don't need pos(t+1).
The 1 cycle delay is real, but it's identical for all axes. With Distributed Clocks everything executes on the same SYNC edge, synchronized to ~100ns. Every axis is "late" by the same amount, so the path shape is correct. Calculate it last week, execute it this week, the part is the same.
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.
If you're seeing ferror correlate with velocity in halscope, that's likely a display artifact. The ferror compares "commanded from 1 cycle ago" with "actual now", so it shows an offset proportional to velocity. It's not a real machining error.
What does your actual part surface look like? Any real deviation you can measure?
 

I think not every hardware has 0x60B1:01 in the accessible PDOs and not everyone can use unsynchronized SDO to change during OP ... therefore I am high-lighing it before job is done ... I have working with 16 different brands of servodrivers based on ethercat and just one it has(nidec control techniques) ... What I know from TC3 this is solved by NC stuff computing for the each single axis ... 

I do not want to talk about ethercat here .. we have separate space, but in reality it is lagging 2cycles because at hardare layer it writes command first and then it reads the slave status... then next cycle it write command by last status and then cycle it reach real status datas ... (Martin Rostan (Chairman ETG group) - when I was with him at last time at conference in Bratislava)

SDO 0x60C2 is configuring the timing of internal stuff of interpolationn of synchronized movement by subindex 01 and 02 .. most drivers it has to have it at same time of master command tick but we knows some which do not as Beckhoff AX5 series 

I am at second computer and I will update picture later this weel but during movement in 15m/s it can produce lag of 0.2mm with timing 250us ... which sound terrible 0

I did compensation component which add posCmd = position command + compensation during vcommand != 0 and every lag was gone ... it was purely for testing but solution is clear
positionOutputCompensated = positionOutput;
            
            if(fabs(vel_cmd) > 0.001)
            {
                double leadCycleLocal = lead_cycles;
                
                const double Ts = periodTime;
                const int    L  = (leadCycleLocal < 1) ? 1 : leadCycleLocal;
                const double LTs = (double)L * Ts;
                

                
                double lead = (vel_cmd * LTs) + (0.5 * acc_cmd * LTs * LTs);
                
                double ferr;
                ferr = (positionOutput - pos_fb_from_incremental);
                
                double comp = (kff * lead) + (k_err * ferr);
                posCompensation = comp;
            
                if(fabs(ferr) > fabs(fErrorOld) || fTopError == 0.0)
                {
                    fErrorOld = ferr;
                    fTopError = fErrorOld;
                }
            }
            else
            {
                posCompensation = 0;
            }
        
        positionOutputCompensated = positionOutput + posCompensation;
        
        if(ui_delayFinal > 0)
        {
            positionOutputCompensated = positionOutput;
            ui_delayFinal--;
        }
        
        //drv_target_position_incremental = (int32_t)(positionOutput * pos_scale * incremental_pos_scale);

        drv_target_position_incremental = (int32_t)(positionOutputCompensated * pos_scale * incremental_pos_scale);
  • minerva
  • minerva
Today 17:43

looking to tweak a working system for more accuracy

Category: Basic Configuration

You're absolutely right—whether you use metric or imperial, the key is the machine's mechanical condition and calibration. Since an inch is defined as 25.4mm, the choice of system doesn't inherently affect accuracy, as long as everything is properly calibrated, ideally through a NIST-certified facility.Microstepping is great for smooth motion but, as you mentioned, it doesn't guarantee linearity. The lead screw's accuracy, whether rolled or ground, and potential mapping for position errors are critical factors. Thermal expansion and material differences also play a role, especially at high precision.Starting with a thorough mechanical assessment of the machine is definitely the right move. Testing linearity and understanding the machine's baseline will help set realistic expectations. From there, progressive adjustments and testing will guide improvements. It’s a meticulous process, but your approach is spot on!
  • minerva
  • minerva
Today 17:42
Replied by minerva on topic wifi adapters

wifi adapters

Category: Advanced Configuration

It sounds like you’ve made a solid upgrade to your WiFi setup on your Dell Optiplex 960! Sticking with LinuxCNC 2.7.15 can be tricky for modern hardware, but the BrosTrend AC1200 adapter seems to have been a great choice. Following their driver instructions and getting support to identify the correct driver family clearly paid off, especially with that jump to 240 Mbps—huge improvement over 16 Mbps!

The speed difference between front and rear USB ports is likely due to power or USB version differences. Front ports might be USB 2.0 or better powered, while rear ports could be older or shared with other devices. Great job troubleshooting and boosting your network performance!
  • Nkbhvid
  • Nkbhvid
Today 17:01
Replied by Nkbhvid on topic Linuxcnc 2.9.4 and Mesa 7i97T

Linuxcnc 2.9.4 and Mesa 7i97T

Category: Installing LinuxCNC

Again -thanks for life-saving support on this issue
I have now a mesa 7i97T connected to my Linuxcnc and according to mesaCT everything seems to be ok.

Now I'm ready for the next chapter:
Configuring Linuxcnc for the analog setup with my Rexroth ECOdrive.
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?
  • OttoDidact
  • OttoDidact's Avatar
Today 17:00
Replied by OttoDidact on topic Mini PC for LinuxCNC/CPU Realtime Performance

Mini PC for LinuxCNC/CPU Realtime Performance

Category: Computers and Hardware

I just watched your YouTube video on reducing latency.

People were talking about isolating cores, and I think that your PC has 8 cores, not 7. Counting from zero gives you 8.

Could this be causing mischief with isolation?

Good video, that grub editor is good to know about.
  • COFHAL
  • COFHAL
Today 16:59

Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Category: Driver Boards

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
  • Aciera
  • Aciera's Avatar
Today 16:03
Replied by Aciera on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

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.
  • Mark Kraus
  • Mark Kraus
Today 15:51

There seems to be a mistake in this pinout I found.

Category: General LinuxCNC Questions

Still have no clue what could be wrong.  The at speed light comes on but nothing in halshow.  Could someone please guide me?

 
Displaying 1 - 15 out of 281860 results.
Time to create page: 1.733 seconds
Powered by Kunena Forum