Hypersensing with THCAD - better way to do ohmic sensing

thefabricator03 wrote:

tommylight wrote:

BTW i did push it to 68m/m but it started tearing the belts.

If you were to use rack and pinion and a quality planetary gearbox, do you think it would handle those speeds well and be reliable?

I think that would work fine. The ones I have been looking at can handle 5000 or 10000 rpm input depending on model, way more than what a stepper can produce. And the torque is not an issue. I ran my Sanyo Denki to 60 m/min and up to 8 m/sec/sec on a rack and pinion while testing.

For belt drive you would be better with a a 30mm wide belt instead of 2. Some belt manufacturers will do the design for you if you ask.

phillc54 wrote:

I have asked Phill to add a seperate THC hold pin to Plasmac for third party use but so far he has been unwilling to do so. That would make extensions like this much easier to implement.

There is a thc disable pin that has been available since June 2019

Yes there is but its used by the Plasmac GUI. It would be very helpful to have a second disable pin that is anded inside the component with the existing disable pin. Its not actually a duplicate, It provided as a convenience to allow Plasmac to be extended and still make it super easy to keep in step with the latest Plasmac upgrade.

I actually started participating in this topic because Rod wrote to me that THC can be deactivated automatically at a certain threshold of the set speed. How exactly does this happen? I mean that in order to monitor a speed you need to turn off small holes for example in principle Is that so?
Can anyone share their experience with this functionality?

stivemaster13 wrote:

I actually started participating in this topic because Rod wrote to me that THC can be deactivated automatically at a certain threshold of the set speed. How exactly does this happen? I mean that in order to monitor a speed you need to turn off small holes for example in principle Is that so?
Can anyone share their experience with this functionality?

This is actually quite trivial with Linuxcnc because we have access to the motion controller. Plasmac knows the cutting speed (feed rate) and the Motion controller knows the current velocity at any given point in time. The motion controller also knows any feed overrides and the like applied. After adjusting the current velocity for any feed overrides etc we compare that with the desired cut speed. We might set a threshold of 80% or 90% to be the trigger for velocity antidive. So if the current velocity falls below the threshold, then the THC is disabled.

I think Plasmac also uses the Linuxcnc filter capability so that any gcode file opened, it is run through a filter program and modified to apply various hole cutting optimisations. In the future I think these optimisations could be applied automatically by the motion controller without requiring gcode.

Well, that's hardly so trivial.

It is a little difficult for me to understand after the translation. You mean that replacement speeds are those that reduce the basic speed and are set parametrically in the PLC or with a special D code?
As far as I understand, this is not yet an appreciated and widely used advantage of LinuxCNC.

Yes, Linuxcnc is far more powerful than many people give it credit for.

I thought you asked about two topics.
1, How to disable the THC when the velocity slowed leading up to a corner ( I covered that)
2. What happens when cutting small holes. I did not speak much about that except to mention that Linuxcnc can filter the Gcode.


By filter I mean that Linuxcnc can automatically pass every gcode file it opens to a program that can modify the code before it is run.

But yes, Linuxcnc supports adaptive feed control which is enabled and disabled with M52. What this means is that an override (from 0% to 100%) can be applied to the cutting speed from a value outside of gcode. Its up to you how you use that feature.

Plasmac can use this for hole cutting. Lets look at an example. I often hear that you should reduce cutting speed by 60% on holes < 32mm diameter. So a gcode filter could inspect gcode arcs and holes and alter the cut speed if the radius is < 32mm by altering the gcode before it is executed.

Another more interesting way which I am experimenting with is to modify the core code of Linuxcnc so that it publishes the arc radius to the motion controller. We could then apply adaptive feed control to reduce the cut velocity based on any algorithm we care to create. This technique could even be extended to offset the torch path to allow for the wider kerf caused by velocity slowdowns.

And yes, these advanced features of linuxcnc are not widely appreciated and will give Linuxcnc a massive advantage over other solutions when it is used as a plasma controller.

To understand the logic of the speed of small holes just imagine - cutting a shape with angles will be passed by about 30% at a lower average speed.Therefore, it is necessary to reduce the speed of small holes - the cyclone torch begins to deviate from verticality and a bevel is obtained from above.

See the level I've reached today gives me the opportunity to appreciate things I didn't appreciate years ago. So I think the capabilities of LinuxCNC can make up for Sheetcam's shortcomings.
The point is to start a more lively development and to suppress the feeling of self-satisfaction and superiority of what has been achieved. You still have a lot of work to do.