Advanced Search

A bit of a strange request. I'm looking at `gcode.parse(...)` the CPython extension function implemented by `gcodemodule.cc`. It is a blocking call from the Python caller's perspective: it initializes an interpreter, opens the file, executes init codes, then loops over `pinterp->read()` and `pinterp->execute()` until the file finishes, an interpreter error occurs, or a Python callback aborts.

I am trying to benchmark a few things and I was wondering if anyone knows of a repository of g-code files for testing?. Basically I'm looking for a small set of .ngc files: small known-good, medium CAM, large CAM, arc-heavy, and many-short-segment. I could create some, but I thought I'd ask if a set already existed.

To answer a few questions,

Tommy,
The soft limits work fine after the machine is homed. The crash into the hard limit happened before homing the machine while jogging from a long distance to get close to the home switch before homing.

This is a new pc bought just a few months ago for this refit.

NWE and Rod
It is an ordinary USB wired keyboard, and exhibits no signs of physical sticking keys, (other than this issue while jogging).

I'll try the xset -r, and report back. But the problem is intermittent, and may not act up for testing.

Hello Andypugh,

This modification was really helpful in last machine I made. I'm now trying to achieve similar but Linuxcnc has changed a alot. Also changed a lot in kinematics. I tried to modify kinematics as per this thread but as expected it's failing with errors.

I want to use XZ and B axis with TCP along with tool length probing. Setup in this thread is working in older version.. I'm struggling to getit worli with Debian 13 rt 2.9.8 Any help or suggestions would be appreciated,


Thanks

Hello Aceiera,

I'm also trying to achieve similar 4Axis TCP kinematics. I want to use Rotating spindle head and XZ gantry with fixed table. No B or C axis. I tried to compile 5Axiskins by removing C axis values but not accepting compilation. Any help would be appreciated.


Thanks

djdelorie wrote:

or if there's some magic to restore it only if the next move is anything other than a G0XnYn move (i.e. G1 or G0Zn)?

You could consider adding the required magic with a Gcode filter that is applied when files are opened...

I suspect the next thing (that causes intermitent latency spikes) is energy efficient Ethernet (EEE) disable it.
Also set the governor to performance.

Warxcell wrote:

MB: P5g41t-m lx
CPU: Intel Core2Duo E7600
Memory: 4GB Ram.

2 cores is not enough anymore. You need 4 cores, 8 gb might be better but 4 gb will work.

This sounds like an autorepeat issue I've experienced in the past.

To test if it is, open a terminal window, and enter the following command:



Launch LinuxCNC and jog around. If the problem goes away, that's the issue and we can come up with a more permanent solution.

To turn autorepeat back on:

Definitely 2.7.

Hallo zusammen, 

da ich aktuell etwas an meiner Maschine abändern möchte, muss ich mal wieder alles nachschlagen. War ja klar, dass ich mir nichts merken kann. Das wäre ja zu schön. Spaß beiseite. 

Mir ist aufgefallen, dass Google zwar viele Einträge hat, die Seiten aber nicht mehr existieren.
Z. B. bei der Suche nach „PyVCP”:
Ergebnis: linuxcnc.org/docs/devel/html/de/gui/pyvcp.html

Das ist mir nun schon öfter aufgefallen, daher wollte ich fragen, woran das liegt. Wird gerade viel umgebaut? 

Gruß
Mücke 
 

The manual for your drive (pages 27–28) shows that Digital Output 5 (pins 19–20) and Digital Output 6 (pins 21–22) are digital output pairs rated to switch loads up to 200 mA. Output 6 can be used to send a stop signal to your system, indicating that the drive has entered stop mode.If your goal is to feed an external E‑stop signal into the drive, you must wire that signal to  digital input IN1 (Servo Enable) as shown in the wiring diagram on page 26.The reference to “differential input” in the documentation is simply a translation error and can be disregarded.

MB: P5g41t-m lx
CPU: Intel Core2Duo E7600
Memory: 4GB Ram.

Thanks Rod!

I have done all that already except using dkms driver. It is an Intel NIC (e1000e) not realtek... Now time will show if it is fixed

With Z0 and Y0 both sitting on the center of rotation in CAM, the G52 Y correction only compensates for the actual clamping offset of the stock, and the orbit problem doesn't arise. The part isn't referencing a point on the stock that moves with it — it's referencing the fixed axis center.

I still fail to understand the point of probing and using an offset.  What exactly are you offsetting?

• If the actual CoR position is not known and you probe the part - you don't know how far to offset.
• If the actual CoR position is known and you probe the part, you know how much to offset, but
  • the CAM doesn't know how far you've offset, so features will be machined in relation to the CoR, but not to the stock position
  • In the case of a profile-type toolpath - depending on how far offset the stock is from actual CoR - you will need extra material on one side and risk taking an extra-heavy cut on the other

If you position the part mostly in-line with the actual CoR and program a bit of extra stock in CAM, you will never need to probe and you will never plow in to unexpected material.

Yeah, I didn't think there would be any magic, but I figured I'd ask. My files come from various sources so "do it in post" is not reliable enough unless EVERY post does a G0XY before any GZ.