Search Results (Searched for: )

  • tuxcnc
Yesterday 21:26
Replied by tuxcnc on topic Open loop motors problem

linuxcnc-ethercat.github.io/apt/
 
I followed the instructions.
Apt wanted to install `linux-image-6.12.116`.
Why?
I don’t use the standard kernel, and I don’t want to.
I took the steps below, and everything proceeded as expected.
Code:
apt-mark hold linux-headers-6.12.116+deb13-amd64 linux-headers-6.12.116+deb13-common linux-headers-amd64 linux-image-6.12.116+deb13-amd64 linux-kbuild-6.12.116+deb13 [code]apt-get install linuxcnc-ethercat ethercat-master
[/code]
The current situation is as follows:
Code:
root@elite:~# dpkg -l | grep -E 'linuxcnc-(uspace|ethercat)|ethercat-master|etherlabmaster|libethercat' ii  ethercat-master                       1:1.6.13-3+deb13u1                   amd64        IgH EtherCAT master — userspace tools and services ii  libethercat:amd64                     1:1.6.13-3+deb13u1                   amd64        IgH EtherCAT master — runtime shared library ii  linuxcnc-ethercat                     1.48.0-1+deb13u1                     amd64        LinuxCNC EtherCAT HAL driver ii  linuxcnc-uspace                       1:2.10.0~pre1                        amd64        motion controller for CNC machines and robots ii  linuxcnc-uspace-dev                   1:2.10.0~pre1                        amd64        PC based motion controller for real-time Linux root@elite:~#  root@elite:~# ethercat slaves -v === Master 0, Slave 0 === Device: Main State: PREOP Flag: + Reinit hold: no Identity:   Vendor Id:       0x0000ffff   Product code:    0x00000001   Revision number: 0x00000001   Serial number:   0x00000000 DL information:   FMMU bit operation: no   Distributed clocks: yes, 64 bit   DC system time transmission delay: 0 ns Port  Type  Link  Loop    Signal  NextSlave  RxTime [ns]  Diff [ns]   NextDc [ns]    0* MII   up    open    yes             -   3269426044           0           0    1  MII   up    open    yes             1   3269431284        5240         580    2  N/A   down  closed  no              -            -           -           -    3  N/A   down  closed  no              -            -           -           - Mailboxes:   Bootstrap RX: 0x0000/0, TX: 0x0000/0   Standard  RX: 0x1000/64, TX: 0x1100/64   Supported protocols: CoE General:   Group: stepper driver   Image name: DRIVE   Order number: TQ870   Device name: TQ870(COE)   CoE details:     Enable SDO: yes     Enable SDO Info: no     Enable PDO Assign: yes     Enable PDO Configuration: yes     Enable Upload at startup: no     Enable SDO complete access: no   Flags:     Enable SafeOp: no     Enable notLRW: no   Current consumption: 0 mA === Master 0, Slave 1 === Device: Main State: PREOP Flag: + Reinit hold: no Identity:   Vendor Id:       0x0000ffff   Product code:    0x00000001   Revision number: 0x00000001   Serial number:   0x00000000 DL information:   FMMU bit operation: no   Distributed clocks: yes, 64 bit   DC system time transmission delay: 580 ns Port  Type  Link  Loop    Signal  NextSlave  RxTime [ns]  Diff [ns]   NextDc [ns]    0* MII   up    open    yes             0   3269114404           0         580    1  MII   up    open    yes             2   3269118484        4080         680    2  N/A   down  closed  no              -            -           -           -    3  N/A   down  closed  no              -            -           -           - Mailboxes:   Bootstrap RX: 0x0000/0, TX: 0x0000/0   Standard  RX: 0x1000/64, TX: 0x1100/64   Supported protocols: CoE General:   Group: stepper driver   Image name: DRIVE   Order number: TQ870   Device name: TQ870(COE)   CoE details:     Enable SDO: yes     Enable SDO Info: no     Enable PDO Assign: yes     Enable PDO Configuration: yes     Enable Upload at startup: no     Enable SDO complete access: no   Flags:     Enable SafeOp: no     Enable notLRW: no   Current consumption: 0 mA === Master 0, Slave 2 === Device: Main State: PREOP Flag: + Reinit hold: no Identity:   Vendor Id:       0x00000a79   Product code:    0x00003000   Revision number: 0x00000001   Serial number:   0x00000000 DL information:   FMMU bit operation: no   Distributed clocks: yes, 64 bit   DC system time transmission delay: 1260 ns Port  Type  Link  Loop    Signal  NextSlave  RxTime [ns]  Diff [ns]   NextDc [ns]    0* MII   up    open    yes             1   1817433980           0         680    1  MII   up    open    yes             3   1817436700        2720         680    2  N/A   down  closed  no              -            -           -           -    3  N/A   down  closed  no              -            -           -           - Mailboxes:   Bootstrap RX: 0x0000/0, TX: 0x0000/0   Standard  RX: 0x1000/128, TX: 0x1100/128   Supported protocols: CoE General:   Group: EtherCAT Driver   Image name:    Order number: TLC57-E   Device name: TLC57-E   CoE details:     Enable SDO: yes     Enable SDO Info: no     Enable PDO Assign: yes     Enable PDO Configuration: yes     Enable Upload at startup: no     Enable SDO complete access: no   Flags:     Enable SafeOp: no     Enable notLRW: no   Current consumption: 0 mA === Master 0, Slave 3 === Device: Main State: PREOP Flag: + Reinit hold: no Identity:   Vendor Id:       0x00000a79   Product code:    0x00003000   Revision number: 0x00000001   Serial number:   0x00000000 DL information:   FMMU bit operation: no   Distributed clocks: yes, 64 bit   DC system time transmission delay: 1940 ns Port  Type  Link  Loop    Signal  NextSlave  RxTime [ns]  Diff [ns]   NextDc [ns]    0* MII   up    open    yes             2   1822098780           0         680    1  MII   up    open    yes             4   1822100140        1360         680    2  N/A   down  closed  no              -            -           -           -    3  N/A   down  closed  no              -            -           -           - Mailboxes:   Bootstrap RX: 0x0000/0, TX: 0x0000/0   Standard  RX: 0x1000/128, TX: 0x1100/128   Supported protocols: CoE General:   Group: EtherCAT Driver   Image name:    Order number: TLC57-E   Device name: TLC57-E   CoE details:     Enable SDO: yes     Enable SDO Info: no     Enable PDO Assign: yes     Enable PDO Configuration: yes     Enable Upload at startup: no     Enable SDO complete access: no   Flags:     Enable SafeOp: no     Enable notLRW: no   Current consumption: 0 mA === Master 0, Slave 4 === Device: Main State: PREOP Flag: + Reinit hold: no Identity:   Vendor Id:       0x00000a79   Product code:    0x00003000   Revision number: 0x00000001   Serial number:   0x00000000 DL information:   FMMU bit operation: no   Distributed clocks: yes, 64 bit   DC system time transmission delay: 2620 ns Port  Type  Link  Loop    Signal  NextSlave  RxTime [ns]  Diff [ns]   NextDc [ns]    0* MII   up    open    yes             3   1828993020           0         680    1  MII   down  closed  no              -            -           -           -    2  N/A   down  closed  no              -            -           -           -    3  N/A   down  closed  no              -            -           -           - Mailboxes:   Bootstrap RX: 0x0000/0, TX: 0x0000/0   Standard  RX: 0x1000/128, TX: 0x1100/128   Supported protocols: CoE General:   Group: EtherCAT Driver   Image name:    Order number: TLC57-E   Device name: TLC57-E   CoE details:     Enable SDO: yes     Enable SDO Info: no     Enable PDO Assign: yes     Enable PDO Configuration: yes     Enable Upload at startup: no     Enable SDO complete access: no   Flags:     Enable SafeOp: no     Enable notLRW: no   Current consumption: 0 mA root@elite:~# 
The TQ870 still stutters with the parameter set to `*1`, but it works fine with `*10`.
I haven’t had time for proper testing yet.
For now, I’m using a small utility:
Code:
g61 o100 repeat[100] g0a60b150 a30b120 g0a90b180 a0b90 o100 endrepeat m2
This is definitely not the right tool for the job; I need to write something that moves all axes simultaneously and runs about a thousand cycles—otherwise, I won’t consider the configuration safe.
  • Jonathan_H
