interesting
if I understand correctly...
the THC uses voltage drop gap sensing,
so if the velocity slows down,
the sensor sees the slot more than the stock
correct?
so the control loop lowers the hean trying to get to the target voltage.
(oops!)
we have similar problems in simple hole drill edm
( similar because velocity is a result of process, not an input to process )
when the tool breaks thru, the drop in sensed voltage pushes the tool
forward quickly
leaving a correct size hole body but undersized exit diameter ( like an
inverted burr )
the edm solution was to change velocity from gap control to feed control
once the
breakthru pattern was sensed.
The rule set for when to change and how fast to go should be programmable.
At least until experience shows some static response is good.
thanks
tomp
On 3/24/20 1:37 PM, Rod Webster wrote:
Anyway, I compiled Chris's branch and did a fair bit of testing of this on
my machine and it all seems to work as expected.
There were no side effects. or breakages I could find.
I can't see any reason why this can't be pushed to Master branch. Just my
vote.
It will take some time to incorporate it into Plasmac so it can do
something useful because there has been some very messy work arounds in
Plasmac because this data has not been available.
Just to refresh, Plasma cutters need to monitor the current velocity and if
it falls too far below the original cut velocity, the reduced velocity
results in an increased torch voltage. The Torch Height Controller (THC)
responds by lowering the torch to reduce the voltage and that can result in
a crash. The solution is to disable the THC if current velocity falls below
say 90% of the original feedrate. So this is pretty crucial parameter for
plasma control.
Thanks Chris for tackling it.
Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au
On Tue, 24 Mar 2020 at 13:06, Rod Webster <r...@vmn.com.au> wrote:
Oops, sorry I fell into an old trap. So long since I worried about this.
That will just be for that segment.
I did not notice you were referring to a test branch. I'll check it out.
Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au
On Tue, 24 Mar 2020 at 12:51, Chris Morley <chrisinnana...@hotmail.com>
wrote:
My work is not in master - confirmed.
requested-vel pin has been there for a long time and is not the Fcode
number - though is related to it.
The pin I added is called (badly named) base-feedrate and is the actual
Fcode number from gcode.
But the good news is if requested-vel works for you then it's available
now!
But I would check that it is in sync with the program.
Chris
________________________________
From: Rod Webster <r...@vmn.com.au>
Sent: March 23, 2020 11:56 PM
To: EMC developers <emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] correct F code status message - opinions
Chris, look again. It is there on a run in place compile of master branch.
And the HTML man page is updated for it too. Keep it there please!
Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au<http://www.vmn.com.au>
On Tue, 24 Mar 2020 at 09:29, Chris Morley <chrisinnana...@hotmail.com>
wrote:
Rod
Sorry I didn't make that clear - it's not in master yet and if it does
it
will probably change a bit, but thank you for testing.
I did think about you guys hence the HAL pin.
Chris
________________________________
From: Rod Webster <r...@vmn.com.au>
Sent: March 23, 2020 10:52 PM
To: EMC developers <emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] correct F code status message - opinions
Great work Chris, Confirmed as working here now on V 2.9 on my machine
Its interesting to watch motion.current_vel and your new
motion.requested-vel pins in halshow while running a job.
This will be very handy for plasma cutting.
And yes, state tags beckons if you feel the urge now you got this far.
Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au<http://www.vmn.com.au>
On Mon, 23 Mar 2020 at 22:20, Amit Goradia <amitgora...@gmail.com>
wrote:
On Mon, 23 Mar, 2020, 1:25 pm Chris Morley, <
chrisinnana...@hotmail.com>
wrote:
I have been delving deeper into linuxcnc to see if I could correct
the
status of F code.
For those who don't know the Fcode status report in AXIS (or any
gui)
is
actually the status of the interpreter rather then the current
Fcode.
If
you have a long program that changes the fcode lat in the program
you
will
see that f code before you should.
I have code that works; it reports through status the current F
code,
and
it outputs a HAL pin of current F code.
I'm not sure I've done it right of course.
It does this by sending a new NML message to motion each time the F
code
changes.
When that message gets to Motion, it updates status and the HAL pin.
Since it's read from the interpreted list, it is in sync with the
actual
F
code.
Currently the message is called feedrate or base_feedrate which
needs
to
be changed probably to F_code.
Then I was thinking S code should probably be updated in sync too.
Rather then having a message per code I could call the message
sync_code
and add other codes to it.
Opinions ? is this the wrong way to go?
Does my code look wrong? (most of it is boiler code actually)
You can see the commits here (top 6):
https://github.com/LinuxCNC/linuxcnc/commits/feedcode_message
Chris
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Hi Chris
Have you looked at the statetags branch?
It was trying to accomplish something similar in a generic manner.
-automata
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
