Advanced Search

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

 

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 

Thanks for this. I have added the debounce function but it didn't didn't fix the problem. I am going to keep it as it looks like a good practice.

I don't have the settings you have in the ini file. However, the probe screen I am using has a separate file, "probe_screen.pref", where it keeps the preferences. Nothing seems to be missing.

I have checked the input signal in Halshow, and I can see the signal is going ON on the first approach at search velocity, but I don't see a second signal at probing velocity. The program just concludes the measurement and uses the value from the search velocity.

I am starting to think it is some kind of bug in a macro, but if that is the case, I am sure others would experience it as well.

I am using the probe screen v2.9 from this git repository:
github.com/verser-git/probe_screen_v2.9

Here are my settings for the probe screen and a macro to measure X- position (I hope it is the correct one). Perhaps someone can spot what is wrong:

####Config file#####

[DEFAULT]
chk_signal_delay = False
ps_signal_delay = 1.5
chk_use_fine = False
chk_error_signal = False
chk_auto_rott = False
ps_offs_angle = 0.0
chk_set_zero = False
chk_arm_enable = False
enbl_remap_m6 = True
ps_metric_mode = True
ps_searchvel = 100.0
ps_probevel = 10.0
ps_z_clearance = 4.0
ps_probe_max = 15.0
ps_probe_latch = 10.0
ps_probe_diam = 1.915
ps_xy_clearance = 5.0
ps_edge_length = 5.0
ps_offs_x = 0.07874015748031495
ps_offs_y = 0.079
ps_offs_z = 19.38
ps_arm_delta_x = 0.0
ps_arm_delta_y = 0.0
setterheight = -23.7225
blockheight = -71.445

#### Example Macro ####

o<psng_xminus> sub

; BEGIN PSNG PREAMBLE
M73 ; Save and autorestore model states. This will be used only in case of error, otherwise we will invalidate it.
o<_psng_modal_save> call
o<_psng_hook> call [6]
; END PSNG PREAMBLE

; Save starting X position
#<x>=#<_x>

; Ensure we're in G90 / absolute mode
G90

; Probe X Minus
o<_psng_probe_x> call [-#<_hal[probe.ps_probe_max]>]
O1 if [#<_value> EQ -1]
M72 ; Restore modal state
(ABORT, Probe already tripped when starting G38.3 move)
O1 else if [#<_value> EQ -2]
M72 ; Restore modal state
(ABORT, Probe failed to make contact with workpiece)
O1 else if [#<_value> EQ -3]
M72 ; Restore modal state
(ABORT, Probe failed to make contact without ERR signal)
O1 endif

; Move back to starting X position
G1 X#<x> F#<_ini[TOOLSENSOR]RAPID_SPEED>

; BEGIN PSNG POSTAMBLE
M71 ; Invalidate Modal Autorestore
o<_psng_modal_restore> call
; END PSNG POSTAMBLE

o<psng_xminus> endsub
M2

If you look at the diagnostic outputs using "sudo dmesg" on the two systems, does that give a clue to what can be the issue?
EtherCAT master puts out some info there.

The card would not be detected if in backwards
(Though the power supply pins might cause some issues)

I can just send you  6I24-16

(The -16 is big enough for any LinuxCNC config)