Advanced Search

The auto-tuning function of the A6 series servo motors is limited to basic gain adjustment. In most cases, manual tuning based on actual operating conditions is required (refer to Chapter 6 of the manual).
What you might be looking for is a one-click auto-tuning feature similar to [other systems], but this functionality is currently still under development. The tuning interface in the software can only automatically identify inertia - all other parameters need to be manually adjusted.

Hello! My team and I have been setting up a cnc using a raspberry pi 5 running remora to an octopus pro with spi, this then uses 4 Ext motor v1.1 to generate the steps using stepgen in the octopus config to generate movement with some DM556 drivers these are wired directly to the steppers. We have been having issues, when we boot LinuxCNC an error appears, raspberry pi 5 using rp1 driver. We belive this to be a warning to tell show that the rasp5 got recognized.

We haven't been able to enable the stepper drivers, the e-stop is working. We can enable but the moment we try to jog we get a joint following error this, caused by  the drivers not getting enabled and not getting any movement. 

Any ideas on what we could do?

Made some progress on reproducing the issue:
forum.linuxcnc.org/qtvcp/57033-basic-pro...ails-on-latch-return

I have, what I think, the same problem. I'm able to reproduce this, posted a new thread that I hope get going for the issue: forum.linuxcnc.org/qtvcp/57033-basic-pro...ails-on-latch-return

So, this is going to be a lengthy post. I'm having trouble with qt_dragon_hd and probing via the "Basic Probe" interface. Sometimes, probing fails sporadically for no reason. What happens is that when I probe towards Z- (towards the work piece), when the probe tip hits the target, it stops there and does not retract for a slow probe.

Up until yesterday, I had not been able to reproduce this error consistently. But now I can, and it might be easier to track this issue down.

I'm on 2.9.4, running a MESA card for my router. I have been able to reproduce it and have taken status dumps in between every action I do to reproduce the fault and actually resetting the fault so I can make one probe action again, instead of restarting LinuxCNC.

I have seen other people having similar problems that I think are related to this:
Thread #1: forum.linuxcnc.org/qtvcp/54027-retract-n...-works-after-a-while
Thread #2: forum.linuxcnc.org/49-basic-configuratio...e-with-qtdragon-hang

So, the first procedure for me to reproduce the issue:

• 1: Start LinuxCNC and home all axes.
• 2: Load the 3D probe and issue an "M61 T99" in MDI.
• 3: I can now probe several times without issues.
• STATUS FILE SAVE: A3-4_status_after_homing_and_several_successful_probes.txt
• 4: Issue an "S6000 M3" to start the spindle.
• 5: Issue an "M05" to stop the spindle.
• STATUS FILE SAVE: A5-6_status_after_M05.txt
• 6: Issue an "M02" to end the program (should not matter for testing, just in MDI mode).
• STATUS FILE SAVE: A6-7_status_after_M02.txt
• 7: Try to probe, fails.
• STATUS FILE SAVE: A7-_status_after_failed_probe.txt

To "reset" the issue, this works:

• 1: Issue a probing action that is bound to fail.
• STATUS FILE SAVE: B1-2_status_during_retract_halt_probe_fail.txt
• 2: Wait for the 30 sec delay to get the error message "latch return failed" (row 1508 in probe_routines.py, I think).
• STATUS FILE SAVE: B2-3_status_after_retract_halt_probe_fail.txt
• 3: Issue a "G1 Z1 F200" (the same as the probe routine that failed) in MDI. Z will not move after this command.
• STATUS FILE SAVE: B3-4_status_during_MDI_G1Z1F200_after_probe_fail.txt
• 4: Press the "STOP" button in the UI.
• STATUS FILE SAVE: B4-5_status_after_pressing_stop_button_after_probe_fail.txt
• 5: Reissue the "G1 Z1 F200"; now Z is moved to Z1.
• STATUS FILE SAVE: B5-6_status_after_successful_MDI_G1Z1F200_after_probe_fail.txt
• 6: Do a probe; this succeeds.
• STATUS FILE SAVE: B6-7_status_after_successful_secondary_probing.txt
• 7: Try a second time; this fails.

Here is my config: github.com/hmunktell/printNC/tree/dustshoe

If I run the sim.qtdragon_hd_xyz on the same machine as my CNC, probing is working fine and I have not been able to get the issue. Also, on my desktop, in a virtualbox, running the same sim, everything is fine.

I can not really read out anything else from the status files other than that the probing routine tries to do the latch return, but motion is not up to this task. It almost feels like a race condition somewhere, or a flag that is set after the first probe that is then locked from clearing when starting the spindle. But it works fine in the sim environment; it might be that the internals in LinuxCNC are not handled the same.

Unfortunately, I have no other computer to test this on right now. I'm attaching the status log files. If I can assist with further testing, I'm willing to, as this is rather cumbersome.

