Rods "Spaceship" Scratch built Plasma Cutter build

robertspark wrote:

--- presume you know that the eoffset_pid was updated 8 days ago (not sure that the change was though) but it may have been a tuning / bug fix if you've been busy with life + work.

Yes, I need to catch up before going further. See my comments above as to why.

Ahh.... that explains it.... (sort of)

If you update the eoffset_pid, you probably want to reset the k factor to 10000, given it's now calculating / correcting for metric conversion
// Make pid gains settings comparable for either inch or mm
// machine-unit specification. With k=10000, 1 count is scaled
// by the axis.L.eoffset-scale == kreciprocal or: 1e-4in ==.00254mm
kfactor = kfactor / (25.4 * units_per_mm);
kreciprocal = 1/((float)kfactor);
dbg_state = the_state;
is_off = !is_on; // convenience pin
the_feedback = feedback;

or comment it out..... (if you're running an imperial machine)

Is there not a flag (setting / config setting) in linuxCNC that tells the machine if it's setup as metric or imperial? given linuxcnc uses G20/G21 I presume there must be a setting somewhere, Ii.e I would have thought that the HAL file would have used this as an input to toggle the scale factor if required (25.4 or 1) to be applied.

If you have the time, there is a really good explanation of PID that was done for the development of the PID algorthm library for arduino here:
brettbeauregard.com/blog/2011/04/improvi...rs-pid-introduction/

One thing I suspect that the eoffset_pid will suffer from will be jerk if the setpoint is changed during the cut.... (whilst this may be unusual it is possible if you had a PMX45XP [of like I hope to hack my PMX45] be able to control the current setting on the fly so it may allow me to lower the current at the end of the cut or in the corners where I could slow the angular velocity down and therefore have less effect of centripetal acceleration ....

This is discussed here:
brettbeauregard.com/blog/2017/06/proport...easurement-the-code/

Well I think I've finally got the noisy Torch voltage signal under control. Initially, Everlast suggested I try soldering a bypass capacitor on the raw voltage where it enters the CNC voltage divider board.

This did nothing. So I decided to purchase a cheap USB oscilloscope and measure the divided voltage as it entered the control box. With the control box turned off thetorch voltage had a nice 50 Hz mains ripple

When I turned the control box on, the signal was swamped with noise.

I was pretty disillusioned at this point and a couple of weeks later a mate who knows more about electronics than I do suggested that I install a mains EMI filter on the raw voltage signal. We figured that a 250 volt rated filter would handle 300 volts DC with no problems. This proved pretty easy to mount in the case right over the raw arc wires so it was real easy to snip the wires and solder them in.

While I was at it, I also replace the IEC mains connector on the control box with a EMI filtered version.
And voila, the noise was gone when cutting. I really hope this is a permanent fix!


So here's a video cutting a couple of parts to repay my mate.

Very nice to see that you found the error.

So with some recent wins, I've spent this weekend working on building a live working system based on the external offsets branch. I have not got as far as cutting anything yet, but I think I've got the config working based on dry cutting. I think also I've isolated an error in the eoffset_pid default settings for the Torch simulator that makes the volts per mm out by a factor of about 4. I'm hoping that if I correct this, I should be able to get a reasonable THC PID tune without doing much cutting.

Fingers crossed from here.

tecno wrote:

Very nice to see that you found the error.

Thanks Bengt. I really hope it is solved for good now.
Rod

Rod,

Just a suggestion for consideration

On the centre punch mark, it appears that the torch is dropping to cut height before the M5.

This will make the hole slightly larger than it needs to be as the cut time will be longer than it needs to be + you have the potential for dropping the torch into the pierce pool.

Instead change your macro to just either dimple the hole (your drills will stay sharper for longer as the hole will not be so hardened) {i.e. a very fast pulse}

Or change the macro to wait for the arc OK, then the pierce delay and then torch off without dropping to cut height.

If you are cutting 10 holes that is 10 times you are dropping the torch potentially into the pierce pool / splatter and increasing the chances of crud sticking to your torch consumables.

Rob

Robert,

Thanks for the tip. I think there are a few things wrong with my current Sheetcam Post on top of the hole marking. Somehow sheetcam duplicated some holes so several were double drilled which compounded the issue.

I think the external offsets needs a totally new POST as it does not use M3/M5 to control the torch on and off and some of the parameters are a bit different to what I've been using

If anyone knows how to retrieve the current state of G20/G21 (Imperial/Metric), please let me know. It took me a while to realise the probing measurements I set in mm was being seen as inches so it would be nice to be able to be able to send it both. I'm hoping my efforts will find their way back into the external offsets branch.With a couple of recent updates the branch has become really polished and there was even some talk of it being merged into master branch on the mailing list the other day (Of course I voted yes!)

Rob,

You have my email address if you want me to look at the post processor for you

You answer may lie here for G20/G21 (depending upon what you want to do with the knowlege)

linuxcnc.org/docs/html/gcode/overview.html
see section 3.4


#<_metric> - Return 1 if G21 is on, else 0.

#<_imperial> - Return 1 if G20 is on, else 0.