Advanced Search

Thank you very much. Homing works just the way I want it now.

I agree completely about naming -- it's very important. I didn't realize HOME_OFFSET was an absolute location until I got this working -- the word "offset" implies "delta" to me, not "location".  

As for the sign of HOME_SEARCH_VEL and HOME_LATCH_VEL, I've decided to try them with different signs, to eliminate the backoff step, as you suggest.  There may be (probably is) a difference between where the switch closes and where it opens, but for my mill I'm sure it won't matter, for homing purposes.

My final X config is this.  Y is identical, except HOME is 0, not 6, to keep the bed at maximum extension toward me.

Hello gentlemen !

Im a Newby and want to run a CNC-mill with a Mesa 7i76E and a Rpi 5.
I have  read the thread and think a RPI 5  with 8 GB will be  the right choice for
bookworm and the mesa. The 16 GB RPI5  won't work or is there any kind of news ?
The freason for the question is that i have to buy a RPI but which one is the best opinion and why ?
Can you help me ?

Thanks   a lot
Ultrakurz
 

Hey,

da ich nicht so oft mit dem Linux Rechner arbeite fällt mir so etwas nicht immer sofort auf.Allerdings habe ich den Eindruck, dass auf dem Rechner einiges nicht mehr stimmt, da auch der Firefox auf einmal in Englisch ist. und ich ihn nicht umgestellt bekommen habe, ohne ihn zu deinstallieren und neu zu installieren. jedoch funktioniert das System im Moment und ich hoffe, dass das auch so bleibt, ich habe keine Lust schon wieder das System neu aufzusetzen, da das echt viel Arbeit für mich ist, da ich nicht weiß, was ich wie machen soll.

VG Mücke

It could be a wiring/noise issue but typically this is because of the relatively
instantaneous velocity estimation (typically updated every ms), which tends
to accentuate the encoder inaccuracies. This fast update is important if a feedback
loop is used but a nuisance for a human readable display.

The way this is typically fixed is by low pass filtering the encoder velocity signal
before displaying it. If this has already been done, you might increase the time
constant of the filter

If the HOME_SEARCH_VEL and HOME_LATCH_VEL are positive, the axis will move to the switch, back off it, and re-engage it at LATCH_VEL until the signal changes state (again).

If the HOME_LATCH_VEL is negative, the axis will move off the switch and stop as soon as the signal changes state.  No 2nd move back on to the switch, so potentially done slightly faster if your LATCH velocities are really slow.

I think one of the contributing reasons LCNC's homing is so confusing is simply the terminology selected by the developers years ago.  The terms made sense to them, of course, but I think more differentiation in terms would make homing configuration more intuitive.

Such as changing HOME_OFFSET to HOME_SWITCH_LOCATION or similar.

And of course, the current terms make sense to some people so changes would make things confusing to them.  There's no perfect answer when it comes to preferences.

I'm not sure if this is the right place to ask about this issue, but I'm experiencing a strange and potentially dangerous problem.

I was running the same program all day without any issues. However, I had to stop the program halfway through due to a broken insert. First, I paused the program, then stopped the spindle, and finally stopped the G-code execution. The spindle was running with G96 (constant surface speed).

After fixing the issue, I reloaded the same G-code. But when the machine started moving with a G1 command, it moved at maximum speed right away. I couldn’t get it to execute G1 correctly until I restarted the LinuxCNC software.

Does anyone know what might be causing this? I was very lucky there was no damage.
I've also uploaded a video showing the problem.




Adding my configuration :


 



Is there anything wrong there?

Hi all 
I'm trying to piece together a boxford 160 to standard.
almost there I have all axis wired up and runing.
anyone know where I can find the correct one of these?
it's a minefield looking on rs components
it's a microsensor but looking at specs they dont macth what I think I need. any advice would be great..

Also, it is perfectly possible to have the index and A/B phases on different shafts. A prox sensor picking up a keyway / bolt whatever on the spindle can work fine.

