'Run from here' calls remapped M-code multiple times

More
19 Jul 2023 19:36 #275833 by chowderhead
I'm replacing M5 with a user defined (Python) M-code, M55, which checks and sets a few parameters before shutting off the spindle. M55 is run the number of times it appears in the g-code before the line from which I fire 'Run from here' in Axis, which causes problems. Is that the trajectory planner parsing the file up to the 'Run from here' line? In Python, is there a way to discriminate a trajectory planner traversal of the code (or whatever it is) from actual running of the g-code so I can trap for it?

Please Log in or Create an account to join the conversation.

More
20 Jul 2023 08:48 #275869 by andypugh
I think this is an attempt by the interpreter to be in same state at that point as it would be as if it had got there by running up to that point.

It's one of the problems with "run from here" that it isn't clear what the best thing to do with "stateful" elements of the system. (like, should it turn the spindle on if the spindle would have been on at that point, and in what mode)
(The reason that it isn't clear what to do is that pehaps the operator stopped the code specifically because they wanted to alter the state)

Please Log in or Create an account to join the conversation.

More
20 Jul 2023 08:59 #275870 by andypugh
G-code has the #<_task> parmeter
linuxcnc.org/docs/stable/html/gcode/over...ub:system-parameters

Which doesn't look like it maps exactly to either exec_state or task_state in the Python interface.
But I would start by looking at those to see if they do what you want,

Is there a compelling reason to do the remap in Python and not G-code?

Please Log in or Create an account to join the conversation.

More
20 Jul 2023 20:17 #275913 by chowderhead
Thanks, andypugh.

Is there a compelling reason to do the remap in Python and not G-code?

I'm setting welding power state using M3/M5. Some welding modes require scratch starting, wherein machine motion and welding power are initiated simultaneously with the arc establishing somewhere along the the tool path rather than precisely at the point where M3 was executed. Many welds start and end at the same point, so the delayed arc initiation results in a gap in the weld. I solve this by capturing the location where the arc initiated and create a temporary g-code file containing relevant moves from the start/stop location to that point. M55 looks for that file, executes its lines before executing M5, then deletes the file. So when I 'Run from here' the very first M55 called by the interpreter deletes the file, which is a bummer.

I don't see how changing g-code could solve that problem...

Please Log in or Create an account to join the conversation.

More
21 Jul 2023 13:18 #275951 by tommylight
A simple reed switch will do for sensing the current when welding starts, wire it to an input and in hal wire it to motion.inhibit.
That will nit let the machine move till it gets that signal that the welder is actually welding.
We use that for plasma cutting.

Please Log in or Create an account to join the conversation.

More
21 Jul 2023 14:00 #275952 by chowderhead
I'm using a robotic welder that sets a pin high when the arc is established - that's not the problem. The problem is the interpreter running M55 at the wrong time. My logic assumes M55 only follows an M3 when halui.mode.is-auto is high. But 'Run from here' violates that logic.

Please Log in or Create an account to join the conversation.

More
21 Jul 2023 14:25 - 21 Jul 2023 15:42 #275953 by Aciera

Is there a compelling reason to do the remap in Python and not G-code?

I don't see how changing g-code could solve that problem...
 

I think andys question was referring to weather it may be possible to write the remap in GCode instead of python, not changing the program.
Last edit: 21 Jul 2023 15:42 by Aciera. Reason: clarification
The following user(s) said Thank You: chowderhead

Please Log in or Create an account to join the conversation.

More
21 Jul 2023 14:31 #275955 by tommylight
Maybe a failure in communication, but from what you explain at length, you do not need any remap, you only need the machine not to move till the arc is on.

Please Log in or Create an account to join the conversation.

More
21 Jul 2023 15:59 #275961 by chowderhead
Apologies, I'm not being clear. I'll try again:

The problem is not starting, it's stopping. Assume the tool path is a closed square starting and ending at the same corner. Movement and welding power initiate simultaneously at that corner, but the arc initiates some distance along the move. (This must be done to scratch through a non-conducting coating.) To eliminate the gap that would otherwise exist between the starting corner and the point where the arc initiated, I capture the latter's position and write a temporary g-code file that M55 opens, executes, and deletes. If there's a problem, e.g. torch collision resulting in a e-stop, the subsequent 'Run from here' fires M55 multiple times, deleting the temporary g-code file, leaving the gap in the weld unfilled.
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

More
21 Jul 2023 16:13 #275963 by tommylight
"Solving hardware issues in software never works"

Movement and welding power initiate simultaneously at that corner, but the arc initiates some distance along the move. (This must be done to scratch through a non-conducting coating.)

That is a very big "no no" in welding. For a single part it might be ok, but serial production, never.
Parts must be clean before welding, and from anyone that i talked to regarding welding, that is not a subject open to discussion. I came to the same conclusion from several machines in serial production.

To eliminate the gap that would otherwise exist between the starting corner and the point where the arc initiated,

Still, you can just add an adjustable delay to switching off the welder.
What is the bearable tolerance? 1-2mm or more?

Please Log in or Create an account to join the conversation.

Time to create page: 0.095 seconds
Powered by Kunena Forum