Advanced Search

grandixximo's linuxcnc-ethercat repo, right?
That pll-err value shows it's not the linuxcnc standard code. That oscillates around zero.

I have looked in the code but don't see why it does what it does.
It is supposed to work like this
When the syncToRefClock option is given the "-" is ignored, "true" means to switch on, any other string means to not activate the pll code.
In lack of the syncToRefClock option, the "-" will switch on the pll code.
Your code doesn't react in that way.

Hakan is correct, but depends on device, we should check what they report.
could you run these?
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

Run these and write here the output, to confirm if sync0shift 0 is supported

Also

refClockSyncCycles="-1" syncToRefClock="false"
is self contradictory

use only 
refClockSyncCycles="-1"
or only 
syncToRefClock="true"

to enable PLL

Just be patient, I started from scratch today and got the framework working but some of the data is  incorrect.
In the mean time, learn how to build linuxcnc as a RUN IN PLACE version for testing
When I get a bit further, you will be able to clone my git repository and test it for me.

System Test Is Debian Trixie 13.3 , kernel 6.12.74 RT, linuxcnc 2.10 ( actual Master), Ethercat 1.6.9.

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

That's the right behavior even if the actual value is strange.

Which version of linuxcnc-ethercat (lcec) are you using right now during these tests?

Good morning everyone.
I did the following test:
refClockSyncCycles="1" syncToRefClock="true" with <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="300000"/>

The problem returned, noise on the axes.

I ran this other test:
refClockSyncCycles="1" syncToRefClock="true" with <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="500000"/>

The problem returned, noise on the axes.

the lcec.0.pll-err pin in both cases reported a value of 0 for about 1 second and then changed to 5072592 for about another second, before repeating the cycle.

The only way to make the noise disappear is:
refClockSyncCycles="-1" syncToRefClock="false" with <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0"/>

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


I haven't tried :
refClockSyncCycles="-1" syncToRefClock="false" with <dcConf and sync0Shift= values ​​other than zero.

The result of the command:
dpkg -l|grep ethercat on debian Trixie is:

ii ethercat-dkms 1.6.9.gb709e58-1+28.1 all IgH EtherCAT Master
ii ethercat-master 1.6.9.gb709e58-1+28.1 amd64 IgH EtherCAT Master
ii libethercat 1.6.9.gb709e58-1+28.1 amd64 IgH EtherCAT Master
ii libethercat-dev 1.6.9.gb709e58-1+28.1 amd64 IgH EtherCAT Master


same command on Debian 10, returns nothing.

if I run : ethercat version
IgH EtherCAT 1.5.2 unknown

 

I think you are using shiftTime in the wrong way.
Your work should focus on the SM2/SYNC0 distance, that it is sufficient.
shiftTime is a slave requirement, not a synchronization requirement.
My slaves work with shiftTime 0.
 

Learning how to actually operate the lathe I built, and I've confused myself over tool orientation.

Gang-tool lathe, with front and back tools.  Defined in INI as a back tool lathe, but that can change if needed.

I use Fusion for CAM, and the standard LCNC post for fusion.  The post handles front/back tool orientation by setting the 'turret' value in the F360 tool library to 103 or 104.  When the post sees a '103' for the turret, it outputs all X-moves with negative values.  Opposite for '104'.

While this results in appropriate tool motion, the LCNC backplot is wrong, kinda.  The toolpaths are appropriately displayed as negative X (below centerline), but the tool tip indicator is approaching across the centerline - looks kinda crashy.

Having researched the forum a while back about gang-tool lathes, I found the 'trick' about using G10 to rotate the WCS 180 degrees around Z for back tools.  So I've got a couple M-codes to do just that - flip back and forth between back and front tool views.

Caught me off guard the first time I flipped the X axis and jogs were backwards.  I somehow thought it was just the display/backplot that rotated...

