Advanced Search

I'm a bit confused, if I want to start the system with an output at 1, do I apply setp... inverter true

This should show me the output activated, but I don't see it that way; I still see it turned off. I don't know if I'm misinterpreting it or if it's not working for me, which is why I left a video showing it.

At startup, the system,(for example the pin 1-out) does not change when an inverter is applied.
You can watch the video I uploaded in this thread to see what happens

Hi,
thanks a lot for the suggestions.

Just to clarify: I had already tried short Dupont wires and a short IDC ribbon, but without the “every second wire = GND” scheme. The cable was about 10 cm long and SPI still failed when the hot wire or motors were active.

Now I’m going to rebuild the SPI cable exactly as you described: ribbon cable with every second conductor GND, all GND wires tied together and connected to GND on both the RPi and the SKR. I will also add a separate, thicker GND wire between the boards and keep the SPI cable as short as possible.

One question: for the ribbon cable, should I place the signals like
GND – SCK – GND – MOSI – GND – MISO – GND – CS – GND – GND,
or do you recommend a different order?

I will report back with results after I rebuild the cable.

Sold.

Coordonnées polaires:
linuxcnc.org/docs/html/gcode/overview.ht...de:polar-coordinates

I suspect you dont need to do any of that. LinuxCNC tool tables aready define both tool number and pockets. Tool numbers are unique, but pockets dont have to be. 

There is a carousel tool changer comp which supposedly already works with the Schaublin tool changer.
www.forum.linuxcnc.org/10-advanced-confi...carousel-toolchanger

So lets consider your example.
For a job we mount all of these tools. The first three go on the three postion gang tooling holder you have. We mount that in turret position 1 which in the tool table is pocket 1.
T1- Spot drill - Pocket 1
T2- Drill - Pocket 1
T3- boring bar - Pocket 1

T4 - RH VCMT turning tool in pocket 2
T5 - Kurling tool in pocket 3
T6 - LH VCMT turning tool in pocket 4
T7 - but we also need a threading tool, so that is on another tool holder, and will be manually changed into pocket 1.

T8 - Parting tool on the rear tool post, which we will call Pocket 5.

I have not looked at the code of that carousel.comp, but suspect it only trigers activity of the tool holder when a pocket in it's assigned range is called.  So if pockets 1-4 are assigned in the comp to the carousel, then the behaviour would be:

At the start of the program, I would add an M1 and a pop up message to remind that the gang tool has to be in pocket 1.
The M6T1G43, the carousel indexes back to pocket 1, if not already there.
First three M6TxG43, the carousel is not called, LinuxCNC just assigns the correct called tool, offset, orientation and nose radius, and continues.
M6T4 G43 - Turrent indexes once, then LCNC assigns the correct called tool, offset, orientation and nose radius, and continues.
It would be at this point that I would have programmed in the M1 stop, to manually remove the gang tool holder with it's T1-3, and load T7.
M6T5 ( and T6) Indexes around one.
Calling M6T7G43 would rotate the turret back to pocket 1, with its changed tool.
M6T8G43 I would expect to again do nothing with the turret and just load the offsets for the parting tool.

It would probably be a good idea to add another M1 and text pop up at the end of the program to remind to reinstall the gang tool in pocket one, so the program is ready to go on a restart.

Of course I could be wrong about that carousel.comp not moving the turret on a tool change which calls a pocket outside it's range (or no pocket). But if that is the case, it would be best to modify the comp. Misusing the tool diameter for this would lose the ablity to do tool radius compensation, which is important on a lathe.

CAM software doesn't care where the tools come from. It just assumes the appear with the correct offsets, orientation and radius.

For tool table hygiene, it might be good to standardise like anything in pocket 1 is called T1xx, in pocket 5 -->T5xx etc.
Cheers,
Mark

 

There might be something in the cia402pv code.
The original cia402 component didn't allow mode switching, it took the first csp_mode value at startup.
I need to at least go over that part to make sure mode switching works.
But I doubt that's the reason.

Start using the debugging tools. Halshow and maybe halscope to follow the values over time
to find out the reason for the following error.

Yes I use his code for tracking the positon.

It also seems like if I tested the pv mode not long enough, because if I let the servo run with for example 600rpm, it throws a joint0 following error after some time. Is this even possible in pv mode? I thought this is only a velocity command without feedback loop?

I also changed the code back to spindle.0.speed-out instead of spindle.0.speed-out-rps (of course with a scale change), but the behaviour is exactly the same.

