Advanced Search

Indeed, QTdragon defaults to the linuxcnc/nc_files folder, regardless of the path specified in SUBRUTINES_PATH.
Sometimes more information is needed about this, because unlike other GUIs, the path for these subroutines is always the same.

This looks promising, nice work!

A couple of quick tries, sometimes the compressor seems to output scientific notation on small decimals; ie. X-76.198 Y6.6066e-05. That and injected G0 X0 Y0 Z0 at the beginning are only things that pop up at the first tests.

Ich hätte Interesse.
Der 400W STO wäre perfekt für meine Z-Achse

Yes, the moment I pressed submit I realized I forgot the attachments, please see them attached now.





The joints are for sure not reversed, I have the exact same wiring and driver settings on both sides, and as I mentioned, it works perfectly with grblHAL.

The weirdness is actually exactly it. I did try reversing one of the Y joints by inverting the scale parameter and the gantry moved correctly in axis mode when jogging (before homing), but then, when I started homing, the joints started to move the opposite directions, starting to tear the machine apart. Like it had a split mind. When jogging, wants to move reversed, when homing, straight. Perhaps one side starting to move the opposite direction at the end of the homing is a result of that, as the final position is taken, the move is using the same "method", as jogging.

I am now compiling the remora-eth firmware in debug mode (USE_DEBUG=1), perhaps I will see something in the debug terminal (PC connected through USB)? 

No attachments, and how are the Y joints driven?
Chances are you have one Y joint reversed, so adding a - in front of the SCALE value should fix it.

Dann teste erstmal in Ruhe, und wenn 400W ausreichen meld dich hier. Dann finden wir schon eine Möglichkeit. Ich hab 2 ohne und 1 mit Bremse.

My configuration is a PrintNC (a dual Y ganged CNC machine) with a FlexiHAL board with a uFlexiNET Ethernet board, and I am connecting it directly with an Ethernet cable to a Dell Optiplex 780 , running the latest LinuxCNC image (linuxcnc_2.9.8-amd64.hybrid.iso).
I flashed the board with remora-eth, and uploaded the attached configuration (FlexiHAL-config.txt). I also attached the hal and ini files.
What happens is, that I can home and move X and Z correctly, but not Y. The gantry goes back to the endstops, and I can see the homing sequence almost completing successfully, but at the end, one side starts moving to the opposite direction, towards the front.
The wiring and driver setting are identical on both Y sides, and the same hardware works perfectly with grblHAL, so I don't think it's a wiring or driver issue.
Any help is greatly appreciated.

Hallo Sascha H.,

grundsätzlich habe ich Interesse daran!
Ich habe mir jetzt den 750-W-Motor mit Treiber bestellt, der ist auch gestern gekommen. Netzfilter und Encoder-Kabel mit Batterie fehlen noch (sind noch unterwegs).
Wenn ich demnächst etwas Zeit habe, möchte ich ihn in mein LinuxCNC einbinden und hoffe, dass ich dann ein paar Drehmomentwerte aus meiner Musteranlage bekomme, damit ich die Motoren abschätzen kann, die wirklich benötigt werden.

Wenn ich das weiß und 400 W ausreichend sein sollten, hätte ich Interesse daran.
Wie kann ich dich am besten erreichen? PN geht hier im Forum leider nicht.

Gruß Mücke

It looks very nice and promising, but where can I find more information about the hardware? I tried searching online but couldn't find any results.

I reflashed the default firmware and still same, none of SSR outputs work. It seems that I have to do some manual control for water pump.

Wenn 400W auch ausreichen, dann hätte ich noch kaum benutzte A6-EC übrig. Mit oder ohne Bremse und mit Batterie am Encoderkabel.

github.com/mika4128/liscio/tree/main
new trajectory/gcode compressor for the future trajectory planner, testers wanted, feed your gcode to it, check the SVG output

If you run qtdragon in debugging mode (-d) and run from a terminal or use debugging mode and look at the system log on the status page you should get more info on where qtdragon is looking to do it's checks when the INI MDI button fails.

What I still haven't been able to understand is why QTDragon in neither of its two versions can execute subroutines from MDI with o<XXXXX> call, while with AXIS it does execute them. I think, and I'm not wrong, that it's because QTDragon looks for those subroutines in some specific directory different from the one set in the INI in SUBRUTINE_PATH.

Can this image work with gpio pins?