But that got me thinking about the point of this long-winded post.  Can I use the lathe tool orientation value (parameter #5413) to drive the M-code WCS flip during a tool change?  And leave all tools as 'front turret' in F360 so the post only outputs X positive numbers?

I've got a lathe-fanucy test config on deck (remap T) for testing.  Maybe add a conditional check for the value of #5413?  Something like:

Anyone see any holes in my theory or suggestions for improvement?

DEAR Sir, it is great work and i hope to learn alot of you , that was very deep in the CNC FOUNDATION, I am now in need to use my machine and the level of mach3 is very suffecient to me , so what do you recommend to achieve this level now and i hope to join your effort of your project that i hope to learn much of you , thank you sir

Demystifying syncToRefClock and refClockSyncCycles

syncToRefClock="true" means the master syncs to the slaves, adjusting its period every cycle to track the DC reference clock (PLL/bang-bang mode).

syncToRefClock="false" means the slaves sync to the master. refClockSyncCycles then controls how often (every N cycles) the slaves perform a sync adjustment.

refClockSyncCycles="-1" (any negative number) means master syncs to slaves, identical to syncToRefClock="true". The magnitude does not matter.

So all four combinations you tested:


refClockSyncCycles="1" syncToRefClock="true"
refClockSyncCycles="5" syncToRefClock="true"
refClockSyncCycles="1000" syncToRefClock="true"
refClockSyncCycles="-1" syncToRefClock="true"


are completely identical. When syncToRefClock="true", the slaves are not in a mode where they sync to the master, so refClockSyncCycles is simply ignored.

The combination refClockSyncCycles="-1" with syncToRefClock="false" is a contradiction and will be treated as invalid in a future version.

Why you heard noise with syncToRefClock="true" and sync0Shift="0"

This is expected and correct behaviour. With sync0Shift="0", SYNC0 fires exactly at t=0, right as the cyclic frame is arriving. The slave latches output data at the same instant it is being written, creating a race condition every cycle. The grinding noise is the mechanical result.

The fix is not to disable syncToRefClock. Set a proper shift:


<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="300000"/>


300000 to 500000 ns on a 1ms cycle is a reasonable starting point. Try that with syncToRefClock="true" and the noise should go away.

If you think sync0Shift="0" always worked for you

It did not work correctly, it appeared to work. The race condition was present but your hardware was consistently winning it by luck. The code now behaves strictly per ETG.1020. If it seemed to work before, it was not according to the standard. Update your configuration.

To help investigate the OP regression, can you run the following and paste the output?


dpkg -l | grep ethercat

Do this on the system with the 1.5.2 that OP's quickly please
maybe we get more than just 1.5.2 we can get some build reference, and I can look at the code, the 1.5.2 I found is identical in OP time as 1.6.8

rodw wrote:

@Tommy, add FOR TANGENTAL KNIFE to the title

 

Done, thank you.

@Tommy, add FOR TANGENTAL KNIFE to the title

@bedouno, Linuxcnc's architecture is complex and described in the docs here
linuxcnc.org/docs/devel/html/code/code-notes.html
The problem to set the tangential heading is that the geometry is known by the gcode but once the gcode is tokenised into a buffer, the gcode (and geometry) is thrown away so motion is just left with way points and segments. Furthermore, this gcode tokenisation is buffered so the interpreter can be many segments ahead of the motion parameters at run time.The intent of state tags was to "tag" each of these motion segments with the interpreter state so certain information was known by motion but it is not exposed in a useful way. (It was originally for  GUI's).

The purpose of my code was to extend the state tags mechanism to include the radius and tangential heading and publish the available tags to a set of pins so the data can be used by anyone.

You can do some stuff in a hal component by saving the lastX and lastY positions (axis.L.pos-cmd) and  the current axis.x.pos-cmd and axis.y.pos-cmd.  motion.motion-type tells you if you are on an arc or a linear segment. Now you can do some trig calculations. If its linear you just need to calculate the slope of the line (angle) and you have the heading. If its an arc, you can calculate the radius, arc and then the tangent which is your heading. I tried this and never got reliable results.
Ref: linuxcnc.org/docs/devel/html/man/man9/motion.9.html 

Regardless of what AI thinks, there isn't a method to inject into the motion planner. Perhaps you can develop a kinematic  model of the tangential knife. linuxcnc.org/docs/devel/html/motion/kinematics.html
But I think the correct method which AI won't know anything  about is to work with state tags.

My thought was that there would be a component that took the heading and set the A axis angle with it.

Yesterday, I  made a start on merging the current 2.10 master branch into my 6 year old arc-radius branch but I have not committed it back to GitHub. github.com/rodw-au/linuxcnc/tree/arc-radius
There are 7 files that need manual intervention because of changes to the code base. I'm on my second attempt.....
 

juan13372k wrote:

... i bought the mill with glas scales and i like to implement them in the driver if possible?

No, but you can use them with LinuxCNC and leave the drives as they are.
You would need a Mesa 7i95T board as it has step/dir outputs and encoder inputs so the glass scales would be wired to those encoder inputs.
There are other combinations of Mesa boards, like 7i96S with 7i85 etc, but first make sure the glass scales can be wired to normal incremental encoder inputs.

You can use glass scales instead of the servo's encoder. BUT.
The driver must interface to the glass scales. And that is most likely the problem.
I'm guessing the glass scales uses incremental quadrature signal.
In the product listing it's mentioned 17-bit absolute encoder.
That's not the same and will not work.
You must check the capabilities of the drive, if it can accept incremental quadrature signal.
If it can do that, there is a big chance it will work.
Summary:
- Check interface of the glass scales
- Check that the drive can use that.
 

nobody