THC2

Bold but foolish. I was wrong and I corrected my post and officially declared I am an idiot! He snuck that in after I printed the source.

For the benefit of others, now I have the latest external offset code that contains a couple of new pins, my take on the eoffset_pid is that:

1. Corner lock is always enabled. If the velocity falls below the minimum_vel pin, the current correction is held constant (ie the Z axis does not move).
2. If the new pin hold_request is true, the current correction is held constant to allow an external pin to hold height corrections.

So to implement a kerf crossing feature we just need to enable the hold_request pin when a rapid increase in torch voltage is sensed. Initially, After a bit of research, it seems this can affect cut quality at the end of a cut (say a hole) when the initial leadin is encountered and this can leave a divot so it is a feature that should be implemented but can be done externally without modifying the eoffset_pid component. Thanks Dewey!

Hello

I am very close to installing my new controller on my table. There is minimal internet access in my shop (slow WIFI only) so updates from the web will be cumbersome after I make the move. So I need to bring my system up to the latest releases of 2.8 pre1 and external offsets. I use Gmoccapy and the last external offsets I built didn't have the latest version. What is best ( most reliable) method to do this for a non linux user?

John

John, just do a checkout on the external offset code. Dewey rebased it with master on 8 April so it is all but up to date and will have picked up any gmocappy updates as Norbert pushes them to master.

If you click on the dots beside Deweys name in his git branch, you get the branch history so just keep an eye on that. Eg.
github.com/LinuxCNC/linuxcnc/tree/dgarr/external_offsets

I played with merging branches and I reset it all as I think I got myself in a mess but it could have been a faulty proximity sensor. I think I posted my git commands on my build thread to merge branches. I will just be patient and wait for Dewey from now on. I have noticed he rebases with master fairly frequently.

Its good to see Dewey's progress on the eoffset_pid component.

I've been writing a cornerlock helper application to interface between eoffset_pid and the Gmoccapy plasma screen. I think there is a gap between the current version and reality.

Generally, as is done in Gmoccapy, Cornerlock is specified as a percentage of cut velocity. In the eoffset_pid example, the cut velocity is set in gcode so it is not currently accessible in HAL. Gmoccapy allows the operator to control corner lock threshold on the fly.

In the current invocation, it seems that the operator has to know for example that this job is to be cut at say 5metres per minute and cornerlock should turn on at say 4 metres per minute.

I think that hpid_sub.ngc should be modified to use a M68 command to sent the cut velocity to an analog output where it can be seen in HAL. This will then allow gmoccapy control of the cornerlock threshold.

Rod

Yes, as you have previously discovered most of the connections from Gmoccapy plasma screen are broke or don't really exist. I just used a bunch of HAL to get things working, yes, you must modify the the Python handler and HAL code to get the scaling and connections right. I will post the code in the middle of the week after I finish with taxes. Still don't have a live machine ( well actually the Z axis is) but it all works on desk top monitoring pins in halshow. I use a lot of MDI commands while testing. Just finished up user controlled filtering of the arc voltage and kerf crossing which are all the features I intend on using at this point. This took 4 custom components to get working easily. Screens aren't pretty but are functional. Still have a few bugs that I know of, the biggest one is that the saved configurations from one session to another don't always reload properly. The files that the configurations are saved to are written correctly every time.

John

Rod

I have found in practice that the corner hold really is a relative function of torch speed. I typically use 75 to 90% of torch speed as the lock point. Dross is dramatically worse when you are at 75% of ideal speed and not too bad at 90% of ideal speed. I also lock torch height when cutting small inside circles and inside open lines that I don't want powder coating to close.

Remember that all your set points for corner holds (or Velocity Anti Dive as one commercial group calls it) need to include the feed override offsets. You will find the using feed overrides are very handy when setting up and running one off cuts.

John

John, I think the issue I raised is a real one and not just specific to Gmoccapy as there is not really a method to set the minimum velocity on the eoffset_pid comp. It wants an input in machine units per second and machinists don't think that way. The example sets #<feed_rate> so it really needs to be sent back to HAL. But then it needs to be converted to machine units per second before it can be used. If you are going to set the feed rate (cut velocity) in gcode, then it needs to be able to be used to set the corner lock velocity which presently it can't.

And yes, I am persevering with Gmocappy as the allure of a touch screen is quite strong....

I have now written 3 components and aside from correcting some errors in the Glade files (like LED's with the same colour for on and off states), I am leaving them alone. Some of the components I have written have replaced some obscure Hal commands to make my config more understandable and easier to maintain. It would be nice if these eventually find their way into a future version of linuxcnc as it would make it so much easier for the next builders. I think the key to bring Linuxcnc Plasma into the main stream will be a series of modular components that can work together to build a complete system. I will post them up as I get them working and properly documented (Dewey sets a high standard there!).

I've built lowpass arc voltage filtering into the SCALETHCAD component I've shared on its own thread. It could have used the existing lowpass component but it already had some of the required inputs, so it simplifies the hal file. My next component is likely to be the kerf crossing. I don't really think this will bite me but it seems it should be an included feature. I know it needs to watch for a rapid change in voltage over time but I don't know what is a reasonable threshold to use as a default.

I still want to have a go at a touchoff component that includes auto volts sensing.

Like you, I don't quite have a live machine and I've had a few setbacks that have held me up a couple of weeks but it is getting closer.

Rod

I just checked the eoffset_pid.comp source again. I doesn't matter what scale the velocities are in as long as they are the same one. The velocity values are only used in a comparison in an if statement and not used in the calculation.

Yes you can use motion.requested-vel ( it is in machine units/s) as it will have the feedrate set by the gcode. Don't worry about the Z component because when you are in the cut you shouldn't be making any gcode commanded Z moves. When you are starting the cut the THC should be disabled.

Kerf crossing is one of those things that are nice but not necessary for the hobby user. For cutting holes you usually either freeze the torch height (small holes) or the corner hold will kick in at the end of the cut where you are going to cross the entry kerf. Kerf crossing is used at large commercial shops that do a lot of chain cutting to save on pierce wear and time when cutting full sheets. I have no idea what the required range to switch is. Right now I can set 1 to 99 V/ms rate of change as the setpoint.

I have set my filtering up to adjusted by the user for now. I am not sure what the required set points actually are. I have heard mention that Hypertherm wants 25Hz or higher corner frequency. I know varying the filtering corner frequency is used in some Mach and in Command CNC versions to control torch hunting. I can switch between using the biquad and the lowpass filters. Both had to be modified to allow setting the corner frequency on the fly. Right now the user can select Fc from 10 to 100hz.

John