Advanced Search

Hello everyone!

I am struggling with the implementation of my servo drives. I set up the pncconf wizard and did some adjustments, checked the Output Offset and scaled the Encoder. Now I want to start the machine an make some PID tuning, but if i toggle the Machine Power Button the Servos directly starts to turn. After a few secs i got an following error (make sens) and the Servos stops.

What is wrong in my config? Is this an Servo Controller Problem or an Mesa Setup Problem? What should i do next?

I am using the Linux CNC (2.9.4), a MESA 7I92TM connected via Ethernet and a 7i77 at Port P2 for the Servo Drive Control. My Servo Drives (Yaskawa SGDV-7R6A01A) run with +-10V and Encoder Signal to the Linux CNC.

Attached you can find some pictures and files of my config.
Thanks a lot and all the best wishes from Germany
JanCNC

active setup is faar miles in front of everything... it is very interesting stuff 

please reupdate repo /configs with scurve_example.hal and .ini files config for easy setup for other users as it was 1.1.2026 for testing ...

 

Most of my testing was on 5 axis, need some help with the performance on a cloud of points, but it is not half bad in my testing, I compared with a commercial 6 axis robot on same point cloud, and well maybe we are half the way there, which is not too bad IMO

多谢杨阳

thanks a lot, Yang Yang!

Testing is at different architectures(because there is some differences at hardware level and in instruction set) with different G code types... It will influence calculations and produce jitter 

Most of us is running 3axis therefore i started there.. 

Then I will move to 6axis setup and do same for multiaxis movement

Then I will move to hardware benchtop setup and then to real iron... 

I am not in the shop and I can not share more or any code.. then later

is there this folder?
~/linuxcnc/nc_files/examples/remap_lib/python-stdglue/python

does that folder have these files?
remap.py
toplevel.py

is this link valid in that folder?
stdglue.py

is there this path?
~/linuxcnc/nc_files/examples/remap-subroutines/qt_auto_probe_tool.ngc

LinuxCNC 2.94
Qt_dragon_hd

Unable to change tools in QT Dragon using the command T2 M6 or any tool number. Debug shows the following

Ran the auto tool sim and that works, compared the .ini and .hal files to find no differences. Thought it wasnt getting to the qt_auto_probe_tool.ngc found in "/usr/share/linuxcnc/ncfiles/remap-subroutines:\"  so I added it to the subroutines which didnt work either

Thank you, by the way all coding was done by 杨阳 aka YangYang, most of the credits go to him, not sure what account he has here on the forum, I did the on field testing feedback, and I now ported to master.
Excited to see your testing results, if you show me your testing methods, I will try to reproduce on my end.

Finally i found the reason for preview disappearing sometimes, while program execution. I was watching call level, current subroutine depth, and preview only works with value 0, not in a subroutine.

 

in your config folder there will be a set of folders: qtvcp/screens/qtdragon_hd/
in that last folder add the file 'qtdragon_hd_handler.py' that I have uploaded here.

It will give you the pins you asked for.

The developed version will be in master branch.
as for 2.9 - I think 2.9.8 was just released.

If you are using an installed version, it should be update-able.
 

Also its very odd that it throws an error for line 76 when the program ends at 72

I would agree its conceptually not hard but my assumption was the rich features offered by qt dragon, probe basic, or even gmoccapy for setting tool offsets would be more simple to setup. Reading docs, changing parameters, and trial and error just leads to more problems, I have several posts going currently with problems in each interface.

My current solution and only working solution has is to just g-code and probe everything manually and type in tool lengths manually instead of the automation I assumed was already included in these setups. Yes from here I need to make my own macros to automate it myself but I guess I was just fighting the fact that its not as plug and play as it was made to seem. Each tool sensor feature from each interface doesnt seem to work at intented.

Dont get me wrong, I like Linuxcnc, I have been using it for over a 2 years now but progressing into more automated features like getting a 3d probe and tool sensors has been a pain so far for something that seems so modern to use now.

This is why I am looking freelancer services, I am willing to pay for someone to 1. setup it up as intented, 2. figure out the problems, 3. or at least show me whats wrong so I can share my findings to save the next person who wants the same features some time and to get on with machining.

