Advanced Search

An important aspect to keeping as much smarts in LinuxCNC as possible is that
complex control systems (like plasma control) work on all supported hardware. As
long as  LinuxCNC has enough control bandwidth, its an advantage to have a single
portable extensible and flexible solution with a single control locus (that has access
to all motion variables)

Do you really want to re-invent and maintain a control system that LinuxCNC can
do internally just as well? Buffered systems like Mach require this type of external
hardware, real time systems Like LinuxCNC do not.

 

but in theory, a Grbl component could completely replace the EMCMot+Stepgen components in LinuxCNC for stepper motors signal generation.


Hmmmm ok

OK, this i did not need to read twice, but from it now it seems you are searching for a problem that already has a solution, well several solutions.
The reference to old dumb drives is a bit disrespectful to old drives, they built the industrial complex we call modern ages, and it worked perfectly well for over 50 years.
Still, with a bit of tinkering, you can get a decent stand alone THC, probably using an ESP32 as it has 12 bit AD inputs, it can control stepper motors so everything on the Z axis can be controlled by it, it can do very fast PID loops, and adding void detection is as simple as checking the voltage rise time with delta-V/T or time.
A 3D printer screen with encoder, a nice simple menu, and that's about it.
-
There was a discussion here about adding controls to old plasma sources to change current from LinuxCNC, but that is not important anymore. Some relays would do the trick easily and some HAL wizardry.
This just shows the flexibility of LinuxCNC to adapt it to whatever is required, hence keeping stuff in LinuxCNC seems much more useful.
And, yes, QtPlasmaC has the ability to control plasma sources through RS485.
-
All this is in no way, shape or form meant to discourage you from trying to make such a thing, and i would gladly help and test whenever possible. I have plenty of CNC machines and plasma sources and ESP32 and 3D printers and...

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