Advanced Search

hows it coming?

5_Zylinder wrote:

The problem arises when the cam limit switch (Pin 28) is triggered: the motor shuts off, but the carousel ends up positioned between two pockets. The motor needs to rotate another 180° so that the cutout aligns with the sensor.

Which version of "carousel"? The newer version supports a slow-speed search for the index marker. 
Settting decel-time and align-dc should activate this behaviour. 
linuxcnc.org/docs/stable/html/man/man9/carousel.9.html

If the sense of the index marker is wrong, then you can typically connect to the inverted HAL input signal that most drivers support. 
For example Mesa cards have pins like hm2_5i24.00.7i64.0.0.input-00-not which is an inverted version of hm2_5i24.00.7i64.0.0.input-00
 

Hi
Meanwhile, there is Xenomai3 and Xenomai4 support in master branch.

Details:
github.com/LinuxCNC/linuxcnc/issues/3878

Prebuilt Kernels and Linuxcnc 2.9.10 back-port for Xenomai4:
github.com/hdiethelm/xenomai3-linuxcnc
github.com/hdiethelm/xenomai4-linuxcnc

For me, it works well and I fully switched to Xenomai4.

Hi All
Meanwhile, I fixed Xenomai3 support.
Additionally, I added Xenomai4 including support Ethernet mesa cards.

Details:
github.com/LinuxCNC/linuxcnc/issues/3878

Prebuilt Kernels and Linuxcnc 2.9.10 back-port for Xenomai4:
github.com/hdiethelm/xenomai3-linuxcnc
github.com/hdiethelm/xenomai4-linuxcnc

Is someone using Xenomai3 actively? Xenomai3 support for Ethernet mesa cards is available in a private branch but not (yet) merged.

Rather than LUT5 look at using a match_8 for each gear.

Alternatively, a mux_generic with 6 bit inputs could provide the gear number, or a pair of them could provide the speed limits.
Your HAL file would only need to define inputs for the valid gear positions, not for all 64 possibilities.

The latest version of the Python Tooledit widget might suit you better, as of this commit it looks like it can run standalone.

github.com/LinuxCNC/linuxcnc/commit/fc24...a518b07987c9e20fd30e

I don't recommend this kind of fun to anyone, but LinuxCNC with Trixie can be installed and run from an 8 GB partition.
For a standard xfce4 installation, 16 GB is enough.
I'm talking about just LinuxCNC without any CAD/CAM or other utilities.
Of course, today it is difficult to buy such a small disk and there is no technical or economic justification for it, but it gives you an idea of ​​how much is needed.

40 GB would be plenty, if you could run gparted and move your partitions around making space for a third system, and install debian trixie, maybe with xfce, we could try and develop support for pci 8255 on the preempt-rt kernel, and you could test it out.

preempt-rt kernels are easy to install,
sudo apt install linux-image-rt-amd64 linux-headers-rt-amd64
Is all you need for that, you will have to run in place, so you want to git pull the repo, and build locally uspace and run in place.
Once you got that working, let me know, and I will prepare something for you to test.

Sure thing, I'll try and put one together in the next couple of days.

I would suggest qtdragon-hd with a 1080p touch screen. Several probing methodologies are included.
Linuxcnc includes a  (large?) number of Sims.
There is an extensive thread about Ethercat jitter which you will see died out once issues were resolved.
forum.linuxcnc.org/ethercat/58103-ethercat-random-jitter-fix
Part of the solution  is tuning the system for RT performance and it was comforting for me to see it acknowledged that my tuning  methods were needed. I might add, the same applies for mesa network cards.

The fundamental difference between mesa and Ethercat is that mesa requires a dedicated point to point railway track. Packets hop on the train and get off at the end. Then packets get on the train and go back to the PC.

Ethercat is more like a streamlined bullet train which goes past a number of stations (slaves). Packets get on and off at each station (slave) without the train stopping. Hence why I say its more efficient.

The other difference is that mesa has pncconf to build your config and ethercat need you to build your config from a template just like I had to do on my first machine that used a Mesa 7i76e that was not supported by LinuxCNC at the time.  Having a similar Ethercat dsonfig tool is unlikely. It hard enough to do for the family if mesa cards, imagine how hard it would be with thousands of devlces, some of which are rarely found on a CNC machine. Then ask a machine to home itself without LinuxCNC's knowledge or control....

