Advanced Search

update again

Okay, I don't think I've done a very good job of explaining what I was getting at and why. I also think in retrospect the suggestion of a modern THC may have been taken as an offensive dig at what's already in LinuxCNC - It's certainly not intended to be that way and my thoughts are not aimed at any one platform.

I'm in full agreement that an integrated system offers many tangible benefits over the completely separate systems that you can buy off the shelf today, both in terms of anti-dive and also in terms of co-location of configuration.

The point I was trying to make was that the standalone hardware that we have today is a frankly weird setup, which seems confused about responsibility. The Proma SD is the perfect example of this confusion, but even the non-SD version is still a bit confused.


To try and make my point clearer, consider motor drivers. The old way of closing the loop was to run everything back to the motion controller and have a dumb motor driver (or amplifier). The "modern" approach is to have two loops - A "smart" driver which closes the loop with the hardware, then a second closed loop between the motion controller and the motor driver. (Step/Direction out, fault in) The advantage of the new approach is that each unit is smaller and better defined, it allows you to change the motor/driver combination for any which follow the same contract. It also allows for a higher bandwidth control loop on the motor side of things.


My thoughts were the same for THC:
- The current standalone solutions are weird. (See above)
- The software solution is very similar to the old analogue motor driver solution, with one massive control loop over the top of everything.
- It therefore stands to reason that there's a version of the standalone solution that deals with target arc voltage rather than position, with two closed loops that are more akin to the modern drivers that we have. A solution which still supports the software THC benefits of anti-dive support. One which would be applicable to all motion controllers, just as motor drives are today. One that could even communicate with the motion controller over Ethercat.

In this scheme, the motion controller gets much simpler. It doesn't need to know or care about anti-dive, or how to pierce and dwell, or to know when to strip out Z motion or really know anything about plasma. It just needs to output coordinated target arc voltage as it does the positions for the other motors (Strip the units and Volts are the same as mm or inches to the motion planner), and it needs to output the current motion velocity so that the THC can deal with that complexity.


Is that a clearer and less offensive way of explaining it, or am I just spouting nonsense? I'm sorry if I am, it can be hard to explain something when it's stuck in your own head.

Thank you very much, that looks like just what I need! Now that I know the name of the component, I've been able to find other threads on it as well.

What's the difference to linear scales with glass scales?

Ohh i write all text in german...

@tommylight
i have 5,14v on multimeter

@FPM 
not any from that thread...
i will show what i make and my outputs
maybe you can help me.

ip a:
sudo chrt 99 ping -i .001 -q 192.168.1.121


sudo nano /etc/network/interfaces



Tomorrow i will try the rest from the thread

Hi rodw,
thank you, I have the DKMS r8168 driver installed weeks ago. I try this tomorrow:
Optional kernel settings (install using grub-customizer as per isolcpus setting)
r8168.aspm=0 r8168.eee_enable=0 pcie_aspm=off loglevel=3
I did not test them individually to see which helped but I suspect that disabling the "Energy Efficient Ethernet" mode might be a good culprit.
Ethernet efficiency mode has to be switched off in BIOS, right? OR is it in the network settings in Linux/Debian Network manager?

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.