Advanced Search

Note that the _preview_ does not take offsets into account:
linuxcnc.org/docs/stable/html/config/ini...sub:ini:sec:rs274ngc

 

Hi,

I have a 4-axis MPCNC with a rotary B axis mounted at the far end of the Y travel (machine Y=700mm). The rotary axis is fixed — it does not move along Y.

G-code is generated by CAM with program zero at the chuck face, all moves go in Y-.

The problem: the backplotter does not display the toolpath correctly. Instead of showing the wrapped toolpath around the tube near the chuck, it draws a large circle. I believe this happens because the backplotter uses machine zero as the centre of rotation rather than the actual chuck position.

Setup:
- LinuxCNC 2.9.8 stable
- trivkins coordinates=XXYYZB, 6 joints
- qtdragon_hd interface
- GEOMETRY = !-BXYZ

Is there any way to tell the backplotter where the centre of rotation is?

Thanks

Theoretically the problem is there. 
Some drives may be better than others to conceal the problem.
When you use syncToRefClock and don't hear it you will not hear it.
I mean the drives will not suddenly start being noisy.
The chance of hearing it is roughly every servo loop time/jitter start of linuxcnc.
With 7 microseconds jitter, you can hear it every 142'nd start of linuxcnc.
And you hear it throughout the linuxcnc session.

I thought my drives were immune to this, but after carefully listening I found they also
experience this, but they don't sound awful, just a very mild "tic".
The drives don't have to make noises, but they should definitely react to it.
It's basically a disturbance in the position flow, requesting an artificially very high or low acceleration.

clayton2ndtry wrote:

This rang a bell from when I wrote a terminate-and-stay-resident PC-DOS (stop laughing) program that intercepted data.

I did something similar but it trickled point of sale transactions out of a cash register to accounting software (And I got paid for it!)

andrax wrote:

I’ve been following this thread with interest all along. What surprises me, though, is that I haven’t experienced the jitter issues described so far. I’d be interested to know what hardware you’re using. Perhaps there’s a correlations 

Its never been an issue for me  either. I did wonder the other day if newer hardware was  not a concern.

soooooo, dev is merged to main, no way back

there are some big changes:

### Warning
* breaking changes, please open your config in rio-flow to fix/convert some stuff

### Gui
* new graphical config-gui: rio-flow
* removing old rio-setup

### Genaral
* move all stuff into plugins (boards/modules/breakouts)
* replacing modbus -> mbus/mbus_device/mbus_hy
* replacing i2cbus -> i2c/i2c_device
* better simulation
* test-tool is now based on the hal-component c-code

Thanks for reporting this. I am a little pressed for time these days, so I don't know when I get around to checking and fixing it. 

 

Untested

 

 

i think NOT need this HAT, i think can build own "hat" mean connect to gpio pins shift level converter tx108 chip module, input is 3,3V and this module convert output to 5V and this 5V signal can wired to stepper driver board DM556 etc, step pin and dir pin and enable pin. but problem have how i setting rpi4 linuxcnc all gpio pins ? rpi4 and has installed linuxcnc but if looking have only config wisard and this can only setting paraller port pins, and pnconfig tool has only how setting mesa card pins, i not understand how can setting rpi4 gpio pins all step, dir, enable and all input pins home, e-stop, limits, probe, etc pendant encoder, rotary SW, axis select, scale select. i have installled linuxcnc to rpi4 and software/image working ok, but how setting gpio pins ?

 
I was wrong, on closer inspection the planner can stay within the jerk limit without falling back to a full stop.

It was a bug in the jerk budget split during Bezier blends. Tangential jerk (Ruckig along the path) and centripetal jerk (curvature change through the blend) were budgeted independently, 50% and 100% of the per-joint limit respectively, assuming they're orthogonal. They are in Cartesian space, but not per joint axis, where they add as scalars. For @ruediger123's octagon: 25k + 50k = 75k on a 50k limit, matching the ~47% overshoot in the HALscope trace.

Fix: subtract the tangential share before allocating centripetal. 25k + 25k = 50k, exactly at the limit, no overshoot, no wasted headroom. Corner velocity drops ~20% vs the buggy code, but it's the true physical maximum.

@PCW was right, the TP should always obey constraints. Fix is in the 9d branch.

Edit:

github.com/LinuxCNC/linuxcnc/actions/runs/24068143520?pr=3807

the artifacts at the end of the page.
I'm also looking at what Automata had reported, I think I can improve merging of small segments, I'll put some effort into that

Here you go.

Again, it's complicated.  Feel free to ask questions if something is unclear.

A few thoughts:

• Still a work in progress, but the part(s) you want works.
• HAL files are broken up by major components of the config.
• Lots of comments - you should get a sense of the uncountable number of times I've tried or tweaked something.
• Signal names are all upper case because LCNC's halshow sorts by case first, then alphabetically.  Drives me nuts searching for signals if they're all jumbled due to upper/lower case.
• Sub-spindle is not connected to an axis.  LCNC doesn't have duplicate rotary axes like UVW for XYZ.  I found (so far) M19 works fine for the sub.
• Main spindle motor is a SZGH 'servo spindle' - an induction motor with a pretty smart drive.
  • The drive has position, velocity, and torque modes, just like a brushless PM servo
  • I believe @Aciera switches his drive between velocity and position when he switches LCNC between spindle and C-axis.
  • I found that position mode had a bit of dither at stand-still, possibly due to the induction motor characteristics.  So my drive/motor is always in velocity mode, unlike @Aciera's example.  This may help you with your Schaublin's spindle drive.

You may find that the user tab for Z-compensation is suitable for PCB machining (that is what I intend to use it for)...

forum.linuxcnc.org/qtpyvcp/56808-surface...asic?start=13#339938

This lets you probe the surface with a grid and then when compensation is enabled it applies an interpolated Z offset so that it tracks the surface. This way you don't actually have to modify the g-code. (Should make engraving depth more consistent if the bed isn't perfectly level).

I'd given up on this for a while and only just noticed the replies here, thanks!

After updating linuxcnc and probe basic I was then able to get the user tab working very quickly. I should be able to have a go at some PCBs now. 

Thanks all for your help.

is spindle.0.at-speed  true?


Also does the index work?

Test by (either in halshow or with halcmd -kf)

sets spindle-index-enable true

watch  spindle-index-enable in halshow

it should go high with the sets command and then low when you rotate
the spindle past the index position.

 

I made a new configuration using pncconf and compared the spindle & encoder 0 section.

I don't see anything that's different, other than naming conventions (see attached)

I have a quadrature spindle encoder connected encoder (0) input. A & B

I now also have a 1PPR signal, connected to the encoder.0. index pin.

In Halshow
- spindle.0.revs counts up as expected when the spindle is rotated forward
- spindle.0.speed-in appears correct
- spindle.0.index-enable shows disabled

In my SM-10.hal file I have:
net spindle-index-enable <=> spindle.0.index-enable

IF I comment out this line, I can then enable spindle.0.index-enable manually in Halshow, that makes no difference when trying to open the file below (same error)

Regardless when I try to open the following 2 line G76 program I get the following error: "Chosen spindle(0) not turning in G76"

Program:
G0 X0.45
G76 P0.0625 Z-0.5 I -0.005 J 0.008 K 0.0503

What does the error message actually mean and/or what is Linux missing that it needs?

It has the quadrature encoder signals and it has the index pulse, that I can see toggle as the magnet passes the sensor once per rev,

The revs counter is counting up 1 per rev.