Advanced Search

  Good afternoon, I think I managed to do what you asked me, but without results, still with the same error. Could it be my pyocd installation? I've tried with other versions of Debian, but always the same problem.

Best thing to do is think of an RPi running Linuxcnc as the ECU in an early 2000's car or bike, as long as it works there's no real need to upgrade.
I'd like to be able to count the amount of times I upgraded the ECU on my 1999 Toyota Echo on one hand, but I have all the fingers on each hand

On a normal daily driver or even server kernel upgrades are fine.
The issue in this instance is that the kernel used in the image is particular to the RPi and is custom built.
From playing around with various Arm devices the boards aren't as "generic" as the PC platform. Each Arm processor or SOC has it's own quirks as such. The device tree is a way to let the Linux kernel know which devices are available, device tree overlays are used to further customise the setup.
Then there are custom patches that are used to further "tune" a particular board.
I have 3 main machines at home running Linux, one desktop and laptop running Mint and a server running Ubuntu, kernel upgrades are not an issue on any of these 3.
Obviously I have an RPi5 & 4 for testing Linuxcnc images, so these don't see kernel upgrades unless testing new images.
The Orangepi PC that running my hacked together reflow oven doesn't get upgrades, it works and is left alone, but it does have a custom device tree has I needed some status LEDs and an off button on the front panel from the GPIO header. Now if I was to upgrade this kernel I would also have to rebuild the device tree file to suit.
Whilst the Arm platform is good, it's come along way in 20 years, it's not as generic as the PC platform, it's kinda like pre PC days.......but without the OS software issues.

Try been in the directory where the file is located. Before you run pyocd. Are you able to ping the board. 10.10.10.10 ??

Aaah I see; thoughtless mistake then. Kernel 6.1.0-35-arm64 was the linuxcnc one, which apt erroneously removed in favor of 6.12.11-1 and 6.12.12+bpo-rt-arm64, since those (recently) emerged as the logical successor. Note to future self: do NOT accidentally do dist-upgrade on LinuxCNC!

I was hopeful though, that the original version could be reinstalled without having to redo the whole install. This is because when removed, apt did note that it could not remove the 6.1.0 folders as they had custom files in them. But alas, I accidentally removed linux-image-bcm2712-rpi since that was now linked to the 6.12.12 kernel. That package has no installation candidate, so I'm borked. Reinstalling...

Thanks! That first paragraph was gold. My understanding of how the whole thing works just went *way* up!

Deleted.

Hello,

I am currently trying to get the toolchanger working with probe basic. It works however the subroutine (m13) is made for a continuous motor. This machine uses a stepper motor, with a custom stepper driver. If I enable one relay it moves the carousel one pocket. The relay needs to deactivate before it can be repeated. There is another relay to change the direction. I was wondering for the homing of the carrousel, is there a good way of doing this?
Like a while loop which activates the relay, waits a little bit and deactivates it until the home sensor is activated?
 

Switches wear out over time and require less force to actuate, which can make a slight difference, bearings wear down a bit, screws loosen slightly, etc.

That's what I mean by mechanical changes.

By mechanical shifting I mean like a leadscrew no longer being in exactly the same place after years of operation due to slight movement of stuff over time.

SIDE NOTE:
My grandparents recently bought a house that was built in 1974 and were told it would not shift or settle because it was built long ago and has had time to settle for 50 years.
But vibrations caused by renovations caused the walls in the basement to crack a bit visually (structurally, it's all fine).

You could use a 7I96S spindle configuration as an example.

Depending on what source you read Australia has anywhere from 10 out 15 fifteen to 20 out of 25 of the most deadliest snakes. As Rod said almost all aren't that aggressive and would rather be left alone.
I can testify to that, my Beagle tracked one for about 10 minutes, effing Brown of all things, and all the poor bastard wanted to do was get away. Bloody dog has a thing about snakes, most beagles like rabbits and the like, but my weirdo dog tracks snakes....gotta be really on the ball when walking him near areas with bush.
A other funny thing about Oz, we have the largest population of wild camels....reckon in the next 25 or so generations they'll get poisonous like every thing else.
Actually it's not that bad, it's only really the coastal areas of Australia where people live, maybe 200k in and after that it's pretty sparse.
Just need a bit of common sense, don't annoy the wildlife, careful which plants you touch and don't go on the other side of the railing to get a closer look at the Blow Hole.
Oh and don't argue with the Highway Patrol, they're the guys the Outlaw MC gangs rejected for being too anti social and morally corrupt.

ok thanks jt, soon as i get to the shop i will check the pins.

btw, do you have some boilerplate code for a pwm spindle? if not i will dig in my archives and see if i can get the old spindle code working

Thanks for the answer. Is there no way to operate my machine like this?
One option would be to swap the X and Y axes, but is there another option?

For Mesa step generation (others are similar) LinuxCNC creates a local feedback loop
where at every servo thread invocation, LinuxCNC reads the current stepgen position
and then sets a new velocity based on the current commanded velocity and with a small
correction based on the current position error. That is, at every servo thread invocation,
LinuxCNC generates a new position. Based on that new position and the current stepgen position
a new velocity is calculated to meet that new position at the next servo thread invocation.

With Mesa hardware the precision of the control loop is 1/65536s of a step, so typically
the error between the commanded position and the stepgen position is never more than
a fraction of a step.

Here is a plot of stepgen error at:

10 ms servo thread
1 IPS cutting speed
5 IPS rapid
50 IPS/S accelration

Note that Velocity is in IPS  per division and error is in 20 uinch  (~0.5 u) per division

The residual noise in the error is caused by timing uncertainty in the position sampling.
This is about 2 usec at a 10 ms servo thread but about 400 ns at a 2 ms servo thread

 

Even the chord error is nothing to worry about as long as you do not have extreme
acceleration (say > 1G)

 

This is how the interface looks like.
 
The difference, the contrast in style is obvious.
So I think with a QT interface, as you are doing, it would be better.

Giovanni