Advanced Search

I see from other posts that with intel network card I should disable IRQ coalescing. I will try that in the morning and repeat the ping test

I like the way you think my friend, I've tried that several times already with the same result. I have a Meanwell power supply that i fine tuned with my Fluke to exactly 5V I really think i have a bad card. I have never not once been able to get any actual motion control out of this thing. Now i need to navigate the seemingly unreachable Mesa company and see if they can help me. I e-mailed them a couple of days ago with no responce. Looks like this is going to drag on into eternity.

How can I get the X & Y values of the Tool Sensor Location from Settings tab in QTDragon_HD from with remap.pyThis code below works when getting the values from the .ini file but I would rather use the values from QTDragon’s screen.self.execute("G53 G0 X[#<_ini[TOOLSENSOR]X>] Y[#<_ini[TOOLSENSOR]Y>]")

Thank You.

force over switches installed and ready for wiring signal wires to the DB37 connector
 

I think 2.8 on Wheezy should work. The issue is Python 2.7 was deprecated from Debian Bullseye and on so the new Debian versions use Python 3

I have the same issue. I tried to rotate the G54 coordinate system slightly to account for a slightly misaligned part fixture. However, the G10 L2 P1 R1 command moved the origin around like described above. I would assume the coordinate system would be rotated around the origin of the respective coordinate system, thus not moving the origin. I could manually set the origin in the rotated coordinate system and then preview and movement of the machine were like expected.

Moreover, the G53 commands used during toolchange operations do not work anymore since LinuxCNC is throwing an error that limits are violated. I would assume the G53 is not affected by rotation of the coordinate system since it is machine coordinates?

I am using LinuxCNC 1.8.4. I would be very happy if someone could check this on a more current version of LinuxCNC since it might have been fixed already.

I know probe_basic and Qtdragon have their own probing procedures including rotating the part coordinate systems. Is this working or affected by this?

I heard a whisper the devs wanted to implement hal pins as 64 bit values with the next release (when  2.10 replaces 2.9)