Advanced Search

salue zusammen,
ich habe ein wenig wegen dieser Thematik recheriert, nur komme ich nicht für Linux CNC auf Antworten wie ich sie verstehe und oder benötige.
Mir ist G Code zum fräsen noch nicht so geläufig. Bedeutet, ich möchte ein kleines G Code Programm schreiben welches mir mit der X Achse ein Verfahrweg von 100mm ins plus und wieder 100mm ins minus verfährt und zwar mit X anzahl Wiederholungen bis ich unterbreche oder bsi diese abgelaufen sind?
G 25 und G 26 scheint nicht verwendbar zu sein. Wie sehen G code Zeilen für Linux CNC aus die mir die Bewegung in der X Achse mit Wiederholungen, Schlaufe und oder Loop ausführt? 

lieben Dank schon mal im voraus
Claude

can you run ethercat master a few times consecutively while running with

refClockSyncCycles="-1"

and paste here the DC reference and the App time values?

at least 3~4 consecutive times please

do the same for 

refClockSyncCycles="1"

With refClockSyncCycles="-1" the value of the ecat.0.pll_reset_cnt pin is continuously increasing, it never stops, it increases in a positive direction more and more, in a short time it was already at 20,000

with  refClockSyncCycles="1" the pin ecat.0.pll_reset_cn remain stable = 0

please check hal pin
ecat.0.pll_reset_cnt

with refClockSyncCycles="-1"
 

As mentioned, with only the refClockSyncCycles="-1" parameter, the axis makes noise, but it's only for reconfirmation.
Parameter values ​​are with refClockSyncCycles="-1"
ethercat upload -p 0 -t uint32 0x1C32 0x06 return 0x00000000 0
ethercat upload -p 0 -t uint32 0x1C33 0x06 return 0x00000000 0
ethercat upload -p 1 -t uint32 0x1C32 0x06 return 0x00000000 0
ethercat upload -p 1 -t uint32 0x1C33 0x06 return 0x00000000 0
ethercat upload -p 0 -t uint32 0x1C33 0x03 return Failed to upload SDO: Input/output error
ethercat upload -p 1 -t uint32 0x1C33 0x03 return SDO transfer aborted with code 0x06010001: Attempt to read a write-only object
ethercat upload -p 0 -t uint32 0x1C32 0x09 return 0x00030d40 200000
ethercat upload -p 1 -t uint32 0x1C32 0x09 return 0x00000000 0

I can't reverse I/O with the drive. I/O is always 0, the drives follow. I would have to change everything hal, but this configuration works fine with Debian 10 and now also with Trixie, but with refClockSyncCycles="1"

The pin pll , oscillation value about 1 second value 0 after 4210619, after 1 second restar with 0

@rodw

rodw wrote:

Hakan wrote:

grandixximo's linuxcnc-ethercat repo, right?
That pll-err value shows it's not the linuxcnc standard code. That oscillates around zero.
 
Please expand on what you mean here.

This is a standard RIP install of Debian 2.10 except its in a folder under /usr/lib, grandixximos driver built from source, Ethercat from repos. That should make no difference. For me, latency etc is fine on my hardware which makes it weird.

 

In Scott's linuxcnc-ethercat repo pll-err oscillates around 0.
In grandixximo's repo pll-err oscillates around that number 992000 something.
It's not necessarily wrong, it was just how I could tell.

sorry, I got messed up, should test the ethercat upload commands with 
refClockSyncCycles="-1"

If you could also do some more testing, I'd really like to get to the bottom of this

