Advanced Search

This might be interesting, no src code but hex files to program 32 bit MicroChip MCU.

github.com/talla83/tshw

I wouldn't use a VFD for a C-axis. A VFD might be able to orient well enough for a tool changer but the dynamics and precision of a rotary axis are much higher and a servo motor would certainly be my choice.
There is also a video in german:
forum.linuxcnc.org/10-advanced-configura...able-issues?start=20
I have successfully used a servo motor for this in an experimental setup. In that case I dynamically switched between step/dir position command for rotary and analog (0..10V) for spindle velocity. A modified orient component and M19 command was used to rehome the spindle when switching from spindle to rotary mode. In the end the problem was that my servo motor setup was not stiff enough in rotary mode and the motor brake had too much play when engaged.
[edit]
I gather that traditionally there is a motor with belt drive for the spindle mode and a different motor on a worm gear that is mechanically engaged for the rotary mode. Although I would be somewhat surprised if that was still the case on modern machines.

Hi Aciera,

Thanks for the Reply.

I tried what you suggested but but there is no change in how the Machines shifts for actual trajectory because of shift in Linuxcnc simulation.
I am using Linuxcnc 2.10.0 Version.
Is it because of some glitch in Kinematics ?


Regards
Abhishek

This 2020 publication proposes the use of 3d clothoid fillets for space corner smoothing in tool paths:
www.sciencedirect.com/science/article/abs/pii/S0736584519306222

So it seems that 2D fillets are still the norm in tool path segment blending, which gives me the impression that even modern controllers can't blend non-planar segment corners including anything that involves a helix (which is often used for tool entry moves). I have no idea really but this might explain why 3D CAM toolpaths are often made up of short straight segments as two straight segments will always form a planar corner.
All this makes me think that using the current (planar) clothoid library would require a segmentation of the recorded tool orientation path and then calculate the plane and fillet for every segment corner. I wouldn't know how to do the segmentation of the recorded orientation path much less if this is computationally feasable. Also it seems kind of silly to have to segment an entire helix when it is really just the beginning and the end that need fillets.

I had a look at your proposed method of fitting helixes:
forum.linuxcnc.org/38-general-linuxcnc-q...lib?start=420#303355
This would probably be ok for many cases, however I'm somewhat skeptical about the predictability of the path deviation as it seems to deform the helix not only locally at the beginning and the end but also quite noticeably in the middle. If this was done to our helical path of the tool orientation the deviation of the orientation angle might well be beyond acceptable.

So for the moment I have run out of ideas, unfortunately.

Good points. I did a reality check on responsiveness by setting jog increment to 0.001" and then banged in 10 moves as fast as I could and it caught all 10, so faster than me.

I'm not ruling out the 7i73, one option would be to buy one and then remove the chip and solder it to my board I don't need the other stuff on the board, or perhaps Mesa will sell me just the chip? This approach still looks a little messy because the data from the touchscreen also needs to make its way to the 7i73.

Earlier (IIRC) (EDIT you  actually it was spumco) provided a link to an ArduinoConnect project. This is another possible solution I watched the video and thought hmmm this might just work? So pulled a little Nano out of the smorgasbord of wires etc on my bench and perhaps 20 minutes later it was hooked up to my Linux machine and visible in HAL configuration however when I manipulated the one input and output it did not work. I will try and find some time today to see if I can get it working. From my really quick perusal of the code other than the 5 s heartbeat it's static unless something changes so hopefully low burden and hopefully responsive enough.

I made a quick list of things I want to get from Linux back to my board and it's really not much (from memory)
Mode: jog, MDI, gcode running = 2 bits
Status: Estop, machine power, spindle on = 3 bits
Limit switches: = 6 bits or 3 if I code them
Rates: jog, feed = 8 bits each.

I don't have a sense of how much Linux time will be required for the .py code used for the HAL interface to deal with a small amount of data like this? I will need to learn about Linux tools for evaluating timing and burden. Bored in retirement ya.... sure;-)

the only thing i could find is that the error rate depends on the SPI speed, maybe try using 'pullup' resistors to 'stretch/stabilize' the signal lines

Hi,everyone.I'm developing a machine,which need using one servo motor as both spindle and C-axis,and it's controlled by ethercat.I dont know how to make it using linuxcnc-ethercat.By reading the doc of cia402 component ,it seems to be unavailable to switch from csp mode to csv mode in realtime ,does anyone know how to make it done ? Thanks

Thanks.I'll post a question in Ethercat section then.BTW,if without considering the hardware condition,what will be the best solution for my requirement? To buy a PWM or VFD motor and using Orient component ?

Nein ich bekomme keine Fehlermeldung. 
Bei allen versuchen sind es interne Grafikkarten. Liegt es vielleicht daran?
Heute letzter Versuch mit externer Grafikkarte. 
Geht aber erst abends!

Yes that is correct. Three ta knot's can create a plane.

Note, the tool orientation vector and the current TA knot already define a plane:
 

On this plane we could record the tcp-ta intersection along the plane.

This crossed my mind as well but will only work for small changes in orientation angles. If we have a simple move like this:
G1 X0 A0
G1 x100 A180

there is no single plane that records the intersection path of the tcp-ta vector. As the vector rotates from pointing straight up to pointing straight down the resulting curve would disappear in infinity.

Wenn Sie linuxcnc von einem Terminal aus ausführen, erhalten Sie Fehlermeldungen, wenn Sie versuchen, die G-Code-Vorschau zu vergrößern?

Könnten Sie die Ergebnisse posten, wenn Sie Folgendes in ein Terminal eingeben?
Tut mir leid, aber ich habe wirklich keine Ahnung, was falsch sein könnte. Ich kann das Problem hier auf keinem meiner Rechner sehen.

Possible solutions will depend on the hardware you are running, so you might want to ask this question in the EtherCAT section.

Trying to get the LC2.8.4 set-up, I screwed up the install badly, so reverted to the LC2.9.2.
Installed the new (old stock) replacement 7i96 and the original RPi 4B 4GB.

The set-up went smoothly with the help and assistance of fellow Forum Members residing here in Sydney .

Axis opens and ping tests perform flawlessly.
Now to make chips.

I will make a desktop system with the old 7i96 and the RPi 4B 8GB to see if the original "perceived" sensitivity of physical movement of the ethernet plug exhibits itself.

But, considering how I screwed up two LC2.8.4 installs, I fear it will be a 'mea culpa' event.

This is my setup:
- download LC2.9.2 from official site,
- Raspberry Imager flashed the SD card,
- nil adjustments to the RPi 4B 4GB operation,
- Mesa jumpers 192.168.1.121.

$menu-config:
Wired connection 1
eth0 (::::
IPv4 <Manual>
192.168.1.120/24
255.255.255.0
(No custom routing)
[x] Require IPv4 addressing
IPv6 <Ignore>
[x] Auto connect
[x] Available all users

Keep well,
John.

Cool, it wasn't an issue for myself but I thought it might be worth mentioning. At least if a user does have this issue they can be sent to your above post.

This was the output I got from re-installing GRUB within an RTAI kernel:When you see:
This is because EFI support is disabled in the RTAI kernel. Latency spikes may happen when it's enabled so I have it forcibly disabled through Kconfig, so you won't be able to modify the boot order through efibootmgr or delete/create entries.

/boot/grub/grub.cfg still updates just fine though and that's the main thing. If you want to modify EFI boot parameters you'll need to reboot into a Debian kernel and do it then.

I'm using a local branch of RTAI which has the kernel updated to 5.4.278, I can't test my changes because the laptop I'm currently using throws kernel panics whenever RTAI loads so I won't push until I can verify my changes are OK.