Yesterday 21:24
Hi,
We have a couple of CNC machines running a mesa board with very similar NUC Intel PCs running LinuxCNC
The Mesa board should greatly reduce critical timing requirements for the host machine, I've turned off everything in the bios that is suggested and whenever I run a jitter test I get decent looking numbers. But sooner or later I always seem to get a communication error, apparently related to timing, it's like sooner or later something somewhere holds things up for just too long.
Now one PC has died (power supply failure) so it needs to be replaced anyway, and I'm wondering whether we should try going down a different path with something ARM based such as a Pi 5.
So, is it a good idea? Will it improve things? Are there other better/cheaper allternatives?

regards
Jonathan
  • Schaublin12
Yesterday 21:13
Replied by Schaublin12 on topic single block mode: movement commands build up
Thanks for your help. I think having one button for single-block mode and another for pause is impractical. I would have found it more practical if pressing the single block button would pause the g-code at the next opportunity. In that case, I prefer Rod's control concept.
  • dirkx
Yesterday 19:53
Thank - that example is useful - but I am still struggling to inhibit a mode change/resume.

, menu entries and remode commands. And I do not want to put the machine in e-stop; as we're in the middle of a manual toolchange ;)
  • kn612
Yesterday 18:26
 

Haven't ran it on my actual machine yet, but here's an example of a gradient style screen set for qtplasmac made with claude 
  • Hakan
