Advanced Search

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.

Both work. They are two different sync strategies, neither inherently better. It depends on which your drives like.

The two attributes are redundant and confusing. Negative `refClockSyncCycles` without `syncToRefClock` is the same as `syncToRefClock="true"`. The `syncToRefClock` attribute just explicitly overrides the sign convention. The code always takes `abs()` of cycles, so the sign is purely a mode flag.

With `syncToRefClock="true"` (or negative `refClockSyncCycles`), PLL runs every cycle regardless. The count value doesn't matter, only the sign. So `-1`, `-5`, `-100` all behave identically.

With `syncToRefClock="false"` (or positive `refClockSyncCycles`), the count does matter. It controls how often `ecrt_master_sync_reference_clock()` runs, every N cycles. `1` means every cycle, `1000` means once per second at 1kHz. Lower values mean faster convergence and more bus traffic. Watch `pll_err` and `dc_phased` pins to see when it locks. If it locks fast and stays stable, the value is fine. Examples in the repo use 1, 5, or 1000.

My take: positive cycles with `syncToRefClock="false"` is slightly cleaner, because the PLL stops once locked and less continuous computation happens, provided your drives tolerate the master as clock source. Yours do.

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

jetbadger wrote:

 In that setup it should be the same as X/Z axis but it's still acting drunk. 

How is the servo connected to the spindle?  My biggest problem a couple years ago when I started fiddling was that my spindle servo was WAY undersized for use as a direct-drive positioning motor.

I had a "2.2kw" BLDC servo connected through a 1.5:1 belt drive.  Soon as I put a chuck on the 5C spindle the inertia ratio was so unfavorable the servo couldn't really handle precise positioning.

I now have a comparatively monsterous 3.7kw (actual rating, not inflated) motor connected to the same spindle through a 2.5:1 belt.  Night and day difference.  That motor can horse the spindle around like it's barely there.

Maybe you have a significant inertia mismatch?  Don't want to throw you a red herring, but something to think about.

That makes sense, I didn't really think of what the INI parameter is actually connected to, but that makes sense now.

I'm still not wrapping my head fully around the velocity/position mode thing. It does make sense that if you have the drive in same scale and always in velocity mode both in stepgen and the drive that the scale shouldn't be crucial and the PID could take care of it, but having it the way I do which is stepgen in velocity and drive in step/dir position mode to me seems like should have to be the same thing, but it isn't for some reason.

I've spent some time today on the schaublin and the C axis hurdle. Some new progress is that I think it all has to do with the PID ratios and acceleration. I played around with it watching the plots and in the end it got slightly better, but the commanded position is still progressing very slow.

I've looped back the stepgen position-fb instead of the encoder for everything and it's still the same as with encoder so I'm still baffled. In that setup it should be the same as X/Z axis but it's still acting drunk. Maybe I'll think of something else as I didn't spend too much time today on that, instead did some other functionality of the machine, which is more practice in hal and ladder so maybe one day it'll all just click

Hier einige links zur Dokumentation


Info über Parameter
linuxcnc.org/docs/stable/html/gcode/over...ode:named-parameters

o Codes
linuxcnc.org/docs/stable/html/gcode/o-code.html#ocode:repeat

G-Codes
linuxcnc.org/docs/stable/html/gcode/g-code.html

That looks good.
The error is normal; it happens when LinuxCNC shuts down.
Can you move the axis in jog mode without any problems?
If so:
You now have two options. Connect the remaining axes and use the CIA402 homing.
Note: Prone to errors with gantry setups
or
Use the LinuxCNC homing. However, this is significantly less accurate.

If there are battery-powered encoder cables available for your servos,
install them, and you’ll save yourself the homing process and avoid any further trouble.

 

A question.
So is it better to work with refClockSyncCycles="1" or with
refClockSyncCycles="-1" and syncToRefClock="false"?
If the two settings are equivalent, does the value of refClockSyncCycles have to be 1 or can it take on values ​​other than 1, and how do I know what the correct value is in this case?

vielen Dank, Deine Zeilen muss ich noch lernen zu verstehen und oder ergänzen,

1° without power on <master idx="0" appTimePeriod="1000000" refClockSyncCycles="1">

DC reference time: 829435419653140029
Application time: 829439464192168202

2° without power on <master idx="0" appTimePeriod="1000000" refClockSyncCycles="1">

DC reference time: 829435419653140029
Application time: 829439529368163181

3° without power on <master idx="0" appTimePeriod="1000000" refClockSyncCycles="1">

DC reference time: 829435419653140029
Application time: 829439568792164528

4° without power on <master idx="0" appTimePeriod="1000000" refClockSyncCycles="1">

DC reference time: 829435419653140029
Application time: 829439599360167607


1° without power on <master idx="0" appTimePeriod="1000000" refClockSyncCycles="-1">

DC reference time: 829439756498240034
Application time: 829439771336260988

2° without power on <master idx="0" appTimePeriod="1000000" refClockSyncCycles="-1">
DC reference time: 829439756498240034
Application time: 829439799640262918

3° without power on <master idx="0" appTimePeriod="1000000" refClockSyncCycles="-1">
DC reference time: 829439756498240034
Application time: 829439828648257947

4° without power on <master idx="0" appTimePeriod="1000000" refClockSyncCycles="-1">
DC reference time: 829439756498240034
Application time: 829439854792266116