Hi,

I am retrofitting a CNC lathe right now. In that process, I ran into a problem: my Z axis, which already worked, stopped doing so. I was messing with the encoder wiring, but I don’t think that is related. So X still works fine, but Z does not. I still get encoder feedback and see that when the machine is enabled, the Z axis drifts slowly.

I use a 7i97T and Chinese AASD motor drivers.

Troubleshooting I already did:

Driver: I confirmed that all the I/O still works. External E-stop, enable line from LinuxCNC, these are fine and work as expected. I then injected voltage into the analog line from the Mesa connector. The drive moves and stops after the following error gets too big, and the enable signal is removed by Mesa.

So I don’t think it is the driver or the wiring to it.

PWMgen: I then switched the pluggable connectors for X and Z on the Mesa and changed the HAL accordingly. Still, the X axis works fine and Z does not. In HAL Show I watched .pwmgen.nn.value, which started to grow after the machine was enabled and the Z axis started drifting. After a few seconds, it reached 60, which is the value of output-scale. With that, I would expect 10 V on that line, but I measure barely a few mV.

That really seemed like a hardware defect to me, but as I said, I switched the outputs between X and Z, and the PWMgens are confirmed to both be OK.

So in my head, only the software (e.g. HAL and INI) is left, but I did not really change anything there, at least I cannot think of anything.

With that, I am at the end of what I can think of. Please, if anyone has an idea, I am going insane trying to find this. I swear, if it is the equivalent of a missing semicolon in C…

I have the current .hal and .ini in the attachments.

At the end, I want to describe what I was doing immediately before this problem appeared. I cannot think of a reason how this would be connected, but still:

I had both axes moving and mostly tuned. I was testing the repeatability of the hall switches I use for homing. I found these to not be reliable and wanted to use the index pulses from the motor encoders. But I have linear scales on the machine, so I wired only the index pulses from the motor drivers to the Mesa inputs, while the A and B lines from the linear scales go directly to the bed and cross slide.

I changed only HOME_USE_INDEX = NO to HOME_USE_INDEX = YES and started the machine, at least that is what I remember. Since then, the INI and HAL have changed slightly as I tried to solve this. The HOME_SEQUENCE has changed as I wanted to check if the index thing worked for the X axis at least. It does.

So yes, I would be thankful for any help you can provide.

In this case i have Home switches on all axis,660x500 cm Travel on X,Y ,but i need only 40mm with a 2mm Endmill.... With a 3,175mm Endmill the Contour works fine,but the Finishing with the 2mm Endmill didnt !

Sorry about the delay. I cant upload the file because it has a sh extension. Please email me raggielyle1@gmail.com and I send the file.

Yes, you are using DC. Both of your working configurations are DC.
syncToRefClock does not mean "DC on or off". It only controls who is the time reference that everyone else follows. Both modes use Distributed Clocks.
refClockSyncCycles=1 means the master pushes its time to the slaves every cycle. The slaves follow the master. This is DC.
refClockSyncCycles=-1 (without syncToRefClock) means the master adjusts its own cycle to follow the first DC slave. The master follows the slave. This is also DC.
refClockSyncCycles=-1 with syncToRefClock="false" flips the sign, making it effectively +1. So it is the same as refClockSyncCycles=1. Master pushes time to slaves.
Both your working configs resolve to the same thing: master as reference, sync every cycle.
What does not work for you is the mode where master follows the slave (syncToRefClock="true" or negative refClockSyncCycles alone). That is what I want to investigate, whether it is a problem with what your first slave reports or something else in my code.
To confirm DC is active on your slaves, run these commands:
ethercat slaves -v
This will show "Distributed clocks: yes" or "no" for each slave. If it says yes, the hardware supports DC.
Then to check what sync mode is actually active:
ethercat upload -p 0 -t uint16 0x1C32 0x01
This reads the sync mode from the first slave. Value 0 means free run, 1 means SM-synchronous, 2 means DC Sync0, 3 means DC Sync1. You want to see 2 or 3. Replace -p 0 with -p 1, -p 2 etc for each drive.
Please post the output here, or if possible email me at luca at aitalmac.com about remote access. A USB to Ethernet adapter would give the machine internet while keeping the EtherCAT port dedicated.

