How to use M10/M11 ??

[beefy]

But what I like is the antidive future based on the motion acceleration/deceleration control! May be now replace M205/206 hardware output to the "antidive hardware output" and name this signal 'Corner' . I think in this case we can not use Sheetcam rules for corners, end of cut....

Also Keith, what you think about this?

Hi Andrew,

I already suggested to Balazs to have ANY feature that disables THC to activate/de-activate the THC enable/disable output. Unless I am missing something I can't see any reason not to do this. I also don't see any reason to use separate synchronous outputs for M205/6, Corner Lock, etc. They all disable THC so just have one synchronous output that gets activated by ANY of them. I'm not sure if Balazs is doing it this way or using individual outputs.

The Corner Lock (Anti-Dive) is not based on acceleration/deceleration, but on a % of feedrate. Basically if the feedrate drops below the set % the THC is turned off so the slower speed doesn't cause the torch to dive.

If anyone sees a reason to have separate outputs I'm eager to learn something.

Keith

[beefy]

Keith
I presently use the same output pin for M3 + laser (m10/m11) .... but I've been having a problem with g31 of late with a uc400..... (I've not had the time to test it out in any detail so it may be me.... I'd like a small test rig next to my inside laptop..... )

I had a sneaky feeling you may be trying it that way.

I am confused how that could work though, I mean M3 is needed first and thus the output is already on when you operate M10 so effectively M10/11 will have no effect on the already activated output.

Keith.

[Robertspark]

response to TP's post

No problem, understood. I have never been sure how much could be gleaned from the toolpath view. because there are two things at work here, the control software (go from a-b as instructed) and the operator visualization screen (tool path view).

The visualization screen basically just [he says with lack of GUI programming knowledge...have done a bit with processing + arduino utft ]) plots the lines and arcs following the gcode. But a programmer with gui experience may look at my comment below and say "sure that's easy to determine" .... i.e. its available with whatever graphics class that uccnc uses, or "you've not got a hope as they are just plotted lines with Xstart, Ystart, Xend, Yend co-ordinates as the crossing points / proximity to those nearby crossing lines are not known and never will be known".

If no one asks the question then it never gets sounded out? Forums should be taken as brainstorming sessions of ideas and suggestions, none of us really can direct the direction of anything unless we do it ourselves or pay someone specifically to do it for us .... I don't think anyone is going to throw their toys out of the cot if something is not implemented, uccnc was sold as is [which I accept if it shut up shop tomorrow], development is just a bonus for us "sitting" purchasers who are lucky enough to be along for the ride of updates as more controllers and licenses are sold.

Out of hundreds of suggestions a few may stick and turn out to be easy to implement / a benefit to others, some may just be smoke.

Suggestions should come from everyone, no matter how far fetched they may sound, consideration of "a benefit to others" should be by those at the coal face of using the applications, and "consideration of ease to implement" should be from those with detailed programming / hardware experience of the application. Its near impossible to be a master of all three, generally people who try all three end up as jack of all trades, masters of none ..... that's how rapid deployment of useful innovative ideas and progress can be achieved in my opinion...
good example here: http://www.forum.cncdrive.com/viewtopic.php?f=13&t=126

Sorry not trying to sound or be an trumped up arse [delete / edit post as appropriate if required], but we shouldn't stifle suggestions when uccnc is sold / bought "as is", just be open to discuss it.

I'll get back in my box now....

[beefy]

People like Rob and Terry are a great combination I think.

You have lots of suggestions, plus a very experienced user to teach us less experienced ones a lot of stuff related to the question, whether it's agreeing or disagreeing with the suggestion.

We come away wiser.

Keith.

[shad]

We will make an assignable output pin for the Antidive, as mentioned we currently working on that.
What we doing is adding outputs for the THC enabled, the Anti dive active and the Anti down active signals,
these are handled in the motion controller, so the outputs will be instantly available as soon as they happen.

It's Great! I think you find the best way for all THC devices.
Also I agree with Keith - enough one hardware output pin for all THC off events. Just we can add/remove events for this pin by turn on/off future enabled checkboxes.

The Corner Lock (Anti-Dive) is not based on acceleration/deceleration, but on a % of feedrate.

Yes, feedrate drop down because Acc/Dec issue on the corner, end of cut. I wrote about my own postprocessor with THC off future for sheetcam - it's based only on the calculating acc/decc of the moves and works perfect.

Here is a bit of a suggestion..... what about kerf crossing?

Rob, for example Neuron during cutting looks on the changes of the arc voltage on the every sampling. If arc voltage changes more then "Kerf detect level (volts/second)" between two samples, AVC will off on short time (25-30 msec). This future (together with another LockHeadDown future) allow to prevent torch diving and crash when torch crosses previous cut or out from metal.