Advanced Search

@f355
Kernel I'm using with the image I produced with pi-gen. Have kernel=kernel8_rt.img in config.txt So it would appear we're cooking with the same ingredients, installed xfce4 and boots to the gui, this was done whilst logged into the lite image. The issue I seem to have is that when running latency-histogram --nobase I'm getting "using POSIX non-realtime" which makes me wonder about the kernel.

Tho I am using the same SD card that I originally wrote through RPi Imager for an RPi5 but I'm running on a RPi-400.........The goblins seemed to have move my USB keyboard from where I last put it. Could this be the issue ? Any thoughts ? Yes the kernel config does have PREEMPT_RT set. (for anyone else reading)

But I do think using pi-gen is a simple solution.

Have you tried PETG with PLA support? (easier said than done if you have a single extruder printer without an AMS)

I have something a bit similar on my lathe running Touchy. The jog increment is from a small encoder on the apron. It's a bit annoying that the on-screen soft-buttons don't even work as indicators, but I have never bothered to try to fix it.

There shouldn't be any problem using an encoder with only A and Z channels. I assume you are using the LinuxCNC software encoder?
If you set counter-mode it should count, but only up, never down. (but you probably already did this).
You seem to be saying that counter-mode prevents index reset from working? I am almost 100% sure that isn't the case.
There may be a not-insuperable problem in your wiring or HAL logic.

f355 wrote:

However, the debian package itself seems to have a broken python3 dependency. I'm on the latest Raspberry Pi OS Lite (which is basically trixie with a custom kernel and a few Pi-specific tools installed). Any particular reason for the arm64 package to want python3 < 3.12? amd64 one depends on 3.13, and so does linuxcnc-uspace 2.9.4 that comes with trixie.
 

It's possibly a consequence of the recent Pi .deb that I posted being built on Bookworm as I don't have a Pi running Trixie at the moment. 
The Debian package control files don't specify a version, but it is possible that a dependency is introduced by the configure step of the software build. 

I have a feeling that the package for the Pi in www.linuxcnc.org/dists/trixie might be the Bookworm package rather than one built on Pi/Trixie. I don't know how that happened at this point, I might just have been hoping that it would work and have now found out otherwise 
 

Sample hm2_modbus config for GS10 VFD including 7I96S hal/ini files:

 

I have found its easiest to put the mbcc files in the ~/linuxcnc/configs directory
as that seems to be in the default search path for the binary (xxxx.mbccb)

I don't know why there seems to be a dependency on an old Python3 version, I don't see that anywhere in the Debian config folder.

github.com/LinuxCNC/linuxcnc/blob/2.9/debian/control.top.in#L44

Not obvious because some step drives list the microstep ratio:
2,4,5,8,16,32 etc but some list steps per revolution, 400,800,1000,1600 etc

OK, i have to ask, why FreeCAD after Inkscape?
If you are trying to do a depth map, none of those are good choices, try dmap2gcode from ScorchWorks website, it is very easy to use and works perfectly.
That is derived from the already included image2gcode that comes with LinuxCNC, so did you ever try to open a image file with LinuxCNC ? It works fine, but does require a bit more testing to get good results.

Have you checked the DIR output pins with a voltmeter when jogged in either direction?

A suggested step/dir daughter cards are: 

7I78 (4 differential step/dir outputs 1 encoder, analog spindle interface),
7I85S (4 differential step/dir outputs, 4 encoders, 1 serial port)
7I88 (8 differential step/dir outputs)

common parallel port breakouts:

Sainsmart 5 Axis CNC BOB
CNC4PC C11G
CNC4PC C10

 

1 piece props will require supports and that will require a lot of sanding and cleaning of all surfaces.
Multi piece ones are much easier and less cleaning and end up much more balanced.
A few nights back i had a light bulb moment, to print 1 piece props with no supports and at very low layer height so the next layer still has where to land, but i have yet to test how that ends up. I would start at 0.1mm for first test.

Hakan wrote:

I like this!
 

So do i, for float switch also, but i digress as i did complain when PlasmaC was developed about double probing being a waste of time.
Someone insisted on "precise" pierce height to 0.1mm, for something that does not care even being a full mm off.

Yes, that really made a difference! Much more distinct and quicker too.
I wonder if there is a way to upload a short video? All kinds of pictures are possible, yes, but a video?

Here is the only change I made in plasmac.comp.
It made plasmac skip the PROBE_UP sequence for the ohmic probe.
 

Ten 5 mm cuts in 1 mm sheet including probing before the cuts.
It goes down, contact detected and directly up to pierce height and starts the cuts.
 
I like this!

 

I know this may sound a little silly but is there a connection between the breakout board's gnd and the 7i97t ground. Some people have either forgotten this or just didn't know.
Not being familiar with your breakout board but does it require a heart beat pulse to enable the outputs ?

Sorry if this sounds a little too basic.

Many thanks Sven, probably I miss something in my config, maybe in the festo drive. Because when I launch linuxcnc the festo drives goes in error “EtherCAT process data invalid”. I’m not sure of the drive reference method on the festo side.
When I’m able I’ll upload my festo setup from the festo automation suite.
If it’s not a problem for you to share your setup it would be great.


Many thanks again, Lorenzo