Hello to all, I am new here and, do hope to learn what I can for what I intend to do with the CNC Router table and, linuxCNC. found this forum by chance, luck me.
I have Debian 12 on a laptop computer, I will be using this for the CNC router table in the workshop, I hope!
The issue I have is that I can not find a good site that has LinuxCNC that works on Debian 12 for download.
Is there anywhere that has this as a download? I simply need to put it on a flash drive and install it to the laptop.

Any help would be appreciated.

Yes excuse the correct question Is :

So in my case, the only way to get it to work is:
refClockSyncCycles=1, without syncToRefClock
or
refClockSyncCycles=-1, with syncToRefClock=false

So I'm not using DC mode?

refClockSyncCycles=-1, without syncToRefClock=false

Are you sure this works? I think you stated differently before.

I tried writing in the XML file:
refClockSyncCycles=5, without syncToRefClock, and the machine makes noise.

I also tried:
refClockSyncCycles=1000, without syncToRefClock, and the machine makes noise.

So in my case, the only way to get it to work is:
refClockSyncCycles=1, without syncToRefClock
or
refClockSyncCycles=-1, without syncToRefClock=false

So I'm not using DC mode?

DC has one start time, that's set on start usually by the first Ethernet DC capable device, from there you have two choices, either the slaves follow the time that the master declares every x cycles with refClockSyncCycles=x

Or everyone follows what the first slaves says the time is, master included. To do that master nudges its own cycle time to match what the first slaves report, the problem with your setup I think, is what the first master is reporting, so this system seems to not work correctly.
This mode is also DC and is set with 
refClockSyncCycles=-1
Or 
syncToRefClock="true"
 

refClockSyncCycles=-1 and syncToRefClock="false"

Is identical to 

refClockSyncCycles=1

What synctorefclock false clock does is make -1 become positive, if it was -5 it would be 5

refClockSyncCycles=-1 DC is enabled but master follows the reference slave, master will change its own time
This is identical to syncToRefClock true

About having only one Ethernet, USB to Ethernet adapter could work to give it internet, but I won't insist, but if possible I'd really love to test for myself, as some things get lost in communication 

Hello everyone. The machine has only one Ethernet port, dedicated to EtherCAT.

I wanted clarification regarding Hakan's statement:
If any of the slaves have an assignActivate bit 8 set (DC sync), switch on loop synchronization.

The drive's XML file contains these entries:

<OpMpde>
<Name>DC</Name>
<Desc>Dc-Synchron</Desc>
<AssignActive>#300</AssignActive>
<CycletimeSync0 Factor="1">0</CycleTimeSync0>
<ShiftTimeSync0Z0>/ShiftTimeSync0>
<OpModie>

Does this entry mean bit 8? Does the manufacturer declare that the drive supports DC?

So, to conclude.
If I write in the XML file:
refClockSyncCycles=-1 and syncToRefClock="false", DC is enabled, so the slaves synchronize with the master managed by LinuxCNC.

If I write only:
refClockSyncCycles=1 in the XML file, DC is enabled, so the slaves synchronize with the master managed by LinuxCNC.
But I can choose the synchronization frequency from 1-5-1000.

If I write only:
refClockSyncCycles=-1 in the XML file, DC is not enabled, but free mode is enabled, and the drives do not synchronize with the LinuxCNC master.

Correct?

I imagine that the best feature for a CNC machine is DC mode, or am I wrong?

I verified that the lcec.0.dc-phased pin is always false.

The option was buggy when introduced, and even now that it works, you can see how confusing it gets about what is actually happening when you have two options to do the same thing, I'll force the XML to be properly written with errors if they don't make sense, that seems the only way forward.
Concretely:
syncToRefClock=true + negative refClockSyncCycles = M2R, fine
syncToRefClock=false + positive refClockSyncCycles = R2M, fine
only one set, other at default = take the one that's set, fine
syncToRefClock=true + positive refClockSyncCycles = refuse to start with a clear error message
syncToRefClock=false + negative refClockSyncCycles = refuse to start with a clear error message

this is also what I proposed in github, I did implement but I had to roll it back, I will probably introduce it again, this is the only clear path if we want to keep both without confusion.
The last example was what caused the confusion with papagno-source

grandixximo wrote:

