Advanced Search

I used it and it worked perfectly with your instructions!!!

Hello,
My system is:
- LCNC 2.9.3, Debian 6.1.0-22-rt-amd64
- EtherCAT AC servo
- Everything is ok: homing, moving each axis separately, ...

When I run G-code, I have strange error: "Linear move on line xxx would exceed C's positive/negative limit".
I remember that it was ok with LCNC 2.9.2, but I have trouble with LCNC 2.9.3
I did big number of MIN & MAX Limit, but could not run G-Code.
Any advise ?. Thank you.
 
 
 
 

 

I think you are doing it the hard way.... Use the linuxcnc iso and follow the sticky...

I shared this script for when the ethercat repo needs reinstalling
forum.linuxcnc.org/ethercat/53785-instal...thercat-repositories

PhilipME,

Are you using a vanilla Debian install from their website? If so, LinuxCNC is not installed by default so you should be safe to proceed and skip that step.

If LinuxCNC is already installed (not run-in-place) then I'm not sure what's going on.

If you're ONLY using run-in-place, you can also skip the purge command as well, but do not try to use the run-in-place instance as it will not work with RTAI unless you've built it against the RTAI kernel debs that are listed in the first post of this thread.

  So far the building of the machine was all much easier than I expected.
But welding the water table is a big challenge.
Since I could not find a peace of sheet metal l large enough it is all warping up. And as it is now it is not usable. I would appreciate any advice on how to get those sheets straight again.

 

Thanks this helps a lot now the entering of data like set offs etc goes much faster.
I must say this is now a very usable Software.

A 97% error seems quite large.
Does the PP output the I & J values as absolute or incremental distances? The LinuxCNC default is incremental.
linuxcnc.org/docs/devel/html/gcode/g-cod...ml#gcode:g90.1-g91.1
 

Thanks, got rid of that error but now there is another one.
Operator error:
G-code error
Radius to end of arc differs from radius to start:
rel_err=97.5794%
I have attached the error.
I have found a lot about this on linuxcnc forums and the solution given is to change the tolerance in linuxcnc:2.4. [RS274NGC] Section n 
It says to add it in the ini file. I can't find where this is meant to go. I tried adding it but it didn't work. I couldn't find this center arc radius tolerance in any of my config files. I tried increasing the accuracy on the cam side but it didn't change anything.

 

Yes you are correct.
Things that can cause sudden latency spikes are, in order:
-CPU overheating and throttling down
-failing power supply
-failing motherboard capacitors
-failing hard drive (as Todd mentioned)
-failing memory modules
-
To check temperatures and sometimes voltages, in a terminal
sensors
while LinuxCNC is running
In case the spikes are at exact intervals, say every 5 or 15 or 30 or 60 minutes, USB devices that can not go into sleep mode when requested by the PC, usually WiFi or bluetooth or cameras. Use the latency-plot if you suspect this might be the cause.

Well, one thing I want to understand i.e latency spike is solely due to computer hardware failure and not due to communication failure with mesa card, am I correct?

Hi,

There are 2 identical cheap Chinese PCI parallel port cards, maybe problematic, I can't judge that.
All I know is that they worked under LinuxCNC 2.7, so why not from version 2.8 onwards.
Of course I also get the addresses of the ports using lspci -v.

I entered these values ​​into the *.hal file, but nothing happened.

Since I want the ports to be active when the PC boots up instead of when LinuxCNC starts,
I decided to enter the configuration of these in any existing *.conf file in the etc/modprobe.d directory.
This is easy to do, the "*.hal" remains untouched, which is what I personally prefer.

lspci -v is an important command, it provides data, but only shows the presence of the computer components,
not whether they are sufficiently configured.

Whether it was due to the "problematic" PCI cards or the swapping of the kernel,
the problem was that the module for the parallel ports was not loaded in the kernel.

lsmod provides information about which modules are loaded, "parport_pc" was not there.

I don't know if there is a simpler or even the right solution,
it works for me and maybe it will help others with the same problem.

Remedy: sudo nano /etc/modules-load.d/modules.conf

Entry: parport_pc
 
Reboot system

RDA wrote:

tommylight wrote:

I do not have any torch with shield, so i can not test although i do have 2 of THCAD for now.

 
I assume you mean that the tip ”sticks out” from the torch? You could always wire the sensing between the tip and work.

I have my 30XP setup like that but I use a cheap solid state relay rather than a THCAD.

in fact it is absolutely not needed if you are using absolute encoders

as I understand it, the documentation suggests using QEI Encoder, but I didn't find this module anywhere in the rt1052 cpp sources, is there a non-quadrature encoder in rt1052 cpp? and if possible an example of a txt file