Advanced Search

Sorry about the delay. I cant upload the file because it has a sh extension. Please email me This email address is being protected from spambots. You need JavaScript enabled to view it. 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.

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

I've added some debug pins in my repo

lcec.0.dc-time-valid
lcec.0.dc-time-mod
lcec.0.dc-time-delta

please use halscope to read the values you get, if you are on master you can save the scope log, and you can use the attach button, in the reply editor, to attach the file, or a picture of the scope.

would it be possible to get remote access to the machine via teamviewer host?
download.teamviewer.com/download/linux/t...iewer-host_amd64.deb
I'd really like to experiment with the hardware, really interested in checking why my PLL is not working for you, if it is a case of bad I/O or something else, possibly something wrong with some of my code assumptions.

can you email me if you don't want to post here the teamviewer access

luca at aitalmac.com

Is my personal email, thanks

You may have a timer issue, I know others had conflict with the timer and hbo4 pregnant, I would investigate that.

Aside from that I'm not sure what would cause that except maybe a setting for the pregnant specific that may require a change?

Hopefully someone else can come in with knowledge on it. My wired jog pendant uses velocity mode when the speed is to fast for motion and the pulses begin to stack up, this stupid a runaway axis condition.

You can set the overrides so you can go both ways while running, the settings are in the ini file, check the Sims for reference.