Recommendation: Use `refClockSyncCycles=1 or -1
Synctorefclock is just confusing.

It was a mistake from the beginning to let a negative value of refClockSyncCycles activate the pll synchronization method. It wasn't documented, is obscure and not logical. It was a too important option to be hidden in a "-" sign. Therefore the syncToRefClock option was introduced to mark that this is the synchronization option. In discussion with Scott, the "-" option was kept in the linuxcnc spirit of backwards compatibility. The intention and hope was that the usage of "-" should fade away over time. Don't go the "-" route, use syncToRefClock instead.

There is some evolution I guess. refClockSyncCycles was an attempt to synchronize slaves but that doesn't work. Then came the pll method and instead of adding its own option they let the "-" mean to activate the pll code. That was a mistake.

What should have been done was to get rid of refClockSyncCycles option altogether and have an option to either synchronize with the slaves or not. syncToRefClock was meant to be that. One can always argue about the naming, maybe it should be called dcSyncSlaves="true/false" instead?

There are really only two options. Synchronize linuxcnc's loop with the slaves' loops, or not. The first is done and required when using DC sync. For free run or SM synchronization methods a synchronized time is not needed since the slaves don't use it. Slaves don't need to be DC capable, it's optional.

One can extend this and automatically deduce the need for time synchronization.
If any of the slaves have an assignActivate bit 8 set (DC sync), switch on loop synchronization.
Otherwise don't touch the times.

Update on my situation.

I was able to solve my jog pendant issues. 

There were two changes I made:

1. halui signals:

Probe Basic
# ---HALUI signals---

net axis-select-x halui.axis.x.select
# net jog-x-pos halui.axis.x.plus
# net jog-x-neg halui.axis.x.minus
# net jog-x-analog halui.axis.x.analog
net x-is-homed halui.joint.0.is-homed
net axis-select-y halui.axis.y.select
# net jog-y-pos halui.axis.y.plus
# net jog-y-neg halui.axis.y.minus
# net jog-y-analog halui.axis.y.analog
net y-is-homed halui.joint.1.is-homed
net axis-select-z halui.axis.z.select
# net jog-z-pos halui.axis.z.plus
# net jog-z-neg halui.axis.z.minus
# net jog-z-analog halui.axis.z.analog
net z-is-homed halui.joint.2.is-homed
# net jog-selected-pos halui.axis.selected.plus
# net jog-selected-neg halui.axis.selected.minus
net spindle-manual-cw halui.spindle.0.forward
net spindle-manual-ccw halui.spindle.0.reverse
net spindle-manual-stop halui.spindle.0.stop
net machine-is-on halui.machine.is-on
# net jog-speed halui.axis.jog-speed
net MDI-mode halui.mode.is-mdiAxis# ---HALUI signals---

#net axis-select-x halui.axis.x.select
net jog-x-pos halui.axis.x.plus
net jog-x-neg halui.axis.x.minus
net jog-x-analog halui.axis.x.analog
#net x-is-homed halui.joint.0.is-homed
#net axis-select-y halui.axis.y.select
net jog-y-pos halui.axis.y.plus
net jog-y-neg halui.axis.y.minus
net jog-y-analog halui.axis.y.analog
#net y-is-homed halui.joint.1.is-homed
#net axis-select-z halui.axis.z.select
net jog-z-pos halui.axis.z.plus
net jog-z-neg halui.axis.z.minus
net jog-z-analog halui.axis.z.analog
#net z-is-homed halui.joint.2.is-homed
net jog-selected-pos halui.axis.selected.plus
net jog-selected-neg halui.axis.selected.minus
#net spindle-manual-cw halui.spindle.0.forward
#net spindle-manual-ccw halui.spindle.0.reverse
#net spindle-manual-stop halui.spindle.0.stop
#net machine-is-on halui.machine.is-on
net jog-speed halui.axis.jog-speed
#net MDI-mode halui.mode.is-mdi

For some reason I had ended up with the exact opposite lines commented between the new probe basic and the old axis configs (probably had used a toggle comment command in vs code accidentally). I swapped the commenting in the probe basic hal file to match the old axis file.

2. pendant.hal and pin conflicts
I had some pin conflicts between pendant.hal and the postgui hal that probe basic uses. I had originally changed them in the pendant.hal file to preserve probe basic postgui hal file. Now, I am using the pendant.hal file that worked with the old axis config and I modified the conflicting pins in the post gui hal file from probe basic.

Between those two changes, the pendant is now functioning just how it was on the old axis configuration.
So now I have a functioning pendant and a functioning ATC using probe basic as the UI.

Next to get my ATC rack made and get my probe working.

thank you sir , it is honor to be your student , but i hope to guide me to improve my skills in real-time c programming and the linuxcnc kernal , i am really surprised about it , i feel like in the temple itself