Advanced Search

Pretty sure this was mentioned in the Remora topic/thread, but searching through it might take a while.

The issue is the 5.835 ms maximum ping time (about 10X the usable maximum)

My guess is that you have a RealTek Ethernet interface on you PC which requires
and alternate driver (DKMS) be installed since the driver supplied with the 6.1 kernel has
real-time issues.

Instructions for this are in this thread:

forum.linuxcnc.org/27-driver-boards/5366...xcnc?start=20#310794

Before you do that is probably best to determine the actual Ethernet hardware with say:

lspci | grep -i ether



 

I need help because I don't know what to do with my PC.
At the moment linuxcnc displays ‘hm2 error finishing read’ every time I change the tool on my turret on my cnc lathe.
several weeks ago I had this message sometime.

below the latency of my pc and the ping for the ethernet.
 

I have disabled all the options that slow down latency in the bios/uefi.
I have followed the procedure to isolate a core for linuxcnc. and other procedure to reduce latency (IRQ affinity scripts / rt_setup).

but i have the problem ‘hm2 error finishing read’, is there any solution to remove this problem or the only solution is to replace the pc because nothing can be done?
 

Hi - I'm brand new to LinuxCNC forum/ forums in general so I apologize if I'm doing something wrong.

But I am having this issue where my stepper motors are clicking after jogging and they are at idle. It doesn't happen all the time but enough that its concerning. I suspect that its because the motors are very oscillating about the set value but I'm not entirely sure. I've had this issue ever since I switched over to a flexihal rpi remora system. I think my issues are within my HAl and INI files since I didn't have this when I was using just he a parallel port - see attached.

I've tried a few troubleshooting steps but nothing completely eliminated the clicking
- P_gain to 1000 (1/servo and it made it worse)
- Deadband to follow linuxcnc.org/docs/html/config/ini-config.html
- Min_ferror to various values

The original hal and INI files where taken from the remora-flexi github: 
github.com/Expatria-Technologies/remora-flexi-hal

[EDIT]
Some more details incase it helps, my build is a very standard PrintNC V3 if that matters at all. The steppers and drivers are all the standard ones that comes with the kit/ is recommended.

Any advice would help greatly
Thanks!

Find a low PPM encoder or build one, or get a Mesa board like 7i96S.
I would not trust an arrduino sending feedback through USB for threading.

It works, no doubt about it, just takes a bit of work and care, and some better cables.
See
forum.linuxcnc.org/plasma-laser/36734-le...ring-and-emi?start=0
forum.linuxcnc.org/49-basic-configuratio...works?start=30#56014
And
forum.linuxcnc.org/plasma-laser/38974-di...rything-in-one-place

Awesome, do RST and INT bring any benefits ? I saw they were marked as optional.

Could you integrate a tooltip on the GUI? That way I could add some more text and documentation. Really phenomenal. New W5500 arrived yesterday, hope I get around testing them soon.

PCW wrote:

Unexpected realtime delay on task 0 with period 25597

Is this a parallel port setup? (25597 sounds like a parallel port base thread time)

EDIT I see this is a 7I96S configuration but the 25597 thread period makes no sense
in that setup.

 

PCW already mentioned the issue, you have to fix it in your ini file, set the "servo period" to 1000000 ( 1 million), save and start the config again.

Hello,

maybe this link is useful.
www.diycncdesign.com/linuxcnc-2.8-huanyang-vfd.html

Best regards, Frank

set und reset funktionieren unabhängig von data und clk (ie wie ein RS typ).

Gute Idee.
Jetzt interessiert mich da, ob der CLOCK optional ist (SR-Flipflop) oder der immer gebraucht wird?

I hate to be another VFD post, but Haven't cracked this yet. I had a VFD that just worked as it should. USB converter, hy_vfd hal component.
I needed a new spindle, so hooked everything up and expected it should work . Of course it did not. I have double checked the registers for COMMs as well as baud rate.
The VFD says it is a H100 Series VFD. All the registers seem to be the same as the other. Honestly I just don't know where to go troubleshooting this. When I load from halrun, then setp vfd.enable 1 I just geet comm error (-12)

Does this mean there is no response or the response is not correct?

So you think the j1 pin 2 serves a different purpose?

I don't know, but since the original system used J2 pins 1,2
I would use them.

Does it support BTT SKR PRO V1.2?Should I edit the source code and recompile the firmware for it or just use  BTT_407?BTT SKR PRO V1.2's MCU is STM32F407ZGT6 teamgloomy.github.io/skr_pro_1.2_pins_3_5.html

---

I tried to add BTT SKR PRO V1.2 to the custom_targets.json, mbed_app.json and edit main.cpp.After compiling it, I got the fiemware.bin.I wll test it when my RPI is delivered.

 

Well, I implemented HeadHeadTCP mode.

I modified xyzbc-trt kinematics .c file and made my kins.c file(attached)

Used sudo halcompile --install command.

However, more importantly, I played with this file for some time and understood the concept how kinematics actually works. I am describing my realisation below. In case I made some thing wrong, corrections are welcome.

The kinematics works as follows:
Actually there are two components, Forward kinematics and Inverse kinematics.

Without going in deep into theory of the above, what I understood during implementation,  is that in Inverse kinematics, we give command to the joints to follow a particular geometry by, of course, mathematical (in most cases trigonometric) formula in addition to the G-code command.

For example, in my Head-Head tilting type machine i.e my cutting nozzle/spindle is on A and B rotating axes. So taking Lt as the pivot length, if A axis rotate by ’thA’ radian (or degree for simple understanding), the Z axis must compensate and more specifically shall move to Z- to maintain the tip point height by Lt*cos(thA). Similarly X axis shall move by Lt*sin(thA).

Note that, cos(thA) is positive within 0~90 degree irrespective of thA positive or negative. Hence, if A axis rotates in either direction, Z moves down. And similarly for X axis, if A is positive, X moves positive and vice versa and tool tip is at fix point. This is simple trigonometry.
Same for B axis rotation. In that case, Z and Y axis moves.

Now, in the DRO reading on gmoccapy/axis gui, X, Y and Z movement is not shown if we rotate A and/or B, although the motor rotates physically and machine moves. This is done by the Forward kinematics. That is why the equation is forward kinematics is exactly opposite to inverse kinematics.

If you remove the forward kinematics corrections, for testing purpose only, you find the DRO in GUI show the X, Y and Z movements. But in TCP mode that is not our intention, hence we forcefully neglect such movement in DRO by forward kinematics.

Hope this will help in understanding of ‘how the kinematics work’ and ‘what kinematics do’ sort of question that myself had in my mind for a long time.