Rods "Spaceship" Scratch built Plasma Cutter build

Well, I have not got much to report for the last week or so other than that I've been insanely busy. I ordered a couple of DM542-A steppers from Longs Motor on eBay and I asked them for a quote on expedited shipping and they turned up from China in under a week! I wanted to swap out the one i let a little bit of smoke out of and also ensure I had one for a rotary axis down the track because I have a stepper equipped rotary table and my 7i76e still has an unused step gen on it.

I shipped off the faulty power supply but have not heard anything about it yet. I have not had time to rewire the NEMA34 steppers to use parallel wiring and up their power feed to 4 amps to make use of the extra power. I am sure this will increase performance.

I still have not investigated my gantry limit switch wiring faults but I have got most of the gmocappy plasma pins connected, bench tested and working. But I know I will end up modifying the GUI interface.

I've been spending a fair bit of my time on this thread
forum.linuxcnc.org/38-general-linuxcnc-q...010-plasma-questions

And I have been following Rick G's experimental THC on this thread
forum.linuxcnc.org/10-advanced-configura...190-thc-experimental

I ordered an external Analog to digital shield for an Arduino in the hope that I can write some code that will sample arc voltage.

I've also spend some time getting to understand the current THC source and also how to code PID controllers so I could experiment with a PID controlled THC..

With what time that is left, I've been trying to sort out how to make a part that I'm currently purchasing from a vehicle manufacturer that is included in some products I manufacture and have been talking to foundries, tool makers, 3D CAD guys and even metal testing facilities without impacting on my real job during working hours! I think I feel like Tommy!

All of a sudden the penny dropped with PID controlled THC's today. I had it in my head that you would compare the desired height with the current height and issue a move to the desired height. But now I realise its all about the velocity the torch is travelling along the Z axis..So if its a long way from where it should be, it will have a high velocity to catch up but if its at the desired height, the velocity will be 0. So all of a sudden, PID actually makes sense to me as we can control a continuously variable parameter (velocity) to seek the desired voltage. In other threads I read, people raised concerns about PID while the arc was being established. I think this becomes simple, you just disable the PID until the arc is established. Or even better until such times as you sample the arc voltage at desired cut height. During this journey of discovery, I think I now know enough to implement a THC in conjunction with LCNC's PID component. Whilst it would be easy to include a PID control within a THC component, this is not in keeping with LCNC's modular approach so I think the external PID is the way to go.

I also sensed (rightly or wrongly) that PCW is disappointed that hid THCAD cards are only being used for simple bit bang THC control. But then again based on a couple of threads that seemed to fade away with out a result, maybe BigJohnT has had a go at this in the past before settling on the current THC component that seems to be the basis of most variations of torch height control I've found.

Anyway, I've only got about a week before my laser cut parts are available so the whole custom PID controlled THC will probably go on the back burner for a while but I can see that I will have to have a go at coding a LCNC PID compatible THC component.

rodw wrote:

And I have been following Todd's experimental THC on this thread
forum.linuxcnc.org/10-advanced-configura...190-thc-experimental

I think you are giving the wrong person credit.

Todd wrote:

rodw wrote:

And I have been following Todd's experimental THC on this thread
forum.linuxcnc.org/10-advanced-configura...190-thc-experimental

I think you are giving the wrong person credit.

Todd, quite right, it was Rick G.

You also deserve heaps of thanks for your guidance as without you and many others I would never have got to this stage but I will update my prior post.

I'm probably being thick but if you are controlling the velocity with PID what is making the decisions around the size of the move of the Z axis? Is that part of the same PID? Or is there another module I have missed understood from the thread doing this? I recognize that 0 velocity means no move but a non 0 velocity still needs a vector to operate on, yes?

Joco wrote:

I'm probably being thick but if you are controlling the velocity with PID what is making the decisions around the size of the move of the Z axis? Is that part of the same PID? Or is there another module I have missed understood from the thread doing this? I recognize that 0 velocity means no move but a non 0 velocity still needs a vector to operate on, yes?

I've not done anything with PID yet at all other than to research how to code it.

Distance of a commanded move does not come into it. If I am right, we just need to worry about the velocity the axis is to travel at for the next PID time period.

The vector is the Z axis and LinuxCNC has a pin that tracks at what velocity the joint is moving at with the sign designating travel direction. So if the THC was tracking the desired volts within the dead band we want, Z axis velocity would be zero as it is not moving. Outside of that deadband tolerance, the PID would return a velocity (and therefore direction) that the Axis should be moving at for the next PID time period to return to a zero state.

You have however, brought the spaceship back to reality as I have to work out how to tell the Z axis to be moving at this calculated velocity. I thought the current THC was already doing that int this line of code, but maybe its not..

If we do have to add a distance to travel, couldn't that be the calculated from the desired velocity and the distance that could be travelled in the next PID timeperiod?

Well I'm trying to come at it from first principles while lacking a whole lot of context you and others probably already have re the inner workings of linuxcnc in this space. So if I'm raising a red herring just say so.
But I would expect something needs to be deciding how many steps the stepper motor needs to turn before stopping. So while the velocity can set the rate of movement and the sign sets the direction on the fixed axis (Z) something needs to say how long do I keep moving? Or can the movement signal be continuous and the velocity just sets the size and +\- of the resulting vector at any given point in time? The risk might be that your head oscillates a bit on the Z as it tries to settle. Of course good tuning of the dead zone could solve that

Joco,

I probably don't know much more than you. I may have it wrong. I don't think you need to control distance becasue you don't do that with a cruise control in a car. It just controls velocity (eg. Speed).

You made me dig though a lot of stuff to see if I can independently control an axis the way I want but I think the concept is sound. It will just be how it is implemented within the constraints of LinuxCNC.

Hmm, this does the trick!

linuxcnc.org/docs/html/man/man9/stepgen.9.html

stepgen has two control modes, which can be selected on a channel by channel basis using ctrl_type. Possible values are "p" for position control, and "v" for velocity control. The default is position control, which drives the motor to a commanded position, subject to acceleration and velocity limits. Velocity control drives the motor at a commanded speed, again subject to accel and velocity limits. Usually, position mode is used for machine axes. Velocity mode is reserved for unusual applications where continuous movement at some speed is desired, instead of movement to a specific position. (Note that velocity mode replaces the former component freqgen.)

And for Mesa cards which i'm using, there is a setting to select this mode.
linuxcnc.org/docs/master/html/drivers/hostmot2.html#_stepgen

13.1. Pins
control-type - (Bit, In) Switches between position control mode (0) and velocity control mode (1). Defaults to position control (0).

rodw wrote:

Hmm, this does the trick!

linuxcnc.org/docs/html/man/man9/stepgen.9.html

stepgen has two control modes, which can be selected on a channel by channel basis using ctrl_type. Possible values are "p" for position control, and "v" for velocity control. The default is position control, which drives the motor to a commanded position, subject to acceleration and velocity limits. Velocity control drives the motor at a commanded speed, again subject to accel and velocity limits. Usually, position mode is used for machine axes. Velocity mode is reserved for unusual applications where continuous movement at some speed is desired, instead of movement to a specific position. (Note that velocity mode replaces the former component freqgen.)

That's the business. Velocity mode gets you your continuous movement signal I referred to so your +/- acceleration approach should work. I hope you have a chance to get to it. Looks like a promising line of investigation.

Cheers,
J.