Remember Arc Lost position

[shad]

Hello Balazs!
Is it possible to remember arc lost XY position inside controller hardware and then transmit it to the UCCNC registers?
It's working now for any THC - by controlling ArcOK input LED or pin in the plugin, but we have minimum 40 msec delay. On the 10000 m/min cutting speed it's will be 6.6 mm error.
It's will be great to make it instant in the controller and store in the UCCNC. What you think?

[shad]

Terry, this is very realistic task. Now I have 10 msec loop time for communication with controller and UCCNC Neuron Plugin has information about arc lost position very close to the real arc lost position. It's work perfect now. But for me this is not auto restart. Operator have to understand what happens and solve problem. Only after this will start Cut recovery procedure.
This is the screen with opened Cut Recovery dialog. Operator just select recovery mode and continue to cut.

My question was for other THC controllers, because they receive ArcOK signal only from teh (as you like to say) software with 40-60 msec delay. This is very big value, especially for hi speed cutting.
I think UC has motion planner inside controller hardware and this is not problem to catch current position when ArcOK signal will lost.
IMHO it's will be very helpful for plasma cutting.
Also Interesting what to say about it Balazs

[Robertspark]

How did you get 100hz loop?

Could lost arc not be done like g31.... ie monitor arc Ok signal and when lost trigger 6 axis dro dump to #vars.... that way vars can be called if you want to instigate lost arc position..... I would like the active gcode line too.... that way it makes restart very easy for me

Sounds like a useful feature... (anyone else seen such a feature before, how do the big boys do it (hyperthem etc))

[Robertspark]

Thanks TP, like most things with me, brain kicks in after mouth has opened... (typed)

At 600ipm, 60ipsec, 100hz plugin loop, 0.1" event trigger to save dros to vars....

My cutting is around 200ipm.... hence error is negligible if the first loop I'd missed or part loop to get the dros and line number

[Robertspark]

Instead of a macroloop I thought about writing a simple plugin which monitored the arcOK input pin, then every time the pin changed state from high to low (whichever was set as inactive), the plugin would obtain the dros and line number and pass it to a var, and call for a stop with deceleration, move the torch to the various var co ordinates x, and Y, move the gcode to the line saved in the var (or a variable in the plugin) call the touchoff macro, refire the torch and call for motion to start, allowing for all background stuff too THCOff and THCOn etc...

Anyone can use it then?

The faster plugin loop sounded interesting (sorry Andrew, did not mean to hijack your thread)

[Robertspark]

Ahh, but if the plugin dumps the values to vars, every time the arcOK is lost, you can have a button press onscreen which would allow you to do the arc lost, restart procedure which will use the vars saved. (Two stage operation, not fully automated)

I thought a plugin could be made to run at 100hz, but a macroloop can only run at 25hz?

[Robertspark]

I know what code() function does.

Does anyone know what codesync() function does?

[shad]

Rob, Balazs wrote:
There is the .Codesync function in the plugin interface, that function is the same as the .Code function, but it does not start it's own thread, it makes the execution in the same thread where it is ...
I am use only this function for execute code from plugin.
About arc lost all are more easy.
Main thing to store current XY position when ArcOK signal will lost and set XY position for example to the 999999999 value if ArcOK is present. It's not hard.
If Arc Lost issue plugin store current position. If THCON, UCCNC will feedhold XY motion.
If I am want to restart from stored position i have to:

Code: Select all

UC.Callbutton(130); //stop program
UC.Codesync("M5");
string code = "G00" + "X" + cutRecoveryForm.XposTextBox.Text + "Y" + cutRecoveryForm.YposTextBox.Text + " F" + cutRecoveryForm.SetFeedrateTextBox.Text; //return to the arc lost position
UC.Setfieldtext(true, "Please wait, we repositioning", 2742);
UC.Codesync(code);
UC.Codesync("M3");
UC.Callbutton(128); //start program


Now Program started, plasma on signal issue and UCCNC wait for arc ok signal for start cutting.
This is more easy for me, because Neuron is Full stand alone controller and M3 command is all what he need, but you have to insert code for IHS (Initial Height Sensing procedure) and lit torch on (it's can be macros).
Before I wrote about main problem - delay in the UCCNC between ArcOK lost and when plugin can get this signal from Led or input pins. This is 40-60 msec. I hope there is a way to catch this position instant in the controller hardware and send to the UCCNC special register avaiable from plugins (for example ArcLost_event function)
I hope that the UCCNC will help us in this very important moment in the plasma cutting.

[Robertspark]

Before I wrote about main problem delay in the UCCNC between ArcOK lost and when plugin can get this signal from Led or input pins. This is 40-60 msec. I hope there is a way to catch this position instant in the controller hardware and send to the UCCNC special register avaiable from plugins (for example ArcLost_event function)
I hope that the UCCNC will help us in this very important moment in the plasma cutting.

Wow, I didn't realise that the delay between feedback from the motion controller was so great....

Have you tried changing the communication buffer (configuration tab >> general settings >> top left hand side)

extract from manual below:

Communication buffer size: This parameter sets the length of the USB communication buffer. The
parameter is in seconds. The shorter the buffer is the faster the machine will react to button presses.
The minimum set value is 0.05seconds(50milliseconds) and the longest is 0.5seconds(500mseconds).
Because the motion core of the software is running in a special high priority loop in our testings we
found that 0.1seconds (100milliseconds) buffer length is enough in all cases and we recommend to
leave this parameter at this value, but we left the ability to change this setting for the most
flexibility of the software.

Anyone else reading this post now or in the future, my ramblings below about 100hz are incorrect, the discussion was to do with setting up another thread to call communications via the plugin [i.e. seperate ethernet comms with another device], the plugin loop runs at 25mSec (although the text in the plugin says 25hz....) extract from the c# example plugin below

UCCNCplugin.cs

Code: Select all

 //Called in a loop with a 25Hz interval.
        public void Loop_event()

http://www.forum.cncdrive.com/viewtopic.php?f=13&t=85&p=338&hilit=thread#p338
http://www.forum.cncdrive.com/viewtopic.php?f=4&t=43

There is a bit of discussion on loops for screenset elements at 60mSec and THC bits at 20mSec .... so ArcOK pins may be updated at 20mSec intervals (needs to be tested a little).
http://www.forum.cncdrive.com/viewtopic.php?f=14&t=86

suggestion >> think we need a bit of clarity in the users manual about what loops run at what speeds and update what

[shad]

Teh example that Andrew gave is what I call a auto Refire not a restart. A restart is where you would move off position to fix a torch problem then return and restart cutting.

Normal plugins and macroloops do run at 25HZs. You MAY be able to program a plugin to run at any speed but you have to take teh CPU load into perspective.

Yes Terry, you right.
But I am use this code to return from current torch position (where machine will feedhold XY moves on ArkOK lost) to the stored position where plugin get ArcLost signal from controller. I have this difference in the position (on the 10000 mm/min cutting speed ~ 6.6 mm) because the delay issue between the real ArcLost and UCCNC stop.
About plugin - yes, for Neuron plugin main non time sensitive thread works in the 40 msec, Leds - 100 msec. Communication thread have adjustable by user pooling time (10-40 msec) and 0.5 msec enough for communication. Left 10-40 msec thread just sleep.