Advanced Search

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)

My mill uses a Jetway JNF9C motherboard, that I am starting to have problems with. This board has a n old-school PCI slot, in which I have a 5i23 card. 

I don't seem to be able to find a PCI slot mini-ITX board at a sensible price, so I thought I would try a PCIe-PCI adaptor. 
Specifically this one:  www.amazon.co.uk/dp/B0CHM91KJB

It almost seems to work, in that the 5i23 appears to be detected. But then fails with "/DONE not cleared...." (I can probably find a way to paste the exact output, but it's not straightforward as the motherboard is not on the network) 

Is there any point persisting with this, or should I just give up and buy a 6i24 to replace the 5i23? 
If so, which 6i24 do I need to run the somewhat special firmware (15 or 25)? (firmware=hm2/5i23/harrison.bit) Which is compatible with 7i49 and 7i39 boards (though I could drop the 7i49s as they are currently not in use) 

One issue is that I don't know which way round the 5i23 should be in the PCI slot, it's keyed to go both ways round.... (But if it is being detected then I guess it's probably right?)
 

Hi,

At this point we can use the clothoid_3d.so library with the scurve motion planner.
What looked like a mission impossible to me, is succeeded in a functional 3d clothoid library.

I brewed an idea how to integrate this chunk of software into linuxcnc's motion planner.
Because one clothoid fit takes ~25 servo cycles we have to use an old men's trick.

1. We put the clothoid fitting algo in a seperate thread.

2. We need to have a modified segment buffer, wich request new segments from the interpreter when at ~10 segments of the buffer end.
If we don't do this, the machine will pause in the program for a short while, when recieving a new gcode load. We must avoid this.
We have to look how linuxcnc behaves when giving us the very last segment of the program.
I hope it will not stop the program directly but wait's until we are ready.

3. I think also to create some kind of segment ringbuffer. Wich is usefull for motion reverse. And usefull to avoid gcode dump wait periods.

For info:
Julian has done work on a back-lash solution using scurve motion. This is scurve on top of scurve, wich works!

Hallo, 
Problem 1: gelöst 

Problem 2: teilweise gelöst
Frage: meine CPU hat nur zwei Kerne, muß ich dann im grub-customizer   "quiet isolcpus=1"  schreiben ?

Problem 4: gelöst 

Problem 3:  nicht gelöst 
   hat Niemend eine Idee warum der Watchdog mit QTdragon nicht funktioniert ?
wie ich oben schon geschrieben habe, Konfiguration erfolgt mit Stepconfig.
schalte ich auf Gmocappy funktioniert es, 
schalte ich um auf QTdragon funktioniert es nicht, sonst keine Änderungen 


(deepl translation)Hello,Problem 1: solved  Problem 2: partially solvedQuestion: my CPU has only two cores, do I have to write “quiet isolcpus=1” in the grub-customizer ? Problem 4: solved  Problem 3: not solved does nobody have an idea why the watchdog does not work with QTdragon ?as I wrote above, configuration is done with Stepconfig.I switch to Gmocappy and it works,if I switch to QTdragon it does not work, otherwise no changes

I bought some DM860H and DM556 drivers off Ebay and Aliexpress, respectively; they worked, but have no flyback diodes.

As PCW mentioned above, they do have flyback diodes for sure, but over voltage will destroy them as soon as powered on, and so will wrong polarity, or worst case, powering them with AC power directly from the transformer, that can happen with a miss wired bridge rectifier.
Was it you that had a blown capacitor in another topic?

So, any help on ethercat finding my drives would be nice. When i try twincat, it sees the drive but then it triggers a communication error. so something is set wrong somewhere.

That did not take long! ?
This makes it usable with Mesa boards and even parallel ports as they can easily count encoder signals

Normally on a 4 layer card you do not need top or bottom fills
unless for heat sinking or shielding. You do need to be a bit careful 
about the 3.3V/1.2V plane cut/bypass capacitors/supply inductance,
and some under FPGA filling of the VCC plane can help here.

The SPI clock will be the fussiest signal so if you are routing it
a long distance, it may need parallel termination at the end of the trace
(series termination does not work with two endpoints)