Advanced Search

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...

I have edited the original pid.c to include a minoutput pin, and now it works like a charm. There is no windup and zero overshoot on the way down, just like on the way up.

To install it, open a terminal in the folder containing the modified pid.c and run:

Then set the minoutput pin to the minimum ADC value your setup can handle. In my case, this value is zero, since I am using a software pwmgen to generate a 0–10 V signal:

This is the piece of code I have customized:

video showing it functioning in sim and how to test:

load tool 99 probe tool, move probe tip somewhere clear in the work envelope, use inside corners probe page and select a single move probe routine, trigger the probe by clicking the probe graphics probe tip. try jogging to see if sim repsonds correctly.

 

if you still have probe basic installed, would you mind running a test in the simulation? I am running a sim test here and cannot reproduce the error using the on screen probing buttons. i can probe a point in space and immediately jog afterwards using both the keyboard and on screen buttons. so its hard for me to discover why your install is not responding the same. but if you test the sim and the problem does not exist then it would be something in your configuration most likely.

when you say locks out, were you referring to keyboard, on screen buttons, or both?

Yes, the PWM value (from the PID component) should increase as the position
error increases.

Did you check the 5V power?

Are CR23 and CR27 (Yellow LEDs near the center of the card) both fully illuminated?
(these LEDS indicate the analog +16/-12V power supply operation)