You can't do multi-pass threading (lathe, or peck-rigid) if the index isn't 1:1 with the actual spindle.
But, for single-pass rigid tapping it doesn't matter where the index is as long a the encoder scale accounts for the gearing.

Hey everyone,
I’ve been setting up a CNC mill using LinuxCNC with a Mesa 7i76e board, and I’ve run into a bit of a headache. The spindle RPM readings in the LinuxCNC GUI are fluctuating a lot even when the spindle speed seems stable when measured with an external tachometer. I'm using an encoder on the spindle for feedback, but I’m not sure if the issue is from signal noise, encoder settings, or something else in the HAL config.Has anyone else had similar issues with inconsistent RPM readings? What would you recommend checking first encoder wiring, debounce filtering, or maybe even firmware updates for the Mesa board? Any guidance would be a huge help, I’m still getting comfortable with HAL and custom configs.Thanks in advance!

References:

www.theengineeringprojects.com/2023/06/i...l-with-linuxcnc.html
www.cnczone.com/forums/linuxcnc-formerly-emc2-/
store.mesanet.com/index.php?route=product/product&product_id=58

Thanks for thinking so hard about this. I appreciate it.

Two things: first, because of how my switches are set up, I believe both HOME_SEARCH_VEL and HOME_LATCH_VEL need to be positive. The backoff movement is added automatically in between them. Second, HOME_FINAL_VEL isn't a signed velocity. I realized that yesterday while trying various combinations. It would probably be better if the homing code threw an error, since it implies a slight misunderstanding of the config, but instead it seems to simply use abs(HOME_FINAL_VAL).

In the end, the difference between what you propose and what I tried yesterday is the value of HOME_OFFSET. That could well make the difference. I'll try it later today.

Thanks again!

Maybe both modules also need to include <linux/module.h> ?

lkw.readthedocs.io/en/latest/doc/04_exporting_symbols.html

pgf wrote:

I've now tested my original homing-at-0 config, with HOME=12, and it does indeed home as usual, and then set the current position to 12. So the question asked in the thread title is answered.

I'd still like to home-at-12, instead.
 

If you'd like the table to home all the way to the operator's left (X-max), and your two X limit switches are on the same input, you can change your INI config so that the search direction is positive. I think the following is what you want:

MIN_LIMIT = -0.001
MAX_LIMIT = 12.001
HOME_IS_SHARED = 1
HOME = 12
HOME_OFFSET = 12 
HOME_SEARCH_VEL = .2
HOME_LATCH_VEL = -0.015
HOME_FINAL_VEL = 0
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_SEQUENCE = 2

This will result in an X homing sequence as such:

• Table moves left (searching X-pos) at speed 0.2
• Limit switch reached
• Table moves right (X-neg) until limit switch clears at speed 0.015
• Table stops, homing complete, DRO will be set to "12"

The reason for the "12.001" MAX_LIMIT value is that if you set it the same as HOME, then when you are finished homing the axis will be on the max soft limit.

If you would like the table to finish the sequence in the middle of travel, you can change the above as follows:

HOME = 6
HOME_FINAL_VEL = -.2

Same behavior as above, except after the limit switch is cleared the table will move right (X-neg) to the middle of travel and stop with the DRO at "6"

Similar edits can be made to the Y-axis to have the table finish close to the operator.

This is just wrong (typical AI error?)
stepgen is realtime, and should be loaded with "loadrt"
I would rather expect that the same is true of remora-eth-3.0 (if that even exists)

linuxcnc.org/docs/stable/html/man/man9/stepgen.9.html

I can't immediately think of a way to do what you ask.
It would be possible if M5 was re-mappable, but I don't think it is.
If you can use (for example) M15 in place of M5, then that could be remapped to:
wait for spindle stopped
measure the current angle
reset the offset (as described earlier)
rapid to A=0

linuxcnc.org/docs/stable/html/remap/rema...remap:existing-codes