Advanced Search

I did only what the instructions said up to the point of typing ethercat slaves.

Quick update and correction.

It seems that changing the Makefile.inc isn't necessary as it gets rebuilt as part of the run.

So looking at ./debian/configure I see the option for no documents is 'no-docs' and this works.

./debian/configure no-docs
dpkg-buildpackage -b -uc

-b option doesn't seem to matter.

I'll do some more digging into the fortify issue to see if I can find a better solution and to understand the DEBUG question lingering in my miind.

Cheers

Link down. Did you customize /etc/ethercat.conf ?

from ethercat master.... seems maybe its not working at the network card level. What did i break? haha

Master0
Phase: Waiting for device(s)...
Active: no
Slaves: 0
Ethernet devices:
Main: 00:23:24:3e:1b:ba (waiting...)
Link: DOWN
Tx frames: 0
Tx bytes: 0
Rx frames: 0
Rx bytes: 0
Tx errors: 0
Tx frame rate [1/s]: 0 0 0
Tx rate [KByte/s]: 0.0 0.0 0.0
Rx frame rate [1/s]: 0 0 0
Rx rate [KByte/s]: 0.0 0.0 0.0
Common:
Tx frames: 0
Tx bytes: 0
Rx frames: 0
Rx bytes: 0
Lost frames: 0
Tx frame rate [1/s]: 0 0 0
Tx rate [KByte/s]: 0.0 0.0 0.0
Rx frame rate [1/s]: 0 0 0
Rx rate [KByte/s]: 0.0 0.0 0.0
Loss rate [1/s]: 0 0 0
Frame loss [%]: 0.0 0.0 0.0
Distributed clocks:
Reference clock: None
DC reference time: 0
Application time: 0
2000-01-01 00:00:00.000000000

Try

So, I installed linuxcnc fresh, then began the ethercat install per instruction thread. It *seems* to have worked, but there are no slaves displayed when I type ethercat slaves...

So, for sanity I went into twincat, and it DOES scan the servo drives, however it triggers a communication error of wrong data type. I wonder if the 2 are related and something is set wrong on the drives.

Servos drives are omron R88D

Any thoughts on what may be wrong here?

Glad you got it. I'm using Basic Probe with QTDragon_HD. There is also Probe_Basic and Versa Probe which I think is what you are using. It looks like you are using the GMOCCAPY UI.

All standard MOSFETs have inherent "body" diodes which will function as flybacks
though typically Schottky diodes are added to reduce voltage drop and hence power
dissipation.

Found it! And at the end, it was a simple option to tick. 
While I was analysing the macro, I came across this lovely if statement:

;Check for refinement measurement
O7 if [#<_hal[probe.chk_use_fine]> GT 0]

And after checking the screen, here it is: "Use refinement measurement". After checking the option, there is a second probing action at probing velocity. Problem solved!


 

I am having the same problem with "Radius to end of arc differs from radius to start" with a +90% error rate, using the fusion 360 post. I am able to post out some parts that will run and some that dont. All of theese have previosly been run with no issues on a Mach3 plasma with the same cut settings. Files 1001 and 1005 runs fine. But not 1002 and 1006? Any idea on how to fix this?
 

OK, I think I now understand how the macros are structured. Here is the main macro responsible for probing. I am now trying to understand it and debug it. Any help is much appreciated

 

The DM860H drivers have their own rectifier.

They accept AC.

No blown cap.

Also, one DM860H managed to work fine after the fuse blew.

They really don't have any flyback diodes, I assure you.

And the transistors ain't DMOS either.

So I found a quick fix for the _FORTIFY_SOURCE errors which is ok specifically for me at least to now but not a good fix for the project.

In the src directory is Makefile line 255:
original line DEBUG := $(DEBUG) -g -Wall -D_FORTIFY_SOURCE=2
modified line DEBUG := $(DEBUG) -g -Wall

in the Makefile.inc file line 114:
original line CPPFLAGS = -Wdate-time -D_FORTIFY_SOURCE=3
modified line CPPFLAGS = -Wdate-time

As I mentioned, this would not be an acceptable fix for generalized distribution as buffer overruns and other security features provided by _FORTIFY_SOURCE are important. It does however get me going for now just fine.

Now I'll dig into the manpage issue with "\S" and see if I can find a workaround for that. Documentation is always a good thing to have.

Thanks to all for help and suggestions.

Hallo Fraes Paul,

zu 2
bin ebenfalls nur Anfänger in dem Thema habe die letzten Wochen aber einige Zeit mit dem Thema Latenz verbracht. 
Vermutlich kennst du die Latenz Videos von TooTall18T?

Hast du deinen Latenz Test unter Last gemacht? Video im Hintergrund, ein paar drehende Zahnräder (glxgears), Fenstergröße mit der Maus langsam ändern, ...
das hatte bei mir einen relativ großen Einfluss im Sinne von schlechteren Latenzwerten.

Mit den Hinweisen aus den Videos habe ich die Latenz deutlich verbessern können aber leider kommt immer noch ab und an die Watchdog Meldung 

Grüße Erwin