THC Start Marks

[islander261]

Hello

I am having some strange "divots" appearing in my cuts at the point the THC starts to servo to the arc voltage. These "divots" are small and only visible from the side or bottom of the cut. I didn't see this happen at all when I did all my straight line test cuts while getting the height control to work. This happens both when the THC starts servoing and when the height hold is released allowing the THC to servo after a height hold event (corner, velocity or kerf crossing). The control is LinuxCNC based using Mesa hardware (7i76e and THCAD). All the control is done using HAL components so I don't think a delay is the problem. I have only found this when cutting full sheets of parts so I haven't been able to synch up the triggering in halscope to get a good trace. Things happen really fast at the speeds I am running so it is hard to tell what is happening visually.

LinuxCNC control.
14ga HR sheet steel, 220ipm cut speed, 45A Finecut consumables, .070" initial cut height, .090" pierce height, air pressure at back of power supply 105psi during cutting, clean dry air.

Has anyone else seen a problem like this? Have any CommandCNC users seen anything like this?

John

[tcaudle]

1' Why are you waiting that long for the THC to turn on?
2. How are you doing that? In the G-Code?

It looks like you are getting a short motion delay when you enable the THC . If you are using a sub routine it must be using the wrong M sequence that is for a static action , not during motion

[islander261]

Tom

Thanks for the reply. I have a delay of .75s on the example cut from arcok or motion enable what ever you want to call it until the THC starts servoing to the arc voltage. This is just the normal start delay to allow the arc to stabilize, really needed with my TD power supply. Looking at halscope plots of the cut start I can shorten this to around .35 second and still always be in the stable arc voltage.

The delay is done in the hal so it is as good as the realtime in the os. The delay can be set from the GUI (as the example photo used) or from the gcode as a parameter past from the PP selected at run time from the GUI. A typical start of cut sequence in gcode is:

