Advanced Search

If I have violated something, then the moderators must somehow notify about the violation. Maybe I'm asking something wrong, revealing some secrets? I don't blame you for deleting the topic......... Okay, we drove.

I always worried about joint axis homing but I think now it can be done in the drive with homing offset 0x607c which is really the same as our HOME_OFFSET. This probably would need to include  an indrive position adjustment for the last joint that makes it home to square the gantry. I need to think through the application of this as its just at the idea stage now.
I really appreciate the input here about the state machine. Homing sounds simple until you go to do it!

I think the homing bits I mention are often described as mode specific or some such garbage, but it is part of the cia402 homing standard that is not well desribed by many manufacturers.

Had event logging on today. It failed again (loop =10).
libusb_submit_transfer failed with LIBUSB_ERROR_NO_ DEVICE (-4) 
github.com/tenderlove/libusb/blob/763471...libusb/libusb.h#L750
github.com/tenderlove/libusb/blob/763471...13/libusb/io.c#L1288

 

Syslog is absolutely full of usb disconnects of the xhc device. Every 16-17 second the device disconnects and reconnects.
Must be the xhc component that does this? It only happens when linuxcnc is running.

 

If I look in github.com/tenderlove/libusb/blob/master...usb/os/linux_usbfs.c and search for LIBUSB_ERROR_NO_DEVICE,
they are there.
Why are all the disconnects/reconnects there? Wouldn't surprise me if that can cause something.
 

I did not remove the new topic, must have been some overlapping moderator work there.
Restored the post here.

So, I see two ways to monitor the reference run.
I can only describe it using SCL Logic.
If I have understood the documentation correctly...
in principle as follows:

case homing_status of
0:
     0x6098 := (-2 to 35);
     0x6099-01 := 13981013 or default from .ini;
     0x9099-02 := 1398101 or default from .ini;
     0x609A := 131072 or default from .ini,
     0x6040 > Bit 4 :=1; // start homing with rising edge
     homing_status :=  10:  // next step

10: // 1st safety monitoring 0x6041>Bit 9=1 Homing started
      // 0x6041>Bit9=0 start timer

     IF  (0x6041>Bit9=0) THEN  
           TON(IN := TRUE, PT:= T#1s); // example 1 second
           Error_Bool:= TON.Q; // time expired error is set
    ELSE
          TON(IN:=FALSE) //timer break
          homing_status:= 20
          END_IF

20: // 2nd safety monitoring Speed comparison
     IF target speed <> current speed THEN
            TON(IN := TRUE, PT:= T#1s); // example 1 second
            Error_Bool:= TON.Q; // Time expired error is set
     ELSE
           TON(IN:=FALSE) //Timer break
           homing_status:= 30
     END_IF

30://wait for homing to finish 

IF (0x6041>Bit15=1) THEN
     //prevents the axes from jumping and gives linuxcnc the opportunity for synchronization
    set halui.axis.n.jog-speed 0.06
    homing_status :=0
END_IF
 

I still remember setting up LinuxCNC back then with my stepper motors and a MESA card – for me it was quite time-consuming and complicated.Currently I am again searching for suitable components.
Current status is as follows:

• 2 × AC Servo Drive, EtherCAT, A6-1000EC, 1,000 W
  www.omc-stepperonline.com/de/1000-w-ethe...67-a6-ec1000h2b1-m17
• 1 × AC Servo Drive, EtherCAT, A6-400EC, 400 W
  www.omc-stepperonline.com/de/400-w-ether...p67-a6-ec400h2b1-m17
• 1 × Unknown for motor CM3C100L-45A-P/DI/PK/VR/EZ4Z/SDB
  download.sew-eurodrive.com/download/pdf/29194644.pdf
  (I will take care of this later.)

Nothing is final yet, but currently it is pointing towards using these components.Regards
Mücke

@Aciera Why did they delete My Post and New Topic? Did I uncover a Masonic secret about compiling components for linux cnc??????

hello,

During todays testing Ive noticed time spiking during the G64 P0.005 and less ... I know there is a huge tolerance limit but I am reporting it for full testing approach ... code 1_1001.ngc from .tar file - again simulation or circural interpolation by cloud of point 

otherwise timing get huge improve ... no big spikes and no big spikes of accelleration during the movement too!!!

I wish happy new year to China! Take a rest and we will see us after !

thanks

For tandem gantry (X/X2) with squaring, I think we need the usual per-axis homing supervision (start→motion watchdog + overall timeout) and a gantry delta monitor using 6064 feedback (abort if |Xfb−X2fb| grows beyond a reasonable limit during homing, and check final delta tolerance once both bit12 are true). While internal homing runs we keep pos_cmd slaved to pos_fb for both axes.

When homing 2X axis, get the position and watch to keep axises difference small.
Position disconnected from joints when doing this.

generic is the right choise.
There used to be a performance difference between generic and say the igb driver.
But not anymore, I always use generic even if I could use igb or igc.

I upgraded to 2.9.8 on a test system and initially saw the same problem you have.
Then I rebooted and made too many things to remember and then it worked again.
So I can only recommend to reboot and cycle the power of the ethercat units.
If that doesn't work, go back to 2.9.5 or try 2.9.8 iso.
Your settings from before is fine.
 

Is that a custom keypad now?
Looks good!

While waiting for Andrax’s view, IMHO for a generic CiA402 setup there’s no standard “homing started” bit, so I’d supervise it with two simple triggers/timers.

I’d start the overall homing timeout when the drive actually confirms Homing mode (6061 == 6). Then, when we assert the homing start (opmode-specific, e.g. the bit-4 flip after 6061 confirms), I’d start a short “start→motion” watchdog and look for real motion as proof (e.g. |6064 - pos0| > eps, or 606C > threshold).

andrax wrote:

@rodw Yes, I would have implemented it in the same way in a PLC. The only thing missing is the safety timer from start homing to axis in motion. Then the homing would be practically monitored. Regarding the axis jumping, you could set the feed rates to minimum after completion until Linuxcnc has synchronized.
 

Can you explain this timer? I would have thought you get the homing signal from linuxcnc, pass it on to the drive then  loop until bit 12 goes true keeping lcnc in sync.. I can't remember off the top of my head how we check that the homing request has actually stuck but I seem to remember we could do this too before doing the loop. Bit 13 will tell us if there is an error during homing.

I think after you upgrade your linuxcnc, you might want to build a compatible version of linuxcnc-ethercat
and check your settings
with your hardware generic is inevitable, it is not supported, performance will not be guaranteed. I should look at getting hardware that already has support from IGH
like intel igc or intel igb
but I never got eoe to work, so you are already ahead of me on that front, so I might be just blabbering nonsense...