Advanced Search

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

langdons wrote:

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.

Yes, that one is completely down, while this one is still up
wiki.linuxcnc.org/cgi-bin/wiki.pl
and the page you requested
wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_Supported_Hardware

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)

thanks i will give this a try tonight.
i did not know ther was a "qtvcp copy" tool
i duplacated the directory and replaced the ui fie and renamed one ot two others.
that obiously did not work.
thanks for your help.

All modern step motor drives have flyback diodes, what they typically do not have is an overvoltage clamp.
This means you must never switch the DC power to the drives anywhere between the power supplies output
capacitor and the drive itself. This means no switches/relays/fuses/circuits breakers in the DC circuit. The
fuse in the  drive itself is just for fire protection, if it blows, the drive was already dead.

I am repairing a CNC machine at my high school.

It has toroidal trasformer with 3 isolated 28.5VAC windings.

It is a 3 axis XYZ machine with each axis controlled by a 4.6A stepping/synchronous motor.

It is connected to a PC running LinuxCNC via a parallelport and PMDX-122 breakout board.

The machine works, but the original 30-year-old stepper drivers are all totally broken.

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

I accidentally broke all of them.

I ordered 1 new DM860 from Aliexpress.

Should I just suck it up and buy good, genuine drives for the remaining axes?

All the axes?

I can make a rectifier, if needed.

What brands are good?

I am reluctant to spend like $300 ($435 in Canada, where both the machine and I reside).

Canada's potential future retaliatory tarrifs on USA in response to Trump's potential future tarrifs on Canada might affect stuff too.

The computer works fine, so does everything else, all I need is stepper drivers at this point (I need 1-2 THK LM guides for th Z axis, but that's a problem for future me).

Hi all,

I worked on the sensorless homing this week-end and it seems to work, at least on a single axis. I uploaded this video where you can see it in action. The code is a mess so I didn't upload it on github yet, and will first try it on a gantry system before publishing it. I also tried to connect a ABN magnetic encoder (AS5047P) directly on the TMC5160; I can read the encoder position through the X_ENC register and use it as feedback for LinuxCNC, as expected.

I'm not sure what next step will be; probably clean up the code a little and publish a "main" branch. I'd also like to try a Pi Zero 2 version without a GUI, actually without X-Server at all if that's possible, to see if this could be an option for OpenPNP users as a cheap yet powerfull motion controller.