Advanced Search

to make an .img file, run the command I posted, except change the of= part to:
of=/path/to/my/hardDiskBackup.img

first make sure your directory has enough free space to hold a file as large as your source disk.

writing that img file to a new empty drive then instead change the if= bit:
if=/path/to/hardDiskBackup.img

COFHAL wrote:

How do I create an image of the contents of one hard drive to install it on another? This is to avoid having to reinstall the additional applications I use with LCN.

There are various ways clone hard drives, I tend to use dd and make a bit-for-bit clone of the entire drive. Empty space and deleted files included. Takes longer but is the most reliable solution I've found.

The first time I did this was on a test machine containing no valuable data so I don't inadvertently destroy it. A little mistake in the following instructions could wipe your hard drive empty.

Important: the pc doing the cloning must not be booted from either drive; also, do not try booting the original or the clone while BOTH are connected to the pc. I learned that the hard way. Both drives' partitions will have identical UUID's which can be changed but it works as long as you don't boot one while both are connected to the same pc. I wouldn't even try mounting a partition while both are connected. Don't bother trying to clone nvme -> sata or sata -> nvme. I think it can be done, but I will not cover that complication. It is also possible to clone to a different sized drive, but I will not get into that here.

First make backups of everything in case this goes awry. You have been warned.

1: The linuxcnc pc is powered off. I connect an empty drive to it (same size as the original) and also a live-boot USB stick. The linuxcnc installer works great for this.

2: Boot the pc from the live-boot USB stick into the live-boot/testing. Do not launch the installer.

3: Find out which drive is which. One way to do that is to open Gparted and inspect the drives. On my system I might see that /dev/sda contains the installed linux os and /dev/sdb is the new empty drive. Your pc might be completely different. This is the most important detail.

4: Using the information gathered in step 3, I formulate the following terminal command:
be very careful of not copying the empty drive to the linuxcnc drive! You will then have two empty drives and no linuxcnc!
# dd if=/dev/sda of=/dev/sdb status=progress bs=1M conv=sync

I will not explain the very important "#" bit. If anyone reading this does not know what that is for, I would suggest to practice your terminal skills in less destructive ways before trying to do this.

if=/dev/sda is telling dd the "input file" is the sda disk
of=/dev/sdb tells it which is the "output file"
status=progress gives you some feedback what it is doing while it is busy
bs=1M sets the block size for copying I think default block size is 512B which copies insanely slowly. You can use block sizes larger than 1M, you might gain some speed, but if block size is set larger than the drive's internal cache space, your resulting copy will be botched. 1M seems to be a safe number that always works for me.

Depending what versions you're running, the status=progress bit will not work and will not display the progress. Just let it do its thing or find other ways to figure out if the hard drives are actively copying. Back when all I had was spinning rust, we didn't have status=progress, but I could HEAR it was doing its thing.

Depending on the size of your drives and their speed, this cloning can can take anywhere from a few minutes to a few weeks to complete. I've had 4GB spinning rust drives take a couple days. A 1TB ssd is usually way quicker than that.

graon
I just discovered there was already an answer to this question after I typed this up. If anyone has a problem with this I can remove it.