Excellent info. I've started working on a similar procedure.There are a few more optimisations but I'll test before sharing anything.
Now PREEMPT_RT is in the mainline, there are a lot of articles emerging about  RT tuning.

I've had a bunch of issues with the TB6600 drives, both missed steps and failed parts. Although they might have been knockoffs but still.
I've used the DM556 series exclusively since then with no issues.

But I've already done that, even if it have been with GRBL and ESTL instead of LinuxCNC.

I already have both the EtherCat servos and EtherCat IO so that is the way forward in this project.

Top work.

The thing is there is a few users of the RPi, I know about 3 personally, but very rarely do they post or answer any questions. So it gets left to a few to get the job done.
Personally I like the RPi5 I just acquired a second one thanks to my son for father's Day and grabbed the same waveshare housing and Nvme adapters I'm using on the mill.
I have been wondering about including a basic 3 axis Byte2Bob config in the next experimental image. Your thoughts ?
Would you be ok with some of your attachments, with due credit, being included ?

Cheers
Rob

Some advice regarding chatgpt and AI in general for help. Currently it is not a good idea asking about Linuxcnc, many many times it gives answers that make no sense and will not work.

I wonder if it would be worth having a sticky thread that is an index to some of these great posts regarding latency and such.

Hello friend, I will try to help as much as I can.
First I would like to ask what language is best for you ? I am asking this as I can only speak English. It is my hope that there maybe someone that speaks your native language and maybe able to help.

For the image the most recent can be found here:
forum.linuxcnc.org/9-installing-linuxcnc...mages?start=0#338181

Byte2Bob help can be found here:
forum.linuxcnc.org/9-installing-linuxcnc...aughter-board#339613

I hope this is a start. I will do as much as I can to help.
All the best
Rob

Hi everyone,
I’ve been thinking about how to handle the toolchanger logic on my lathe, and it’s turning out to be more complicated than I first expected. I’d like to get your opinions on the approach I’m considering.

Problems I’m trying to solve
1. My machine has a 4-position turret plus a back-toolpost. When a tool change is commanded, LinuxCNC needs to decide whether the turret actually needs to rotate or not.
2. Some toolholders can carry multiple tools, so I need a way to define several tool offsets for the same physical holder.
3. A program might use more toolholders than I currently have installed, which means a manual tool change may be necessary.
4. But if the requested tool is just another tool inside the same holder, then no manual intervention should be required.
5. I want to achieve all of this without making CAM programming more complicated.

Nomenclature
Toolholder: The physical holder that can contain up to four tools.
Toolchanger position: One of the physical locations where a toolholder can be installed.
• Back-toolpost = position 0
• Turret stations = positions 1–4
Tool pocket: A logical element in the tool table used to identify and group a toolholder and its tools. A tool pocket maps to a toolchanger position using:
tool pocket number % 5 = toolchanger position
For example, tool pocket 7 corresponds to toolchanger position 2 (because 7 % 5 = 2).
Tool table number:
The line number (ID) in the tool table.

My idea
I’m proposing to use the tool table in an unconventional but structured way:
• Every tool table number divisible by 5 is used as a toolholder descriptor.
This tool table entry represents the holder itself and indicates which tool pocket (and therefore which toolchanger position) it belongs to.
I plan to store the tool pocket number in the diameter field.
• The four following tool table numbers describe the actual tools inside that holder.
These tool entries can be used normally in CAM and have their own offsets, as usual.
In summary:
Toolholder → tool table numbers 5, 10, 15, …
Tools inside holder → table numbers (N+1) to (N+4)

Additional requirements for the component
This approach requires the component to check a few things when a tool change is requested:
• Is the requested tool number divisible by 5?
(If yes, the request refers to a toolholder descriptor, not an actual tool.)
• Does the corresponding toolholder descriptor exist?
The component needs to confirm that the descriptor entry is present in the tool table.
• Is the diameter field of that descriptor a valid integer?
This determines which tool pocket (and therefore which toolchanger position) the holder belongs to.
These checks should be fairly easy to implement.


What this should allow my component to do
• Decide when a turret rotation is required
• Decide when a manual tool change is required
• Select and apply the correct tool offsets
• Remember which toolholder is installed in each toolchanger position (even if that position is not currently active)

Questions
Does this approach make sense?
Is there anything fundamental I may be overlooking?
Any feedback or suggestions would be appreciated!