Advanced Search

I'm getting the feeling that Rob Ellenberg's spindle synch updates/re-writes were never incorporated in to LCNC mainstream.

www.mail-archive.com/emc-developers@list...ge.net/msg16956.html

 

radom wrote:

will that get somewhere marked as a bug/something to improve in the future or will be forgotten in a week's time?

I'm interested, and despite my utter lack of programming knowledge I've been poking around on github looking for anything obvious.

My inexpert opinion is that a thread start point that varies with spindle speed is a bug - not expected behavior - at least according to the user manual:

G76:G33:
So according to the the user manual author(s)' expectation, the start point should be a calculated position with compensation for spindle speed and axis accel/maxvel values.

I did find that the section of trajectory planner file (tp.c) Chris posted earlier was edited a few times in 2009.  I've no idea whether the change(s) have any affect on the situation at hand.

I see that there is an open Issue on GH - 8 years old? - that may have something to do with this, as well as some more recent (possible) resolutions:

github.com/LinuxCNC/linuxcnc/issues/167

github.com/LinuxCNC/linuxcnc/pull/479

github.com/LinuxCNC/linuxcnc/pull/581/commits

I can't tell if #581 fixed, broke, or had nothing to do with spindle synch/threading start point calcs.

I think more testing is in order.

First, I'd like to see if G33 behaves the same as G76 does.

Second, I'd like to see if the thread start point varies by a predictable amount depending on

• spindle speed
• encoder resolution
• axis max accel
• thread pitch

If the offset is predictable, that suggests to me that position math is being done... but some programming is wrong.  If the offset is not predictable,  then my guess is that position is not being calculated per the G33 user manual section.

I'm sure some of the folks reading this can review files like tp.c and understand the behavior, but I can't.  What I can do is poke around and see if something obvious crops us.

I've got a fairly high-res encoder on my project lathe, as well as fairly 'dynamic' Z-axis accel.  I'll try to run some basic G76 and G33 tests this weekend and report back whatever I find.  Maybe with a high enough encoder res and accel values, this is a non-issue... and below some set of values the underlying problem makes a (negatively) meaningful difference in threading results.
 

It is possible to solve the problem related to distance and speed by using a spi to lan converter similar to the module below
And it had a real time component
www.amazon.com/HiLetgo-Ethernet-Network-...Z820io/dp/B08KXM8TKJ

Hello cornholio,

Sorry for asking questions bass-ackwards.

I have the need to build a real boat but honestly I don't want to cut it out by hand so, I have been thinking of building a CNC machine.

Doing some research I found and looked at LinuxCNC for part of the software chain but the references I saw were pretty negative (see a citation below from Google). I was not sure of the veracity of the citation(s) but I really want to pursue the CNC route so I really needed LinuxCNC.

I looked at the forum and it seemed there have been persistent problems with Pi 5. Given my background I offered my help getting it to be more stable (forum.linuxcnc.org/9-installing-linuxcnc...dux?start=260#317739).

So I really like the time I do Linux and driver/kernel work and, I really want to build a boat and I would love to help here.

Tom

----

From Googling "linuxcnc reviews and complaints":

Reviews of LinuxCNC often highlight its powerful customization capabilities and open-source nature, but also point to a steep learning curve, potential instability issues, and the need for significant technical knowledge to properly configure and troubleshoot, especially when compared to commercial CNC controls; many users report frustration with the complexity of setting up a reliable system, especially for beginners, and concerns about real-time performance depending on the hardware used. 

quelle lecteur vous parlez ! servodrive ? exe805 ? desolé je ne veux pas me tromper.

OK, again, drive enable must be controlled by LinuxCNC, and they are not controlled by it in your config.
See the drive manual, find what pin is drive enable, wire that pin to Mesa 7i77 output (disconnect from whatever it is connected now), then in hal/config add that physical output as net machine-is-on or net machine-is-enabled

Same here.

I've cooked up a bunch of m-codes for my in-progress lathe and I had to do a remap for any >199.

So 100-199 are 'normal' M-codes in an "MCODES" folder, and 200+ are mNNN.ngc files in a "subroutines" folder.

Thanks for the feedback. I have a Mesa 6i25 card with a 7i77 I don't understand. The activation must be controlled by Linux Cc The power-up is not managed by L. Linux CNC, but the activation of the axes is done by itself. I can interpret an entire program despite the small defect on the Y axis I attach a video and the ini and hal file. Thanks for your help.

Yes, I’ve also been encountering this type of error while adding custom logic in the INI file for my double Z CNC machine. I experienced the "out of range M-code" issue when working with higher M-codes. To resolve it, I attempted remapping the M428 code to T in the configuration file, which seemed to help in certain cases. It might be related to how the M-codes are being interpreted by the machine’s controller, so adjusting the logic or reassigning the codes can sometimes fix the problem. Has anyone else had success with a similar approach or found a better solution?

 

bonjour 
des personnes sur bordeaux et allentours pour échangés ,partagés discuté  sur linuxcnc avec une bière ?

Hello,
I upgraded my router from 2.7.15 to 2.9.3 and found out that jogging acceleration limits from XHC-HB04 config are no longer applied to keyboard jogs. MPG jogs are limited by new pins jog-accel-fraction for joints and for axes, tho. I have read a comment to a commit that introduces this change and it confirms, that keyboard jog accelerations are no longer limited. The thing is, that my machine's max accelerations are too scary to be used in manual jogging moves, and I would like to limit them as it was in 2.7.15. 
I did not found any other way to limit the keyboard jogging accelerations other than bringing back the old deprecated mpg-accel script functionality, that muxed the accel values to ini component during jog.
Any thoughts if this could be achieved in other way?
Thank for all feedback.

My setup: (Axis screen, simple servo with stepper outputs to servo drivers from 5i25/7i76 combo)










 

OK, I found it.
/usr/lib/python3/dist-packages/qtvcp/widgets/probe_routines.py, line 698f:
So, it seems that XY TRAVEL needs to be bigger than 2x LENGTH - LATCH RTN.

Setting XY TRAVEL to 15 and LENGTH to 2 (metric) worked for me.

Choosing the right parameters seems tricky to me. Preferably XY TRAVEL should be small, but OTOH I would like to be able to probe larger hole diameters than a few millimeters.

Hello,

You can connect the output of the encoder to 1 input of the Spindelspeed

i do not know witch pannel you use, i am using GMOCAPY

there i have addid following rul in de post gui hal file

net CPenc-01 => gmoccapy.spindle.spindle-override.counts
i think trher is a same art pin in Axis

will that get somewhere marked as a bug/something to improve in the future or will be forgotten in a week's time?

BSOD on the video I see your shaft is moving on motor side. Tighten your motor - ball screw coupler.

Oh you did it on purpose. My ADHD kicked too fast .

I would check if your timings are properly set in remora config.txt for your driver. You can check my repo since I use similar one DM556T.
I would limit velocity and acceleration on all axis to small one like 10mm/s, reduce microstepping, and increase amperage rating. Basically make everything easy to decrease amount of reasons that it can fail.

Sometimes I get similar sound when the position is oscilating, but that's usually when it flips between two microsteps.
Does the grinding sound keep going when you home that axis?

Also ensure that your logic voltage level is set correctly on DM556 driver if it have switches for that. I know newer DM556T have one.