I tested it with Nidec N753(it has 0x60B1 avaible - but i did not implement the offset yet), Kollmorgen S343, Kollmorgen S7xx, Pilz pmcTendo, Beckhoff AX5106 hw2(https://codeberg.org/endian/Beckhoff_AX5ZYZZ_lcec_driver - here is working driver for AX5YZZ drivers with sercos.comp which is very similar to dominik cia's but only for AX with external trapeziodal homing based of high speed probing hw-input outside of master[lower cycle time at fpga]), Beckhoff el7221 and I will test it with @zmrdko's Delta ASDA drivers too ...

pictures shows like that solution synchronize of timing lag of position mode of ethercat

Can you show the same test at same velocity with compensation on and off? The two pictures are at very different speeds so it's hard to see what the compensation is actually doing.
 

 

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

endian wrote:

I tested it with Nidec N753(it has 0x60B1 avaible - but i did not implement the offset yet), Kollmorgen S343, Kollmorgen S7xx, Pilz pmcTendo, Beckhoff AX5106 hw2(https://codeberg.org/endian/Beckhoff_AX5ZYZZ_lcec_driver - here is working driver for AX5YZZ drivers with sercos.comp which is very similar to dominik cia's but only for AX with external trapeziodal homing based of high speed probing hw-input outside of master[lower cycle time at fpga]), Beckhoff el7221 and I will test it with @zmrdko's Delta ASDA drivers too ...

pictures shows like that solution synchronize of timing lag of position mode of ethercat

Can you show the same test at same velocity with compensation on and off? The two pictures are at very different speeds so it's hard to see what the compensation is actually doing.

A little bit off topic, but a cool experiment with multihead touchscreen


the camjog plugin:
youtube.com/shorts/pnibjyDy1ZI

For what it's worth, I've used $200 to $400 USD mini-pc's with way worse latency than this with ethercat and Mesa card setups and never bothered optimizing for latency. It seems to work great.

I like this better. I went in the bios and changed cpu power limit back from 10W to the default 35W "performance" setting.

Now it's bogging down. Toward the end I had to close some stuff so I could get screenshot to open. Boy, this thing is really throttling down.

Oh No! now I remember, a bit ago I was running this thing on a power tool battery+inverter , so I had changed the power limit in bios as low as it can be set! I will try one more time.

grandixximo wrote:

@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);
 

 I think I understand better now, good to know this issue exists. When I get to Phase 5 testing at 250µs, I might see this show up as following error that isn't the planner's fault.I will bookmark this for later, is you compensation component available to test with?

 

 

I tested it with Nidec N753(it has 0x60B1 avaible - but i did not implement the offset yet), Kollmorgen S343, Kollmorgen S7xx, Pilz pmcTendo, Beckhoff AX5106 hw2(codeberg.org/endian/Beckhoff_AX5ZYZZ_lcec_driver - here is working driver for AX5YZZ drivers with sercos.comp which is very similar to dominik cia's but only for AX with external trapeziodal homing based of high speed probing hw-input outside of master[lower cycle time at fpga]), Beckhoff el7221 and I will test it with @zmrdko's Delta ASDA drivers too ...

pictures shows like that solution synchronize of timing lag of position mode of ethercat

More screenshots; for the first run I left it running for a bit without teasing it much. Then I restarted the test and let it run a bit, occationally taking a screenshot, then opening more apps.

Wow, I just noticed the load average numbers in btop. I was noticing how glxgears is not showing a lot of cpu usage, now I notice it showing up in the load average. I will go back and find out what it takes to bump that load average over 16! I will post it.

When I'm building something like LinuxCNC from source I make sure I have the build terminal and btop open so I can watch it rip! Especially on the 10yr old server with two Xeon 14 core CPU's = 56 threads.

Yes, setting those ini variables fixed the issue.

Even at 10000 feed override (which showed on the screen as 0000)
 

Is restoring a 7i76 by externally reprogramming the dsPIC with the proper 7I76R14 image theoretically possible

If recovery requires a Mesa-provided programming image or process, is there any form of guidance or support you can offer? I fully understand if this is not something Mesa can support or disclose.

PCW wrote:

I still get this at 100% feed override:

 

The ini file

 

File Attachment:

File Name: 7i96s-1kio.ini
File Size:7 KB

(I set ini.traj_planner_type =1 by hand before starting)

 

please see this, I have fixed the INI, we will fix code a bit so that we can support your original configuration as well, the issue was/is max_jerk in traj was set to 0, which is the default, but actually should not be allowed.

Old mate was specifically asking about the RPi images, this is one of 2 threads where the subject was raised. And yeah I got a bit pissed.

After this comment:

Thank you for your response, and also for your subtle sarcasm in calling me ignorant every time I comment or ask for help in the threads you also participate in.

But I'm not anymore. The stress has been deleted.

Building  the bin files basically amounts to:

installing the Efinity too chain

unzipping the Mesa source for the particular card in to Efinitys project directory

Creating the desired pinout file for a particular configuration
(mainly a copy-past operation from existing pinout files)

adding the new pinout file to the project

including the new pinout file in the top level source

build

Note that I included the pinout source for the 7I95T  XY2-100 configuration