It seems to me the lawn is really an XY plane with no motors on the axes and the tyres follow a tangential arc and provide the drive.
I think the new motion.interp.heading pin in master branch could solve this. You give the mmachine fake XY g1/g2/g3 moves including the arc at the end and tell the tyres (eg A axis) to follow the heading. If the front and rear wheels need to follow differing arcs on a turn, you might need to adjust/scale the heading using a real time component. Perhaps the spindle speed (S command) might set the rpm on the wheels.

I think with this new feature, solving your problem is a lot simpler than you think.

Some more questions:
What's the best touch GUI in your opinion? Later I must implement custom multi spindle tool probing etc, so that should be possible.
Can someone give me some tips how to set up a machine simulation? It would be great if that also hast a collision detection. Is that possible?, how does that integrate into a GUI?

Please excuse the crudity of these drawings. I didn't have time to build it to scale. (Doc Brown BTTF reference)

That sounds great, where do I find more information about that?

I was having a fun discussion with google AI about trying to build a 4WD 4WS gps guided lawnmower. The idea is to build a chassis with 4 "slew drive units" (SDUs), one on each corner. The SDU would consist of a drive wheel and a vertical rotation axis capable of +- 180 degrees. I currently have a very basic RC lawnmower I built. The only thing I don't like is doing 180s with it, it is only 2WD, but if you're not careful with it, it does dig into the lawn. It's "skid steer", no turing steering, just casters.

So my new concept with the 4 SDUs would have 2 distinct drive modes:

1. conventional curve follow mode. this would pretty much act like a 4WD platform and it would use front and rear steering to gently follow medium size curves up to straight lines. The "body" of the platform would align with the direction of motion following the curve. Say during a mild left curve the front 2 SDUs would turn a bit left and the rear 2 SDUs would turn a bit right to allow a nice following of the curve and keep the platform aligned with the direction of motion.

2. transition to next "parallel" row. this would be kind of like a zig pattern in machining. The idea is to transition at the end of one row to the beginning of the next row without any tight turns or reversing wheels spinning on the grass. If the machine is moving say, directly East and it arrives at the end of it's row, the main platform is pointed East and will maintain that Eastward direction as the 4 SDUs "slew" each steering unit through a 180 degree rotation that drives it to the next row, say to the South, all 4 SDUs would turn say 30 degrees to the right and keep driving "forward". During this transition, "forward" eventually become directly to the West (after each SDU has completed a 180 degree arc), but the platform body is still facing East. Each SDU will follow a "perfect" 180 degree equi-radius path bringing the still-facing-East-platform to the next row. The exact opposite of this would happen at the end of the West running row (and untangling the SDUs wires) to bring everything back to normal at the beginning of the next East facing row.

So Ardupilot is a system used for RC airplanes and drones and such that allows GPS guided "missions". By using RTK GPS you can get cm level accuracy. The software already has a "rover" version that can do conventional mowing patterns but it can't do the kind of motion I'd like to try.

So I asked AI if Linuxcnc could help with this. Of course it said, "That is some next level genius engineering solution, just let HAL take care of it for you."  And I said "can you just make that happen for me?"

At this point it's just a thought exercise, but if you understand what I'm trying to do, could you give me advice as to how I should learn how HAL works? I run Linuxcnc on my DIY 3 Axis router, so I'm familiar with that, but not HAL.

I'm imagining loading a lawnmower path g-code into LinuxCNC and it would use 8 Axii (4 drive motors and four rotational axii for steering). Maybe it could use custom M-codes to specify which mode it's running in (curve follow or slew mode row transition). Somehow we would need to get GPS feedback into LinuxCNC to correct for slip. There would actually be two GPSs on the platform to provide a heading instead of the unreliable magnetic compass. I think I would just use the Ardupilot Mission Planner to read the GPSs and somehow that needs to get to LinuxCNC for feedback.

I'm imagining the code would all be G1 moves and for the tight turns at the end, simply allow the path look ahead to decelerate the drives and accelerate the steering as setup on each axis physical limits.

I'll try to draw up some diagrams if the turning strategy is confusing as I'm not sure I explained it right.