Advanced Search

Solved the boot issue.
Seems to be an issue with the line

Addf mh400e-gearbox. Servo-thread 

Once I removed this from HAL I could boot normally again.

I attached the screen that was showing when it was bugging. See attached 

 

Thanks to you, Andy, NTULinux and everyone for keeping RTAI alive. It's a great controller, I use it weekly.

How does this version compare to the previous Dec 2023 RTAI release? Out of curiosity, does it also include the latest bug fixes?

My installation (Dec 2023) seems to be relatively stable, apart from some insignificant and easy-to-manage glitches, should one upgrade to this fresh build version?

Hallo zusammen,

ich habe das Problem, das meine Maschine ein sonderbares Verhalten zeigt, wenn ich meine Werkzeuge dynamisch vermesse.
Zum Vermessen der Werkzeuge habe ich den M6 Befehl geremapt auf das Macro messen.ngc.
Vorbild hierfür war das Video zur dynamischen Werkzeugvermessung von Talla83.
Die Maschine zeigt dabei folgendes Verhalten:
Das erste Werkzeug wird aufgerufen z.B T10 und vermessen.
Mit diesem Werkzeug wird nun der Nullpunkt gesetzt.
Wird jetzt ein anderes Werkzeug aufgerufen, fährt die Maschine zum definiert Wechselpunkt und wartet auf die Bestätigung das, dass Werkezug gewechselt wurde. Wird der Werkzeugwechsel bestätigt, fährt die Maschine führ einen kurzen Augenblick los (ca. 0,1-0,5s) und bleibt dann stehen.

Hat jemand von euch schon mal ein ähnliches Verhalten gehabt und kann mir weiterhelfen?

Anbei noch ein paar Infos zu meiner Hardware:
Mesa 7i95
Debian 12
Linux CNC 2.9.2
Screen Gmoccapy

Vielen Dank im Vorraus
Viele Grüße
Raksop
 

Yes,I quite agree with that. I think both the spindle orientation or the spindle/c-axis for mill-turn functionality are commonly used .It's better to make it easier for using it in linuxcnc.Maybe the developer or the community of linuxcnc should consider to simplify it for the common user.

I am just trying to understand the mindset of why the code is structured like it is.

Good luck with that.

though the sample hal config in the comment ,I found a little too complex for me

Also a bit dated, a fair bit has changed since. Although setting up the spindle orientation is certainly still not the easiest thing to do.

Hi,I'v watched your youtube video.It looks that the most of the solution need to use Mesa board.but I'm now using Raspberry pi ,so do I have to buy a Mesa board for achiving the spindle / axis as one functionality?

Is it because of some glitch in Kinematics ?

I doubt it, but I haven't tested 'sim/axis/vismach/5axis/table-rotary-tilting/xyzac-trt.ini' in 2.10 lately. I would expect this to be related to your use of the 'U' axis.
Have you tested this on an unmodified 'sim/axis/vismach/5axis/table-rotary-tilting/xyzac-trt.ini' simulation configuration?
 

Thank you ,Aciera.In fact I also want to use servo motor
to be acted as both spindle and axis too. The below youtube link is the final result I want to achive,though the sample hal config in the comment ,I found a little too complex for me :(

hello,

thanks for sharing the manual.
one thing I can't figure out in the driver, the motor is rotating at the rate of 10000 pulse/revolution, is there any way to change it to 1600 pulse revolution in the drive? I tried to find any parameter but unfortunately, they have fixed it to 10000 p/r.

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;-)