Code: Select all

  G4 P.1 
  G4 P0.5 (end of cut delay)
  G0  Z#<_g0-gap>
  G0  X15.647 Y8.731
  G0 Z #<_w-gap>    (plunge safety move)
  o<probe_sheet3> call    (external Touch off)
  o137 if[#<_value> LT 0] 
          M0 
          (MSG, Probing Error!) 
  o137 endif 
  G1  X15.647 Y8.731 (adds in a G1 move to the same location to fix LINUXCNC bug of Run From here)
  G0  Z #<_pierce-gap>   (pierce height)
  M3 S100
  M66 P0 L1 Q3   (wait for ok to move) 
  G4 P#<_pierce-delay>     (pierce delay)
  G1 Z#<_cut-gap>  F150.0
  M67 E0 Q20 (THC is on)
  G3 Y8.842 I-0.110 J0.056 F220.0
  X15.559 Y8.956 I-0.434 J-0.247
  G1 X15.493 Y9.018
  G2 X15.406 Y9.103 I1.562 J1.682
  G1 X15.425 Y9.024
  G3 X15.497 Y8.748 I10.614 J2.629
  X15.567 Y8.607 I0.456 J0.139
  X15.657 Y8.574 I0.072 J0.059
  X15.755 Y8.636 I-0.083 J0.239
  X15.882 Y8.790 I-0.834 J0.824
  G2 X15.761 Y8.823 I0.027 J0.349
  X15.565 Y8.952 I0.232 J0.563
  G1 X15.563 Y8.954
  M5
  o<endcut> call
  M68 E0 Q10 (THC is OFF)

John

[tcaudle]

well. either its hesitating in the motion or the torch climbs at that instant then recovers (less likely to leave a divot). You can't control the cut current of a TD so that's not it. Plasmas create divots when you change the cut rate (slow it down) or momentarily stop . Raising the torch will widen the kerf but typically not cause a divot in a spot. So you are turning the THC on when you have plunged the Z to cut height (?) but you programmed in a delay in the HAL code to delay? What are you doing with the end-of- Cut subroutine? I would think its not needed using an internal software THC.

Average settling time AFTER the move to cut height is less than .1 sec and most sample and holds are done a t .025 seconds in. You do need to sense the XY speeds and trigger the sample only when the speed is 90% of commanded feedrate. I have no experience using the beta THC function in LINUXCNC but doing it all in hardware and using hardware output makes it very close to real time.

[islander261]

Tom

I pulled out the scrap sheets that I did all my test cutting on getting the THC to work correctly. I had no "divots" on those cuts leading me to think that my start of cut "divots" maybe from poor IHS (dross stuck to shield or on sheet). I know the IHS was good on the test sheets because I checked it with a gauge before each cut.

The event flow on my system when I start a cut is:
Move to start position
Lower torch to Safe Z height
Probe for sheet surface (ohmic with float switch backup)
Set work piece offset Z (G92 Z0 or add in float switch offset if float switch used)
Raise torch to pierce height (.090" in example photo)
Close Arc Start contacts (M3)
Wait for "Ok to Move" or "ArcOK" signal or what ever your power supply calls it
Wait for Pierce Delay time (.01s in the example in photo because the TD power supply reacts so slowly and the sheet is thin)
Lower torch to initial cut height (.020" move on example in photos, .070" cut height)
Start XY motion
When THC servo start timeout has expired (measured from ArcOK going true) allow the THC to correct height (done using timedelay hal component with hal component logic)
At end of cut open Arc Start contacts (M5)

You are correct, the end-of-cut subroutine is just a place holder, it has no functional code in it.

I am using a Mesa THCAD to measure the arc voltage. The velocity output (THCAD voltage measurement) from the FPGA encoder reader is updated every servo period (1khz).

I am not using any of the THC components published with LinuxCNC. My THC is put together using standard HAL components with one exception. The exception is that I use the eoffset_pid component to generate the velocity hold signal and to track the z movments when the THC is running to prevent Following Errors on the Z axis when the motion component is not controlling it. Please find attached block diagram.

John

[islander261]

A quick update here. Please find a revise copy of the simple_z_controls diagram. I have added some signals to clear up the confusion over the velocity hold control and fixed a connection so there isn't following errors for joint.3 when the height is held.

John

[islander261]

Well all this has taken a rather unexpected turn. After quite a bit of testing and soothing by rodw and myself have found the problem! Yeah, but not so fast because this more than likely effects everyone who has a table running under LinuxCNC or a rebranded version. This has now been confirmed in release 2.7.n, master branch and external offsets branch. It seems that the definition of in the docs:

motion.requested-vel - (float, out) The current requested velocity in user units per second from the F=n setting in the G Code file. No feed overrides or any other adjustments are applied to this pin.

Is not entirely correct, it seems that it is actually limited by the trajectory planner to make it fall under the constraints as defined in the .ini file. A simple example of this is cutting a sharp corner at high speed, if the table is setup correctly then the trajectory planner will reduce the velocity as reported by motion.requested-vel and acceleration to a value that your table can do. Why is this a problem? Because most if not all THC controls use this value ( should equal the F=n in effect from the G code and not change) to generate the minimum velocity which is compared to motion.current-vel to decide when to hold the torch height when in a corner or at the beginning or end of a cut, this is the velocity anti dive common to most LinuxCNC plasma systems. It actually causes the THC to start controlling the torch height at the worst time when the velocity is lowest.

Ok, some obvious questions. Why haven't I seen this on my system? Well if you only cut thicker sheet (>4mm) and you have 600oz-in steppers or larger (or servo motors) and you are mostly cutting largely rectilinear pieces you are likely not hitting the TP limits and seeing the value of motion.requested-vel reduced. How can I tell if my system uses this halpin? Search your .hal and .tcl files for motion.requested-vel, if you find it then you may have a problem cutting thin sheet at high speed with velocity anti dive enabled.

The developers of LinuxCNC are now working on this problem, the expected solution will be a new halpin that actually follows the published definition of motion.requested-vel. I think we can expect to see the master branch and external offsets branch fixed this weekend. I am not privy to the update workings for the mainline releases so they may take a little longer.

For those of you that are interested in all the testing and discussion about this here is the link:

https://forum.linuxcnc.org/plasma-laser ... t?start=10

Just to reiterate if you mostly cut thicker sheet and retcilinear pieces on a well powered table you will most likely not be affected by this during your normal cutting.

John

[Rodw]

Yes, John has been working so hard on this and I've been following along from the sidelines (being 15 hours ahead of him, maybe I'm leading???). I've confirmed an error in the LinuxCNC docs where the internal pin supposedly representing feed rate (gcode F command) is overridden by the trajectory planner so it is not a constant as per the docs.

So what happens is under some conditions, an unexpected drop in the commanded velocity when the THC is under velocity anti dive control, causes the THC to be re-enabled when travelling at a low velocity. This results in a big, unexpected and incorrect correction in height and resultant cut quality issues.

Being internal to LinuxCNC, this issue will impact CommandCNC if it uses motion.requested-vel as an input to its velocity antidive feature.

The current workaround is to also send the feedrate by an M67 E1 Qnnnn command in your gcode. Then update your HAL files and replace references to motion.requested-vel with motion.analog-out-01. Please check your config to make sure this digital pin is not in use and use another pin if it is (the E1 parameter). Please refer to the Linuxcnc docs for motion and Mcodes for more information.

We had great service from the LinuxCNC development team as this bug reported late last night is being worked on this morning. Some commercial software houses would do well to follow their example.

[tcaudle]

We are not affected by this bug. Velocity Anti Dive in CommandCNC is entirely in the DTHC . Z motion under DTHC is outside LINUXCNC. So is the PID loop. DTHC opeartion and ON/Off are outside the trajectory engine.

[Rodw]

We are not affected by this bug. Velocity Anti Dive in CommandCNC is entirely in the DTHC . Z motion under DTHC is outside LINUXCNC. So is the PID loop. DTHC opeartion and ON/Off are outside the trajectory engine.

Great to know thanks Tom

[islander261]

Wow

I guess the current CommandCNC manual must be in error! I guess that is why it has a disclaimer saying it is only a beta version.

Instant DTHC ON/OFF (hardware control).

Use Hardware Enable PIn (checkbox). This enables the direct high speed DTHC
ON/OFF. Used in conjunction with VAD. Must be ON to use VAD
Velocity Anti-dive % (DRO) The 5 the combined feedrate must drop below for the
DTHC to turn OFF then back on when it reaches 100% The deafult setting of 85%
works well for normal cutting and detailed cuts on thinner material. This also works as

Velocity Anti-Dive. This function is a new and important feature.
VAD is based on detecting the slowdown in the feedrate that
occurs naturally as the torch approaches a corner or slows down
at the end of a cut. The velocity in CommandCNC is handled
differently than most controls. There is a setting that tells LINUXCNC
how far it can deviate from the toolpath. It gives preference of tracking
(accuracy) over feedrate, so it does not round corners or cut across a
turn to try and keep velocity as high as possible. As a result VAD
virtually eliminates all corner and end of cut diving. The Settings
in DTHC SETTINGS tab/ Other DTHC Settings determine the VAD
actions. the Use Hardware Enable Pin MUST be checked. The
default 85% works for most cutting. The higher the number the
more sensitive VAD is.
To use VAD you must: Have DTHC Rev 2 or higher (or a REV1 with the MOD (green
sticker). Contact the factory if you have a rev1 that has not been modified

John

[Rodw]

The beauty of using Open Source software like LinuxCNC, is you don't need to wait for the developers to fix it. I've added 5 lines of code to the linuxCNC core and now we have a new pin that publishes the original feed_rate requested. It still needs to be fully tested before we call it a wrap.

Tom, I'd check with your software engineers again. When I stop and think, the only way your external hardware can know what the feed-rate is is if LinuxCNC tells it via your RS485 link. Currently, the only copy of LinuxCNC that knows the accurate feed-rate and can tell the world is mine and it would need a small configuration change if it was sending it down a serial link to your hardware.

The feed rate in the Gcode only goes to LinuxCNC and it could be modified there by a feed override. Sure, you might be able to parse cutting charts and so on or you could count pulses but thats only an educated guess. It doesn't make sense to implement velocity hold any other way. My guess is that your users will be affected if they are cutting decorative stuff like Islander261 does.

[tcaudle]

Wrong. you don't seem to understand that DTHC velocity and acceleration are not provided by Linuxcnc. DTHC has its own processor and memory . RS485 is WAY too slow to do anything Real Time. The RS485 link can die and it will continue to cut. We do have a watchdog signal to the DTHC from the hub and it shuts off the torch if you lose RS485 but that can be bypassed. We do not even try to inform LCNC what the feedrate of the Z is. The VAD works perfectly on very complex decorative cuts . You can watch the pretty blue LED on the DTHC module flicker on and off rapidly as it cuts the corners and sharp detail . Only data coming back from DTHC during a cut is the Torch Volts (for screen display) and the UP down and Arc OK indicators. All of those functions are handled by the DTHC processor. Linuxcnc never moves Z directly regardless of the mode. I can post some of the designs we cut . Heck I'll even post a video that shows a really complex design cutting and the VAD turning the DTHC on and off. We for sure don't get divots in the middle of a cut of when the DTHC turns on or off

We are about to add real time collusion detection at the DTHC and it can be used to fast retract the Z instantly then tell LCNC after the fact. The problem with thinking in software terms is you see every problem as a programming issue. My team consists of software and hardware engineers and we cross pollinate so we pick the best solution. We had to learn to do that with Windows and MACH and the ESS that has real delay issues .

[Rodw]

My bad, I thought your velocity antidive feature monitored the X & Y velocity and disabled the Z axis/THC like most upmarket systems but you don't mention doing that at all. Realtime is not required for setting feed rate at the beginning of a cut. RS485 is used by Hypertherm to set other starting parameters. Nothing wrong with software when you can write a high performance velocity hold/antidive component in about 12 lines of code. My pretty LED is green and its embedded in the GUI as are the up/down indicator LED's. If you are developing on an embedded processor you are probably still writing C code just like me.

Anyway, the main thing is that your users are not affected by a shortcoming in LinuxCNC you may not have been aware of which was the point of my post.

[beefy]

I only have a technical interest in this chat, but so far this is not making sense, and I'd like to understand it.

Regarding what Rod has just said:
"My bad, I thought your velocity antidive feature monitored the X & Y velocity and disabled the Z axis/THC like most upmarket systems."

Well, what other Velocity Anti-Dive is there ??? There's voltage anti-dive but that is a completely different thing and has nothing to do with velocity.

First thing to confirm is we are on the same page, so here goes. Velocity Anti-Dive is basically turning of the THC or at least disabling THC Z down movement when XY velocity goes below a certain pre-set percentage, correct ??? And this typically happens in corners, etc when the XY travel speed is reduced as the torch decelerates and accelerates with changes in direction.

So, assuming we agree on that one, how can the DTHC (which has its own processor and memory, I know) perform Velocity Anti-Dive, without getting XY velocity feedback in realtime from Linuxcnc. Unless I've missed it, I have not seen anywhere in this chat telling where the DTHC gets this XY velocity feedback.

I could understand if the processor of the DTHC was doing something like monitoring the pulse stream sent to the XY stepper motors and could calculate the XY velocity fast enough, but otherwise doesn't it have to get the XY velocity feedback in realtime from Linuxcnc.

Sorry for the curiosity and/or if the answer has already been given and I've missed it.

Keith.

[islander261]

Well I'm not much for red herrings but I do enjoy the occasional kippered one.

This is surely a case of the CEO not being up to date with the engineering staff work product. I did a little soothing around today to try and make sense out of all of this and found a couple of interesting things. So I found a copy of a _ccc_main.tcl file attached to a mysterious email today. In it I found the following stanza:

setp hm2_7i92.0.gpio.017.is_output TRUE
setp hm2_7i92.0.gpio.017.invert_output 1
net vad-curvel thcenable.current-vel motion.current-vel
net vad-reqvel thcenable.requested-vel motion.requested-vel
net thchwdisable0 thcenable.extdisable0 motion.digital-out-00
net thchwdisable1 thcenable.extdisable1
net thchwdisable2 thcenable.extdisable2
net thchwenable thcenable.out hm2_7i92.0.gpio.017.out
net program-is-idle thcenable.prog-is-idle halui.program.is-idle
net vad-percent thcenable.percent
net velantidive-en thcenable.enable

Well this indicates that CommandCNC does indeed use the halpin that I found the bug on. So I looked a little farther and found the referenced thcenable.so hal component. A quick man references yielded this little gem:

license:GPLv2 or greater
author:Moses McKnight
component:thcenable:Turn off output when disabled, or when current-vel < percentage of requested-vel

Well from these two code snippets there is little doubt that CommandCNC uses the motion.requested-vel halpin to take some kind of control action on the external THC through the hm2_7i92.0.gpio.017.out pin on the 7i92 card.

John

[Rodw]

Very interesting John. So CommandCNC users doing decorative cuts would be well advised to follow the advice I gave earlier in this thread (changing the file name to what its used).

The current workaround is to also send the feedrate by an M67 E1 Qnnnn command in your gcode. Then update your _tc_main.tcl file and replace references to motion.requested-vel with motion.analog-out-01. Please check your config to make sure this digital pin is not in use and use another pin if it is (the gcode E1 parameter). Please refer to the Linuxcnc docs for motion and Mcodes for more information.

The bad news this won't be an easy fix. The workaround I coded failed on further testing.
motion.requested-vel represents the requested velocity for a specific cut segment after adjusting for machine and trajectory planner limits. Sebastian, one of the lead LinuxCNC developers said:

This is all to say: Motion doesn't know the programmed feed rate, it only knows the requested velocity of each segment. This requested velocity is generated by Canon (the interface between the Interpreter and Motion, inside Task) based on machine constraints.

After a few hours studying the code looking for a solution, it became obvious that the feedrate from an F code is thrown away in the Canon module and an adjusted value sent to Motion. Canon is unable to access any global variables used in the Motion and Task modules.

The solution requires merging an experimental branch "State Tags" into LinuxCNC master branch and from my observations, development has been stalled for about 8 months. The best I've achieved is to get the erroneous documentation corrected in both the master development branch and the stable 2.7 release. I guess that will roll out to the Linuxcnc web site as part of their normal release schedule.

This plot I generated of cutting one of islander261's files at 220 inches per minute shows the magnitude of the fault.

The stepped line is the requested velocity (feed rate) and the jagged line is the actual velocity. You can see that in places there is a massive fall in the requested velocity so all of a sudden the THC is enabled at very slow velocities and this results in the divot illustrated by John at the beginning of this thread.

I'm really disappointed by the arrogance of CandCNC over this matter. Early in this thread, Tom provided some really useful information which I acted on and when I return the favour by alerting him to a problem that probably affects his product, I am treated with untruths and scornful disdain. I won't be so keen to share a software solution to this problem if an idea I have works out in practice.

[beefy]

Very interesting John. So CommandCNC users doing decorative cuts would be well advised to follow the advice I gave earlier in this thread (changing the file name to what its used).

I'm really disappointed by the arrogance of CandCNC over this matter. Early in this thread, Tom provided some really useful information which I acted on and when I return the favour by alerting him to a problem that probably affects his product, I am treated with untruths and scornful disdain. I won't be so keen to share a software solution to this problem if an idea I have works out in practice.

Ha ha, quite normal for Tom in my experience.

I started off with a Candcnc product but out of principle decided I could not buy their later and better products. Had I experienced sincerity from Tom in the years subsequent to my purchase of his product, I would certainly have one of his products today. However, I now believe that if there's any "difficult" issues with his gear, he'll do his best to circumnavigate the problem. So I changed to Cncdrive products with a Neuron THC and am very happy. So far all I've seen is sincerity with any problems that are brought up.

My experiences of Tom has led to my opinion he often attempts to "baffles people with BS" when a problem does not have a solution. As can be seen in the thread above, Rods observation was not actually addressed and Toms reply is all over the place, and does not go near what Rod was talking about. So I ask a very clear question that is hard to be circumnavigated and as I've experienced before, Tom goes quiet. Hopefully he'll come back and put everyones doubts to rest. I don't really understand what RodW and Islander261 are talking about with the Linux technical chat so can't comment there, but I do understand a THC needs realtime XY velocity feedback or at least a realtime hold signal from the CNC controller, to implement Velocity anti-dive on the THC Z axis.

Tom has ridiculed me at least 2 times in the past. One is when I designed my hole marking circuit board and he attempted to make me look like an idiot for all the time and effort I'd put into learning how to make it. He said I should just buy one of his systems, despite his system not being able to do what my hole marking board could do. I challenged him technically to explain how his system could do what mine did, and as usual he went silent instead of answering my questions.

The next was when I asked a general question to all plasma users about the need for high speed THC, and who'd got by without problem with a very basic THC. Once again I was jumped on and ridiculed, no doubt because the question was perceived as a threat to the sales of his systems, if users were educated and realised that a high speed PID controlled THC is not always necessary.

Quite sad for me really, because I worshipped Tom in the beginning, and thought he was an awesome guy. I do feel his systems are one of the best electronics packages you can get, but my opinion is if anything/anyone is a threat to his enterprise, or there's some flaw discovered, he won't play fair. And if he can knock someone down to make himself look better, he'll go for it.

But like other threads, this thread will get lost in time and I don't think anything will change, and nobody will be any wiser, and I'll just be looked at as a disgruntled dick LOL.

[Rodw]

Beefy said

I don't really understand what RodW and Islander261 are talking about with the Linux technical chat so can't comment there, but I do understand a THC needs realtime XY velocity feedback or at least a realtime hold signal from the CNC controller, to implement Velocity anti-dive on the THC Z axis.

Sorry we LinuxCNC plasma nerds are used to poring over halscope screen dumps. Halscope is a software oscilloscope included with Linuxcnc that allows monitoring of any internal signals in real time. Very cool tool. When you know where to look you will see that I sampled at 200 Hz But it is possible to get it to sample at 1000 Hz which is the speed at which Linuxcnc is operating at.

So what has happened to John and CandCNC is that they've used an internal LinuxCNC signal that was documented as being the F feed rate. But in reality it changes based on a particular line segment based on constraints imposed by what the trajectory planner can do according to the laws of physics and the machine velocity and acceleration constraints.

So what happened to John was the cut speed of 220 inches per minute (motion.current-vel in the screen dump) fell to say 50% of the feed rate based on the cut charts so his velocity hold kicked in to prevent diving. Then for the next segment, LinuxCNC decided it was too hard so changed the target feed rate (motion.requested-vel in the screen dump) from 220 in/min to say 30 in/min and was only able to cut it at say 28.5 in/min. This is seen on John's machine as being only 4% below the requested feed rate and thus within the Velocity hold parameter so the THC is re-enabled at a very low velocity with a very high voltage. The THC responds with an immediate erroneous height correction to get the voltage down and this is what caused John's divot.

There were other factors at play and John spent many hours optimising his system to reduce rise time by revising his hardware filtering at the plasma end. This did improve the results as corrections were much more responsive. But it was an observation of mine playing with a LinuxCNC test file that a very short straight segment about the width of your finger exhibited no ramp up or ramp down in cut velocity. I thought this was strange with a trapezoidal trajectory planner but it was actually becasue the machine was able to meet the reduced feed rate that LinuxCNC decided was all it could do.

So between John and I, now we understand this last roadblock, we are in a position to finalise a software only LinuxCNC plasma controller tightly coupled to the LinuxCNC internals that by definition will exceed the performance of any external THC. Its been a long road, we don't have a team of software and hardware engineers at our disposal but because we both have enquiring minds, and a spirit of collaboration, we've achieved what no others have done previously. That is to leverage the existing features of LinuxCNC to build a high performance software THC solution with a $69 arc voltage sensor.

Watch this space, its a very significant moment in the history of plasma control systems....

Rod

[beefy]

Thanks Rod,

that makes things a little easier to understand.

Keith

[tcaudle]

I go silent because I do not want to engage and rise to your bait to debate technology to an audience that wants to know what time it is, not how to build a watch . i deal with normal customers every day whose expertise is fabrication and metal work. Not programming and not electronics. I am stunned at how much more all of you guys know about plasm cutting than me. Maybe I have been doing this too long and I should be out in the yard following small animals. (I was the dumbass in 2001 that came up with the idea to embed THC logic in MACH1 and worked with Art to do the beta testing). Later i worked with Art to do the port mux stuff (that gave the MP3000 8 inputs from one parallel port) . Later we had to work with Gary at Warp9 and bring Art out of retirement to fix a bug in MACH3 with the DTHC IV and ESS card.

I will make a feeble attempt to explain why we don't have problems with mid-line divots
This whole thread started when the first post showed a defined divot in a cut at the point the internal THC is synced up to the motion. It was my conjecture that it was a motion pause to get a divot, but the user feels the torch was diving. Typically torch diving does not cause a divot Not sure how it gravitated to VAD . Anyway if its the Z diving then what is controlling Z is the source. In our system once the DTHC is turned on (happens precisely when the torch moves to Cut height) it ignores any steps from the control software. Its in total control of Z . If a VAD event happens it simply stops DTHC motion but it does not turn control back over to CommandCNC. So VAD detection is not outside the HAL pin but the on or off of the DTHC is not going to cause a plunge in the Z. With the control of Z outside the motion engine its not going to do anything but possibly cycle the DTHC enable on/off. Since there is no trajectory info for Z when the DTHC is active (even if its disabled) it is not part of the axis coordination algorithm . So no diving, no XY hesitation .

So are you dazzled with my BS? Guess not. Did you notice how I deflected and skipped over the exciting part about all of the internal stuff?

Why don't you guys go pick on one of the other LINUXCNC based systems? When you get your software only THC actually running then lets have a little contest. Let's cut some complex designs in thin corrugated then follow that up with a series of small holes on flat material , then cut some thick plate where I can use my soft start technology. Then we can do a combo plate marker/plasma cut followed by some peck marking and throw in pipe cutting with complex joints.

So if you want somebody to ohh and ahh and rub all over you then consider it done. You guys are way smarter than me, better looking and and I am sure, more successful and your children are beautiful. In the mean time I will start this week to ship our new EBOB direct Ethernet with the DTHC5. It's yet another attempt to hoodwink the buyer into thinking we know what we are doing. Now, with your exposure, that whole ruse is at risk.

[Largemouthlou]

Well then,,,,,, I don't have a spark in this pot and have no clue what all the this and thats are!! BUT, I do know Tom has sold a lot of the new system and I have been following it due to a future upgrade eventually and NO one that has bought his system has had this issue.. So would stand to reason that Tom is correct with his explanations of his system.

Also through the years of my self teaching with a non turn key unit I have dealt with Tom and his crew and have learned that his responses to your problems some times are not as direct as some would like but, his indirect responses at times leads you right to the problem but make you think, test and learn how to figure out what you did or what went wrong. In the grand scheme of it I have been able to keep my old systems running and obsolete as they are they do the job from .050 to .50 any day of the week!! And no I do not cut thin corrugated!! LOL

[Black Forest]

Very interesting John. So CommandCNC users doing decorative cuts would be well advised to follow the advice I gave earlier in this thread (changing the file name to what its used).

But like other threads, this thread will get lost in time and I don't think anything will change, and nobody will be any wiser, and I'll just be looked at as a disgruntled dick LOL.

Wait a minute there Beefy. We have always looked at you as a disgruntled dick!!!! It is not just because of this thread.

Sorry just had to poke a little fun at you!

[Rodw]

Well, it looks like we've solved Islander261's problem using the method I devised.
This 1 kHz plot from another LinuxCNC user shows perfect height control with internal software THC control using the same method.
Channel 1 (red) Z axis velocity
Channel 2 (aqua) Voltage
Channel 3 (green) torch height
Channel 4 (blue) cutting speed

You can see 3/4 of the way through the cut, cutting velocity dives to negotiate a corner, the velocity hold is enabled and torch height does not deviate at all.

And a video of yet another Linuxcnc user cutting corrugated iron at 200 ipm with software based THC control. Video is his first attempt

https://youtu.be/mOg5C_TusdM
I'm not sure if he's using a servo or a stepper on the Z axis. We calculated that you need the ability to accelerate at about 0.2g (2019 mm/sec/sec) at a book speed of 240 in/min to cut corrugated iron. I found it was hard to get past 1500 mm/sec/sec on my direct drive 5mm ball screw Z axis without losing steps (cheap NEMA 23). I suspect its a servo based on that.

Really good to see it all starting to come together and not just from one user either.

[tcaudle]

Interesting video. Did you happen to look at the date on that file? Late last year (2017) . So how did he fix the "problem" that has been presented with the solutions? Is it possible its not a problem if the machine has acceptable dynamic performance? The acceleration target of about 2000 mm/sec/sec (about 82 IPsec/sec) is quite doable with a stepper. The limitation would be the RPM to hit the 240 IPM target velocity with a 5mm pitch ballscrew. That forces the motor RPM to be up around 1200 RPM. Depending on the motor characteristics and the physics of the Z (mass and efficiency) you could reach stall point before you got to full RPM. At a slightly lower feedrate of 180IPM you could adjust the target volts up some and have enough speed overhead to support the higher acceleration rates. To cut a 45 slope you have to be able to move the Z at the same vertical speed as the X and Y. X and Y have to be able to meet the called for velocity or they adjust to keep the accuracy.