Best regards, Henrik

Anyone know how to setup two inputs to trigger the motion-probe.input? 
I have a tool height setter and probe. I can only link one at a time it won't allow two input pins to trigger the motion-probe-input. I tried or2 but neither will trigger when I use or2 

I have/had KUKA industrial robots welding and paletizing bricks and sacks with sand, but they used a stripped down version of winxp.
And there are some robots here on this forum running LinuxCNC, just search for Scara robot. Also there should be some configs included with LinuxCNC so you can download the ISO, write it to a USB and boot from it, then run LinuxCNC in sim mode, some sim configs also have visualization so you can see on screen the machine moving.
As for toolpaths, it depends on what you need, some stuff can be done as simple as for a normal router/engraver/plotter, some might need specialized CAM software.

Occasionally, when using 'run' on the 'Test/Tune Axis' panel, for a back and forth test of 2", the movement at the end of travel oscillates around the endpoints. It isn't consistent, it will oscillate for a little bit and then stop oscillating and then start up again. I will try and post a video of this shortly. Any insight would be greatly appreciated!

This typically means that the P term is set too high in the local PID control loop.
For local control loops, P should be set to 1/(servo period in seconds), That is,
1000 for a 1 ms servo thread period or 500 for a 2 ms servo thread period.

The physical meaning of this P term setting is that any detected position errors
are corrected by the next servo thread invocation.

@ccatlett1984
Do not change the subject tittle as it makes it impossible to find when searching.
Thank you.

On the latest Linuxcnc images SPI should be enabled by default, this was an issue I had with the previous releases.
You specify which spidev mesaflash uses on the command line switch as the --addr, spix can be forced to use a particular SPI interface. The Linuxcnc docs for spix are a good read as it points everything out.

Many thanks to everyone who has offered some advice. I found a single stepperonline DM860T stepper driver on marketplace to test with and I now have the x-axis wired to my 7i96 for and moving, more-or-less as expected. I have the driver and Mesa card wired for differential inputs (dir +/- and step +/-). For settings, I'm simply using 5000/5000/10000/10000.

 

For what it is worth, the timing page in the stepperonline manual lists:

• dir must be ahead of pul by 5000ns
• pulse with not less than 2500ns
• low level width not less than 2500ns
  
  
  Two quirks I've noticed:
  1. The max limit for direction hold/setup in the 'Test/Tune Axis' option is 10000, rather than the recommended 20000.
  2. Occasionally, when using 'run' on the 'Test/Tune Axis' panel, for a back and forth test of 2", the movement at the end of travel oscillates around the endpoints. It isn't consistent, it will oscillate for a little bit and then stop oscillating and then start up again. I will try and post a video of this shortly. Any insight would be greatly appreciated!

RPI5 OS with 7c81 Interesting note:
- Leaving config.txt alone creates only spidev10.0 and hal_spix works fine, but mesaflash does not.
- Enabling spi in config.txt (dtparam=spi=on) creates spidev0.0, spidev0.1, and spidev10.1, hal_spix works fine, and mesaflash works fine with --addr /dev/spidev0.0

It would appear that hal_spix just looks for the first spi device, whichever one it is, or scans all of them; and mesaflash explicitly requires it to be on spidev0.0.

Peter? 

Hi, I'm trying to setup an ATC carousel with "style" I could have added an axis and use the standard probe basic marcos but the carousel component is something I would like to learn. 

1) I tried to feed the carousel.0.count-target straight as a pos-cmd getting a following-error, guess due to the sudden change in position, the motor moves a bit then stops with an error.
2) as a second attempt I've added a joint (without axis) to feed the new servo position from joint.N.motor-pos-cmd hoping that the servo would be controlled as an axis but motor.pos.cmd is an OUT pin..

At this point I'm lost, but don't want to give up using an axis, any suggestion?

Attached my actual toolchange.hal

Hello, I've seen industrial robots online that were used as 3D printers, for drawing, or for milling. Does anyone have a robot arm like this in use for such an application? Can this be done with LinuxCnc? Which LinuxCnc version would I need? Are there programs for creating toolpaths?
Thank you very much for any answers.
Hans

Hallo
Habe den Eingang für die Längenmessung Kontrolliert der ist OK.. Bin daraufgekommen wenn ich die Neuen Einträge in der INI Ausschalte dann ist der Bildschirm wieder Aktiv und die Maschine kann man Einschalten (Raute). Wenn der Eintrag wieder aktiv ist dauert es sehr lange bis die Visialisierung kommt und die Maschine kann man nicht Einschalten. Ein VWWersuch mit einen anderen Neuen Eintrag hat das gleiche Ergebnis gebracht. Was stimmt da nicht?
Gruß Hans