Advanced Search

So, es läuft jetzt, vielen Dank Aciera, ist genauso wie ich es haben wollte, alle 2 min einen Intervall ohne viel drumherum.

Die Verknüpfungen haben mir das Leben noch etwas schwer gemacht, den interval.enable habe ich mit machine-is-enabled verknüpft, ging problemlos.

Beim interval.out kam immer der Fehler, dass der Pin nicht vorhanden ist, letztendlich habe ich Hilfe von Sven die Verknüpfungen in die Postgui_call_list geschrieben, damit ging das dann auch.

In LinuxCNC 2.8x läuft das ganze wenn man in der Interval.py aus python3 python macht.


Grüsse
Steffen


 

Yeah, that's what I though, the direction signal going to 0 at every step is dubious at best. Especially looking at your older posts which clearly show a logic analyser graph with the expected step dir behavior.

I made a short video so we can all better understand what's happening, would you mind taking a look ?

(Keep in mind, these are differential signal, the dir pulse is not going in the other direction between step pulse, it's just going to the mid point, 0v)

Thanks, that works perfectly!

Yes it seems I have mistakenly used qtpy instead of PyQt6, and so needs qtpy installed. I'll align with flexgui on QT6.

Are you sure the blue trace is the Dir pin. It should only change from high to low on a direction change. I doubt you are changing direction every step pulse.

The LinuxCNC component does not control the setup and hold times. This is done in the firmware.

hi
will this version from your repository control an real machine with ethercat servos?
it already works with linuxcnc 2.9.3, its a cutting machine with XYA axis, A is tangential to the path. today it has very jerky moves as linuxcnc doesnt blend rotary axis. i would like to test the blend features you developed. in the previous videos there was an tool direction that i could use to control the tangencial axis, is this avaliable in this version?

Strange enough is the value of #5070 probe fail/succeed passes each time with a one(1) succeed.

#5070 returns '1' if the probe succeeds which seems to be case. Looking at the 3 screenshots indicates that the actual probing works fine as the resulting 'calculated offset' values are very close.

Seems to me that the problem is somewhere after the actual probing has taken place.

[edit]
I wonder from where in the code this comes from:
'Return to original tool-tip position using new z-offset: ...'

Looking at the oscilloscope I found out that my timing is wrong.
There isn't any Dir Hold or Dir Setup in my signal as is required by my drivers.
(Yellow: Step pin  Blue: Dir pin)

Following Scott's post I edited and uploaded my config.txt
Unfortunately, looking at the scope, there still isn't any Dir Hold or Dir Setup in my signal !


I made sure my config was updating properly by changing the timing and looking at the scope, which it does.
I made sure the dir signal was wired correctly to the scope by moving the axis back and forth, which it is.
I reinstalled remora ethernet component by downloading the repo and doing sudo halcompile --install remora-eth-3.0.c inside Remora-RT1052-cpp-main/LinuxCNC/components/Remora-eth/

Is there a bug, did I overlook something ?

The limit will likely be the rate at which steps can be generated by the parallel port

If you set the stepgen velocity with RPM and you have 800 steps/turn the step scale should
be 800/60 = 13.3333.  With a 55 usec base period and 800 steps per turn, this limits you to 1350 RPM