Advanced Search

Thanks Tommy.

Figured it was program as it all worked on the first cut.

Turns out I had to drop the high voltage arc ok from 250 (which is the setting on my machine) to 200. Once this was done it activated arc ok ever time.

Cheers

I've got a new install on an RPi4 with a 7i92TF and an MX3660.  The DB25 is on a ribbon cable with a third cable end pressed onto it.  I have A step/dir on pins 8/9.  The MX3660 does also use 8/9 but only to drive isolated outputs that aren't connected to anything.

IIRC I used the Geckodrive G540 flash on the 7i92.  The readhmid is enclosed.  DB25 8/9 should be stepgen 03.

I don't have homing set up yet.  XY jog fine.

Initially, I saw XYZ axes moved ok but then I tried to jog A and both A and Z moved.  That's as best I recall, it was late last night.

I looked at what I had in the hal and, ok, the joint and stepgens for A were off like that.  IIRC what I saw had A on stepgen 2.

I did the logical thing and X=Joint 0 stepgen 0, Y=Joint 1 stepgen 1, Z=Joint 2 stepgen 2, A= Joint 3 stepgen 3.  Order XYZA.  HAL/ini enclosed.
At least that's what I tried to do.  The machine thinks differently, I keep looking for the prob in the hal/ini but I don't see where the typo is.

The problem is, any attempt to jog to Z (keyboard, MDI) won't physically move anything, although the Z in AXIS does increment.  
But, if I select the radio button for A axis, or use the MDI on A axis, it moves both the A and Z.

I unplugged the A-axis DB25 tap.  Z commands won't move the Z, A commands do still move the Z, but of course A is disconnected so it won't move.

What am I missing here?

Also setting FF2 should be done with halscope.

Muftijaja wrote:

Hi tommylight, i just followed the advice from PCW in an earlier posting: "...and change all joint PID "P" terms to 666"

That was correct back then when you had the servo period set at 1.5 million, it is not correct when you changed the period to 2 million.
1 million = P 1000
2 million = P 500
0.5 million = P 2000
etc.
And sorry, i missed the part with FF2.

I think you may have moved past this but the only network latency issue I can think of is that energy efficient Ethernet is enabled. This can cause intermittent latency spikes you are experiencing. The method to fix is different between Intel and Realtek device but I do mention them here
docs.google.com/document/d/1jeV_4VKzVmOI...diY/edit?usp=sharing 

Hi PCW,
well I have had FF2 at 0,003 when the errors began and just tried 0,005, then 0,008, just not knowing what it does. I point out, that my servos (OMC 400W integrated drivers) do not send any feedback to the Mesa card, they have closed Loop Drivers/Encoders.
I can see the following error in the tuning software from OMC, but the numbers are not in any correlation to numbers in LCNC and INI file.
Is it better to leave FF2 at 0 or less than 0,003?
INcreasing FERROR = 0.1 or MIN_FERROR = 0.01? What could help more?

Thanks for your advice!
Greets, Hanno

Went through this twice, still have no clue what ...
We have a modern THC, fully implemented in LinuxCNC, including PID and closed loop and everything, with a bit to much added functionality for my taste. All made possible by Mesa THCAD.
Have a look at PlasmaC and QtPlasmaC, everything mentioned is already there and working properly, and much more.
THC has a single purpose: to keep the torch the set amount of height from the material while cutting.
Everything else are added features that a THC might or might not have, be it in software or hardware.
-
Proma THC 150 SD is the stand alone version that intercepts step/dir signals from Z axis
Proma THC 150 sends UP/DOWN/ARC OK signals to PC, and the PC makes the moves, so not stand alone, and can be considered closed loop for sure.

Hi tommylight, i just followed the advice from PCW in an earlier posting: "...and change all joint PID "P" terms to 666"
OK, i will do that and also correct the stepgen max velocityto 160.
FF2 has been also an advive from PCW - I have Servos with integrated drivers, no feedback to the MEsa card.
"You might try plotting the following error and perhaps tuning by adding a little
FF2 (say .0003 to start) to the PID loop (using the calibrate menu so you can do this live) "
I'm just doing what I've been said to.
Thanks for your hints!
Greets Hanno

The best plasma controllers don't have a THC. Instead, the torch height control is done internally by the motion controller. Because the motion controller is all seeing, it knows when to apply anti dive and other corrections because it is THE MOTION CONTROLLER.

This is the approach Linuxcnc takes if you use QTplasmac plasma controller GUI. QTplasmac and its plasmac component take full control of the X axis so motion commands are only in the X,Y axes. In fact, any Z axis motion is stripped out of Gcode files when they are opened.

All you need to do is to feed Linuxcnc the torch voltage and it can use its robust PID routines to control the torch height. You can do this with a THCAD2 from Mesa electronics or in an Ethercat world something like a Beckhoff EL3162.

The THCAD2 is a voltage to frequency converter. It is connected to an encoder and the frequency is converted to a voltage inside Linuxcnc. The EL3162 reads the (divided) voltage directly.

There is a very high linear correlation between torch voltage and torch height so torch voltage becomes an ideal process control variable for torch height control. This is outlined in the Plasma primer in the docs. linuxcnc.org/docs/stable/html/plasma/plasma-cnc-primer.html 

The capabilities of Linuxcnc already far exceed anything from Centroid as the collective minds of open source provide much higher intellect than can be achieved by a closed team.
 
Open loop drives are ideal for plasma use because there are no irregular cutting forces so the system is perfectly predictable. A correctly designed open loop stepper system will use the enormous low down torque to provide high accelleration to minimize the times when corner lock is required. They will only loose steps if the original design is poor.

Linuxcnc does not care about what drives are in use as it just works in device units. Open loop, closed loop, analog, step and direction, ethercat are all the same once installed and configured.

That's a really nice improvement, can't wait until the next release to try it out.

Actually, having a small amount of FF2 improves the following error
(the actual amount should be the time between reading the position and updating the output
though 0.005 seems large)

It may be necessary to take a look at the following error to diagnose the issue
(this will also allow for tuning of the FF2 value)

Increasing the following error limits should not hurt either

Thanks for all the hard work Scott. The PIO install went really smooth, all I needed to do was update my ststm32 lib and it compiled no problem. Next steps for me is doing a H723 port, and figure out how this new repo works. Regarding hardware abstraction, (as always) I have notes on that based on the PIO stuff I did with Drew on the W5500 ethernet branch.


Hmmm call it something like Remora Motion Controller or something? ReMot? ReMOC? RemoraCNC?

Maybe GrblGru with this Extension:  ?

Maybe because I want to use the power of LinuxCNC for something that is not a mill. Like a pick & place machine that would adapt the position according to a vision result

Well, you can, but you need to use the python module.

Nice nice nice... This document is tasty and it is a new galactic space for everyone from us... 

Sinamics are widely used for everything and they are very powerfull.. 

every shared picture is are helpfull i think if you will need help I am here for everyone.. i will create a dry project in the twincat3 to check configuration ...