Yesterday 18:05
I now have two prototypes
- EtherCAT Setup, a program that reads the slaves on the bus (their EEPROM, CoE dictionary and ESI files), proposes a configuration, checks it, helps find out why a slave does not work, and test it
- ecat , a HAL component, grown out of linuxcnc-ethercat, that reads that configuration. It runs the userspace IgH master inside LinuxCNC, so no kernel module needed.

This is an early stage. What you see is a base that shows what the tool can do; a good workflow around it is still to be found.
I am now putting this on hold to let the thoughts around the usage mature.

Below are animated gifs from my plasma cutter; three ECT60 drives in CSP and one IO board for THC.

Reading the bus. Every slave, its state, and how it matches the configuration file. The process data, HAL pins and start-up SDOs of each slave can be edited and checked as you type.


Troubleshooting. Why a slave is not in OP: the way from INIT to OP, the AL status code in plain words, error counters per port, and the slave's own messages.


Testing I/O. The configuration runs in halrun with the same component as in the machine, without LinuxCNC. Inputs are shown live, outputs can be set, and SDOs can be read and written.


Moving a drive. A CiA 402 drive in CSP can be jogged in small steps. The drive is enabled only while a button is held. Limits are written to the drive and put back afterwards, velocity, acceleration and the travel are limited in HAL, and a heartbeat disables the drive if the program stops answering.


HAL. The pins the configuration gives, and the lines for the HAL file. Writing them into the LinuxCNC configuration is the next step.


The code is at github.com/MetalMusings/ecat , with Debian 12 and 13 packages under Release. It needs the userspace EtherCAT master from github.com/MetalMusings/linuxcnc-ethercat (the uspace-v* releases).

 
  • mwc
Yesterday 18:02
Replied by mwc on topic New Forum Reports

And the editor lets you paste images, but shows them as text 🙈




 
Aren't you glad it only took 3-4 weeks of my time and 4 attempts to upgrade the forum with minimal loss of content? It could have been a lot worse being it was my first time doing a major OS, Joomla and Kunena upgrade on a new droplet.

JT




 
Sorry, that wasn't meant to be a dig at you, more an observation about how the editor capability doesn't match the actual posts.
As well as the image issue, the code is another example. Code displays pretty well in the editor, but once you post, it goes to that rubbish format.
For example, screen shot from the editor-

And how it's displayed in the post -
Code:
Some code another line of code
  • Wischi
Yesterday 17:49
Thank you! But i was more thinking when having the tool table open (in gmoccapy) and entering the values. Because there, the column is in diameter. When you use the G10 command it actually multiplies the radius by 2 and enters that into the tool table.

But you’ve given me an idea: Write a gmoccapy macro which asks tool#, radius and length (all on label from presetter) and then run a G10 L1 P# R# Z# to update the table. This also prevents from entering values into the wrong column.
  • JT
Yesterday 17:39
Replied by JT on topic New Forum Reports

And the editor lets you paste images, but shows them as text 🙈

 
Aren't you glad it only took 3-4 weeks of my time and 4 attempts to upgrade the forum with minimal loss of content? It could have been a lot worse being it was my first time doing a major OS, Joomla and Kunena upgrade on a new droplet.

JT
  • MaHa
Yesterday 17:27 - Yesterday 17:28
example:  G10 L1 P5 R2.5   sets T5 diameter to 5 in tooltable

 
  • Wischi
Yesterday 16:51
Hello,

is it possible to use the radius instead of the tool diameter in a milling config tool table? I am using a tool presetter which only outputs the radius of a tool. Sadly it can't be changed.

Thanks.
  • M0ti0n
Yesterday 16:38
Replied by M0ti0n on topic GNEZDO NESTING SOFTWARE
Ok i made info page a bit more readable and added roadmap for project
also under releases you can now find linux desktop, windows desktop and windows server versions to try out... 
github.com/M0ti0n/GNEZDO
 
  • kn612
Yesterday 15:52
All good stuff, I used Claude to make a cad/cam/nesting program for with parametric shape library that outputs a toolpath for qtplasmac 

  • djdelorie
Yesterday 14:39
Alternate ways to stop the machine was created by djdelorie
My machine as various levels of "I need to stop now".  Physical estop switches are in the contactor chain (and an input pin), VOLATILE_HOME is set, servos are monitored, and now I have a HAL component that keeps rogue gcode from crashing into my toolholder.  However, that last one causes the machine to unhome because it's wired to turn the machine off, and volatile_home...
The servo faults (clearpath) are wired into joint.N.amp-fault-in, and the servo enable is wired into pid.N.enable.  They lose position when disabled.
Is there an alternate way to say "stop this job now" in HAL, for cases where the gcode (or the user) is the problem, not the machine?  I.e. that doesn't turn the machine off or unhome anything?
Or is this a case for something in python?
  • grandixximo
Yesterday 13:39
@mwc homing has been tested on 2.9.10, I am waiting on another feature to get tested and I will release hopefully within the week, keep an eye on the repo.
Displaying 1 - 15 out of 190823 results.
Time to create page: 1.350 seconds
Powered by Kunena Forum