Thank you, i will report back whenever i get a chance to do some testing, but:
-it is -2 degree C in the shop with the plasma machines and -10 outside
-i am in negotiations with local government and KFOR on sever projects, from CNC to drones, takes a lot of time for very, very little results
-
Edit:
Maybe to late but still, when i use the phrase "unreliable" i mean compared to Axis GUI as that is my reliability reference point as it just works, perfectly, for years. Compared to most other machine controls i have used, PlasmaC is very, very reliable, and another reason why i use the 2.8.n version on production machines, it is 99.8% reliable, i am just a stickler for those 0.2%. Same goes for QtPlasmaC with about 99% last i tested several years back, but (and this is a big butt ) when doing 286 cuts on a single plate it gets annoying fast.
Also, no, i really do not expect support or updates to 2.8, i mention it as it some of this was there too.
And most importantly, sorry for not helping, i rarely get to use my machines lately, reasons above.

Hallo,
ich betreibe hier zur Zeit eine Eigenbau Portalfräse mit GRBL, genaueres über die Maschine gibt es hier .
Dort sind auch die Probleme dazu angerissen, prinzipiell genügt mir diese Lösung völlig, zum Killer wird das ganze aufgrund der Störungen der Frequenzumrichter. Technisch ist da zwar Abhilfe möglich, das würde aber der Mobilität der Lösung nicht zugutekommen auf die ich nicht verzichten kann.
Als Lösungsansatz hatte ich über eine Ethernetverbindung PC - Fräse nachgedacht, sowas ist deutlich robuster. Inwieweit es funktionieren wird wird sich noch zeigen müssen. Daher wählte ich einen günstigen Ansatz für den Test.
Momentan ist ein Arduino Uno mit GRBL drauf in der Fräse, ein MSI 9A35 als PC, das sind die komplett passiven Windboxen im Alugehäuse, schön robust mit Linux und BCNC im Einsatz. Im Grunde ideal für solche Dinge.
Das der 9A35 nicht genügen wird war mir klar, daher habe ich einen 9A45 beschafft, das ist ein dächte ich 1,8Ghz mindestens Zweizylinder mit 4 GB RAM. Der Charme der Dinger sind auch die zwei Onboard Netzwerkschnittstellen. Eine davon stellt die Verbindung zu einem Novosun NVEM V2 Sechsachscontroller bereit, die Firmware für Remora ist schon drauf.
Der PC hat ein installiertes Linuxcnc mit der nach besten Wissen und Gewissen installierten Remora Erweiterung. Soweit sogut, der NVEM ist via Ping auf seiner Adresse erreichbar. Linuxcnc scheint den auch zu erkennen, trenne ich die Verbindung zum NVEM oder schalte den aus kriegt das die Software mit und geht offline.
So, nun ist es so, ich brauche etwas Hilfe zur Selbsthilfe, was muß ich als nächstes tun? Was muß ich als erstes konfigurieren, oder anders gefragt was muß ich überhaupt konfigurieren - versuche ich eine Achse mit der Testkonfiguration in Remora zu bewegen gibt es eine Fehlermeldung Motor x Positionsfehler - x steht für die Nummer der Motorachse.
So wie das also aussieht fehlt da noch ein Stück Konfiguration, ich denke nicht das das Problem am NVEM zu suchen ist.

Gruß
Mario


 

your job is amazing ... i am watching the scope curves without the breathing ....

conculations of polynomes of 5th grade probably take some power ... for more axis at same time can introduce jitter and at cloud of point it will be most visible ...

I am actually testing it at 1000us 500us and 250us which is most commom industrial scan time ... intel core duo, i5 and i7 ... every has different computation capacity but jittering are present during clouds 

I will take some more time and I will post outcome 

thank you for your job! is very interesting 

Wow! Thank you for testing, I actually never looked at the effect on the servo thread, I was more concentrated on velocity and acceleration changes, it is an interesting testing method, there maybe further possible optimizations, possibly some c++ tricks I'm not aware of, but in current state is the best I could come up with, and it is IMO respectably decent, nice to get some validation...