Advanced Search

Wie zu erwatren ist ein Fehler aufgetreten  

Error
Kunena Internal Error: Please contact the site administrator to fix this issue!

 Ist eventuell etwas intern mitgeloggt worden? 

 

Some observations:

Lots of people are using USB to Modbus convertors to control spindle VFDs, and that works OK, (it's noticably notchy doing CSS on my lathe, though)

Jepler (long-time LInuxCNC dev, but now left the project) wrote this back in 2007:
emergent.unpythonic.net/01198594294

USB is definitely adequate for any HMI interaction, otjherwise gamers wouldn't be able to use USB keyboards. (I know that _some_ insist on PS2 for less latency, but most don't)

Have you tried an "fq" config (or "fqi"). That should use the Fanuc commutation for initial starting and then use the quadrature position from that point on.

Probably . I haven't tried it.

Dec 27 it looks like from github. Actually, the bug shouldn't affect you.
A negative refClockSyncCycles value should switch on the PLL and synchronize servo loop time with DC time.
You can always check the lcec.pll-* hal variables. If some of them move, it's on.
refClockSyncCycles is how often the master sends a synchronization signal to the slaves to compensate for clock drift.
I use 1000 because the slaves' DC clock run pretty accurate as it is. Many people use 1 as value.
I have not seen that any number is better than the other, maybe there is, but feel free to use any number you prefer.



 

Now as in just recently or in the patch from last year? or reaaally recently
Also, what does the refClockSyncCycles value do and is there any baseline on what to set it at?

There was a bug with "-1", fixed now but it sounds like you have it.
Use a positive value in refClockSyncCycles and set syncToRefClock="true"
and that should hopefully fix it.

I currently have refClockSyncCycles="-1" which according to the docs you linked above, means its enabled for backwards compatibility. Sadly, I have these mentioned issues where the axis starts clunking randomly (on a random axis) after some time. Its a fresh install from end of january. Does SyncToRefClock still need to be set?

Better yet, enable synchronization with syncToRefClock="true"
github.com/linuxcnc-ethercat/linuxcnc-et...s.md#master-settings

The refClockSyncCycles is how often to synchronize the clocks between the slaves
which is something different altogether, and doesn't help this problem.

Never mind. 

I was trying the entire weekend to make the drives work but still no success. Basically I started from scratch and cloned "linux-cia402" from RodW github page. Then executed "ethercat pdos" and the drives return PDO mapping 1701h and 1B01h. Next, following the manual and the mapping for 1701h and 1B01h, I wrote the .xml and .hal files. In the .xml file, I tried to set the data type for each pin as per the manual but the lcec components does not like s16, u16 and u8, anyway I changed them to s32. LinuxCNC opens and loads the configuration but when I try to home, a following error occurs.

In the terminal I observed a weird output when execute "ethercat pdos" after LinuxCNC has started - there is no names on the right of the PDOs, look at the attached pdos.txt file.

Also the synchronization error  and 1 datagram unmatached warning appeared again.

In the beginning of the .xml file I tried to set the PDO mapping using "sdoconfig" but it does not seem to help either.

Debug enabled, give it a try.

Okay, thank you.

I had already thought that the issue had something to do with packet loss when starting LinuxCNC.
However, this seems to occur during operation, which I have not yet experienced. If this work results in ethercat running more stably, I will simply wait until Sascha announces an official patch, which will likely be available via update.
Until then, I will simply stick with refClockSyncCycles="1">.

I got it working.

No feedback needed.
3 pins are used..

Forward
Backward
Pwm pulse

L298n cheap modul.

I clean up the component and then i make a small video und can share the code.

I use a 8 position toolchsnger from my emco 220 where i unmount the lightbarrier pcb.

How it works:

Start linuxcnc..
Then 1 time make movement over a button of the toolchanger.
Then look which tool is in position.
Then set toolnumber over buttons.

After this all is done over timing.
No motor noise!
No overheating!
No issues!

Rollover is handled.
The biggest problem was to find the correct timings and speeds.

The reason for the issue is that the dc motor has a planetary gear and the wormgear has small play.

You can setup:
How many toolslots you have
Time from slot to slot
Backward time
Backward locking time

Pwm for forward
Pwm for backward
Pwm for locking against the pawl

Advantage:
If you hit emergency off the toolchanger stops and resets

You can add reference signal to tool1
You can drive toolchanger from slot 2 slot over buttons.

You have pins where you csn see if you have rollover and the slots it must travel.

Its complete openloop and can setup over a hal or halpkns

@Finngineering: So you did not start a rewrite? I see it the same way. The actual component looks like a school book example of object oriented design, then it didn't suite the needs, took way more time then estimated and the needed redesign, simplification and finalizing never happened. But for a rewrite, the chances are high the same will happen and to get it to the functional state the actual module has, it will take a lot of time. So if it works now, fine. If there emerge unsolvable issues, we can think about it again.

I looked quickly into the xhc-hb04: is way less complex but it also has less functionality. I find this automatic change to manual quite nice. And the xhc-hb04 has a complex hal and config file which probably also makes it difficult to use.

@rodw: As I understand linuxcnc, before homing, you can only jog single axis due to the kinematics needs homing. But due to jogging Y1 separate from Y2 will bend the gantry, this is deactivated like in my machine using HOME_SEQUENCE. I don't need jogging before homing, so that's fine for me.
However, the WHB04B tries to activate jogging also before homing and then generating errors. For me, that's a non-issue, I just don't touch the wheel. And if it happens by accident, nothing else happens except an error messages.
For non-gantry machines, you can jog also before homing, so I did not remove that functionality because it might be useful for others.
An solution would be to add a command line option for this. However, I rather create some chips than continue coding...

Additionally, I started another rabbit hole which is more important for my machine:
github.com/LinuxCNC/linuxcnc/issues/3839

Just a note: Linuxcnc is just a hobby for me I started recently. But I have a lot of experience in coding and bug fixing from my day job and I figured fixing the issues I am having myself and creating PR's would give something back to the community.

It sounds like you get gravel in the servo motors from time to time.
Or you get click sounds from the motors. It repeats itself with a few or many minutes apart.
The first thing to do is to enable syncToRefClock and enable DC mode for the servos,
this will keep the servo loop in sync with the DC.

What grandixximo is doing here is fixing an effect that despite DC and servo loop are synchronized,
the two loops have been started with an undetermined/unfortunate phase between them.
The gravel sound is there all the time and it doesn't go away until linuxcnc is restarted.

Surprisingly, yesterday Sasha Ittner popped up in the PR log and mentioned he had been working
on a complete redesign of the DC system, eliminating all these problems (don't know details)
grandixximo seems to have reviewed that work and decided to adopt Sasha's work.
grandixximo will have to say himself. And if you don't know, Sasha Ittner is the author of linuxcnc-ethercat
from many (>10) years ago.