also with refClockSyncCycles="-1" (don't move just start)

Check pll_reset_cnt, does it increment every ~1/sec?

Also could you move the first servo drive as the first slave, and try with refClockSyncCycles="-1"?




 

I only tested refClockSyncCycles="1" without writing syncToRefClock, and the machine worked flawlessly.

The lcec.0.pll-err pin in this case reported a value oscillating from approximately 991902 to 994498.

The rest remained the same:
<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0"/>

The result is :

ethercat upload -p 0 -t uint32 0x1C32 0x06 return Failed to upload SDO: Input/output error
ethercat upload -p 0 -t uint32 0x1C33 0x06 return Failed to upload SDO: Input/output error
ethercat upload -p 1 -t uint32 0x1C32 0x06 return 0x00000000 0
ethercat upload -p 1 -t uint32 0x1C33 0x06 return 0x00000000 0
ethercat upload -p 0 -t uint32 0x1C33 0x03 return SDO transfer aborted with code 0x06010000: Unsupported access to an object
ethercat upload -p 1 -t uint32 0x1C33 0x03 return SDO transfer aborted with code 0x06010001: Attempt to read a write-only object
ethercat upload -p 0 -t uint32 0x1C32 0x09 return 0x00030d40 200000
ethercat upload -p 1 -t uint32 0x1C32 0x09 return 0x00000000 0

then it should also work with 

refClockSyncCycles="1"

just the above don't add

syncToRefClock="false" or syncToRefClock="true"

your assumption is correct in the case you are testing.
refClockSyncCycles="-1"
will force syncToRefClock="true" because that is expected to respect old behavior

so your problem is PLL is causing the vibrations

Please run my commands again with only

refClockSyncCycles="1"

then run

ethercat upload -p 0 -t uint32 0x1C32 0x06
ethercat upload -p 0 -t uint32 0x1C33 0x06
ethercat upload -p 1 -t uint32 0x1C32 0x06
ethercat upload -p 1 -t uint32 0x1C33 0x06
ethercat upload -p 0 -t uint32 0x1C33 0x03
ethercat upload -p 1 -t uint32 0x1C33 0x03
ethercat upload -p 0 -t uint32 0x1C32 0x09
ethercat upload -p 1 -t uint32 0x1C32 0x09

syncToRefClock is false by default, your assumption is incorrect, are you sure you have built my repo's code?

Yes machine work only with refClockSyncCycles="-1" syncToRefClock="false"

Initially, everything seemed to be working fine, because I was testing a system with smaller motors, always from the same manufacturer, not connected to the mechanics. I noticed the problem when I started moving the axes on a real machine. Here's my experience:
-First of all, on Debian 10 with EtherCAT 1.5.2, I never used the :syncToRefClock parameter, only refClockSyncCycles.
-On a real machine with an ASD2 Delta drive, with the first I/O node being the same, if I set the refClockSyncCycles parameter to -1, the axes shook at the first movement.
If I set the refClockSyncCycles parameter to 1, the machine worked 99.9% of the time; only very rarely was I forced to reboot the system because the axes made noise the first time they were restarted.

Still on Debian 10 with ethercat 1.5.2, with the same I/O node, with a Veichy drive, the refClockSyncCycles=1 parameter causes the axes to shake. I had to set refClockSyncCycles=-1 to work without problems.

Debian Trixie ethercat 1.6.9, Veichy drive machine. I initially set the Debian 10 xml file, so with only refClockSyncCycles=-1, the machine makes noise.
I then modified the xml with refClockSyncCycles=-1 and syncToRefClock="false" and now the machine works correctly.

I haven't been able to test Debian Trixie with the ASD2 drive, but I think at this point it will behave the same as Debian 10, namely:
refClockSyncCycles=1 and syncToRefClock="false"

I therefore assume that the syncToRefClock="true" parameter is set by default if not added to the XML file.

Are you saying that the only way it works is this

refClockSyncCycles="-1" syncToRefClock="false"

??????

the result is :

ethercat upload -p 0 -t uint32 0x1C32 0x06 return 0x00000000 0
ethercat upload -p 0 -t uint32 0x1C33 0x06 return Failed to upload SDO: Input/output error
ethercat upload -p 1 -t uint32 0x1C32 0x06 return 0x00000000 0
ethercat upload -p 1 -t uint32 0x1C33 0x06 return 0x00000000 0
ethercat upload -p 0 -t uint32 0x1C33 0x03 return Failed to upload SDO: Input/output error
ethercat upload -p 1 -t uint32 0x1C33 0x03 return SDO transfer aborted with code 0x06010001: Attempt to read a write-only object
ethercat upload -p 0 -t uint32 0x1C32 0x09 return 0x00030d40 200000
ethercat upload -p 1 -t uint32 0x1C32 0x09 return 0x00000000 0


I've already tested only refClockSyncCycles="-1" without syncToRefClock="true" and the problem persists.

I've also tested refClockSyncCycles="1" and syncToRefClock="true"
and the problem persists.

Do you want me to try deleting refClockSyncCycles="1" and leaving only syncToRefClock="true"?

Sometimes you do not have enough room for the tool outside of the machine limits.
Install home switches, set the tool centered above the part and set your G54 offsets and it will likely work fine. 

the radius error is related to your gcode. Sometimes from running absolute instead of incremental  arcs or vice versa,