THC postprocessor

[stivemaster]

Hello, Mr. Newell.
I have an idea but no programmer skills.
How can a postprocessor with THC be modified to perform the following logic:
At the beginning we declare the variables - "slow distance", "slow radius", "slow speed" and "slow angle"
They will then be used for inspection. All parts of the contour are checked.
If the part of the contour is larger than the "slow distance" - then it is divided into parts. At the beginning and where the "slow distance" is set to put THC Off, and at the end of the "slow distance" to put THC On. If the next part is at an angle greater than "slow angle" then at the end of the first part you should calculate again "slow distance" and put THC Off. However, if the next part is not at an angle to the previous "slow distance" no is being recorded.
If the next part is an arc, the same check and division of parts is done for it. So I think there will be no need to use rules at all. On the other hand, there will be no conflicts with THC due to the lack of constant speed, because in all places where there may be delays, Sheitkam will turn off THC.
What do you think ?

[Les Newell]

Path rules are there to do exactly what you want. These YouTube links may help
https://www.youtube.com/watch?v=hC_TRbmlzpE
https://www.youtube.com/watch?v=_gsNhcWF2lE

[stivemaster]

Ha ...., you really don't understand what I wrote to you?
Well, another person can help, although it won't be very nice if someone else does it for you.
Read again what I wrote, if you do not understand something, because of the translation I will specify if necessary. The good thing about what I suggest is that it makes the rules redundant.
Or maybe you don't like it?

P.P. Or tell me the price of such an add-on to one of the existing postprocessors - Mach3 Plasma THC for example. In my opinion, this should be a section in the file similar to the checks that still exist in postprocessors such as Mach3 THC with a scriber.

[Les Newell]

I used to modify post processors to do this sort of thing. It was unreliable and a complete nightmare to maintain. That was why I introduced rules.

The post processor can only see the current motion segment (line or arc). It cannot look ahead. Path rules can see the whole cut path and therefore can slow down in advance of a corner. You can also layer path rules allowing them for instance to handle different sized arcs differently.

What is your objection to using rules?

[stivemaster]

Well, my problem is that the arcs differ not only in length! If lead in and out arcs are used, then it becomes a complete mess. Because the rules are made with one logic - and that is that the arcs are in the middle of the contour, not at the end!
I try to come up with a universal rule so that different rules are not used, because for too long I have no questions from clients who can't handle them!
Consider whether the rules cannot be combined using this logic - if we know the minimum distance required for acceleration (I do not know if a calculation can be made - value of acceleration / distance traveled, taking the value of the speed that the user has chosen) we can to analyze the contour so that we know when the machine will maintain a constant speed and when not. If we can locate the places that the machine accelerates or decelerates only with logic, it does not matter what the element is. It only matters how long the element is and whether it is at an angle to the previous element and whether it is at the beginning or middle or end of the contour.
What do you think ?

[Les Newell]

We have discussed the acceleration idea before. The problem is that different controllers accelerate differently. For instance say you have a 90 degree corner. Some machines will come to almost a complete stop on the corner while some will round the corner. The amount of deceleration and rounding varies between controllers. Take another example of a curve made up of lots of short line segments. Some machines have a limited amount of look ahead so they would slow down for this curve. Others may run through at full speed, rounding as needed.

The only way for this to work would be to basically have an emulation of every motion controller's trajectory planning algorithm. This would be impossible to support.

I believe switching THC on and off should be done directly by the controller, not from SheetCam or the post processor. The controller knows if it needs to slow down so it can then disable THC as needed. Unfortunately not all controllers implement this.

Well, my problem is that the arcs differ not only in length! If lead in and out arcs are used, then it becomes a complete mess. Because the rules are made with one logic - and that is that the arcs are in the middle of the contour, not at the end!

You can set up rules for different arc radii. For instance say you have two rules. Rule 1 is for arcs smaller then 5mm and rule 2 is for arcs smller than 10mm. If your arc is 8mm the 10mm rule will apply. If your arc is 4mm the 5mm rule will apply.

Currently arc rules also apply to leadins and leadouts. This could be made optional if that would help.

[Les Newell]

Give this one a try.
Note this post completely ignores tool changes. Maybe it should do an M1 pause. Does GRBL support M1?

[stivemaster]

No GRBL does not support M1, M0 can be used, although I don't understand why you sent me this postprocessor.
I don't think you understand me again. In fact, everything seems too simple. No cheap controller other than LinuxCNC can output the required signal for a constant speed. That's why I offered you a universal solution that will give SheetCam a rattling advantage over others!
The arcs are processed differently by different CNC controllers. For example, the UCCNC does not understand from an arc which is actually a hole. There you have to divide the hole into 4 arcs. Then in one contour we have three types of arcs - lead in / out, angle arc and arc which is 1/4 of the hole. To think that they can be divided by size is not acceptable to me, because the logic of THC in different arcs is different.
And the issue of acceleration is solvable. Take the following as an example:
In SheetCam, the speed in the operation is set to 1000 mm / min and the acceleration is 500 mm / s2 - respectively in the CNC controller the set acceleration must be the same.
This automatically means that 1000mm / min will be reached in less than 0.05sec. or about 2.3mm. It follows that even if the machine stops at each part of the contour, 2.3 mm will be needed at the beginning and as much at the end. Then these 2.3mm can be placed on any part of the contour and if the remainder is up to 33% - then the whole part will be marked as THC Off.
Is that so?

mach3.png (71.17 KiB) Viewed 1254 times

[Les Newell]

Ignore the GRBL stuff. That was an answer to a question in another thread and I posted it here by mistake.

In SheetCam, the speed in the operation is set to 1000 mm / min and the acceleration is 500 mm / s2 - respectively in the CNC controller the set acceleration must be the same.
This automatically means that 1000mm / min will be reached in less than 0.05sec. or about 2.3mm. It follows that even if the machine stops at each part of the contour, 2.3 mm will be needed at the beginning and as much at the end.

That can only be guaranteed at the start or end of motion. Here's an example: On a 90 degree corner Mach3 will come to a complete stop on the corner, change direction and accelerate away. Your acceleration calculation will probably work in this case. In LinuxCNC if you have CV enabled, it will round the same corner slightly and not come to a complete stop. The post processor has no way of knowing exactly how the controller handles these situations. Now take a 45 degree corner. Both Mach and LinuxCNC will round the corner but by different amounts. Without actually measuring the output pulses there is pretty much no way of knowing what acceleration they are using in this situation. About all you can say is that it's probably less than the configured acceleration.

There is no easy solution to this problem. If there was I would have implemented it. That is why I created rules. They aren't perfect but they are the best solution I can think of.