forum.cncdrive.com

Hi Balázs,

If probing twice to get high accuracy is not necessary, like it has been said in this thread...

http://www.forum.cncdrive.com/viewtopic.php?f=2&t=288

...then why by default include in the UCCNC product an M31 macro which is doing (wrongly?) just that? Why not include a working and correct macro using the trip point #5063 instead? Isn't reading #5063 the EXACT trip point after a G31 on Z? Which is the right approach? Balázs, can you give us a definite answer?

Most of the included macros are old, and haven't been updated to reflect changes in UCCNC. Many of them are written differently then the documentation would lead you to do.

ger21 wrote:Most of the included macros are old, and haven't been updated to reflect changes in UCCNC. Many of them are written differently then the documentation would lead you to do.

Then the question is even more valid. The default macro folder should reflect the product and should be updated with the product.

Gerry is right, earlier the probing was not working this accurate, the precise probing was implemented only recently.
The probe macro has this variable:
bool dodualcycle = true; //Do probing from 2 cycles, first with Fast and second with Slow feedrates

Changing that variable false will make probing from a single cycle.

Thank you Balázs, but if he is right then the question is even more valid. Why include macros which are not up to date? Why not give up to date, simple and well documented macros instead?

Also the question is still unanswered about dual probing run. Is it or is it not necessary to run a dual probe run to get accurate probing? I know how to change that macro for single run, that wasn't my question and in fact, for my needs that macro is just overkill anyway so I would write a new one anyway. The truth is that I already have new ones for X, Y and Z but I would like to know the answer to my question before I finish them and continue with the others.

Especially that macro just like some others e.g. the M6 and goto parking position macros etc. are examples, are a starting point only in most cases.
Different machines have different requirements, if the user has an example which is about to be good in most cases then the user can study how it is done and with minor changes they can customise for the exact needs.
This is why we wrote variable definitions with value giving in the beginning of the macro, so the user can change some behaviours of the macro simply with changing those values without the need for real coding.

As we discussed earlier programmatically there is now no difference in precision if the feedrate for the probing is high or low, but mechanically/electromechanically there could be,
but that is sensor and mechanics dependent, so we felt to leave the opportunity to easily change the way of how the macro works with simply changing values of some variables in the beginning of the macro is the best and most generic way of coding this particular macro.

For those like you who can write a macro from scratch it is not a problem if only one way is coded, because you can simply write your own,
but can be helpful for those who don't know programming that good if there are more solutions in the macro which they see that they can change with simply changing a variable value.

OK, so now I am on probing again... obviously, it is very important for me, and probably for many others also. I am working on a probe hardware which allows high speed probing and takes care of the deceleration, but it seems that a single probing run at high speed is not working as expected, and a second probing with slow speed is necessary to get accurate reading.

Based on earlier discussions I decided to test high speed probing and check out if it is true that UCCNC detects a probe touch input in less than 50 ns (0.00000005 seconds) through interrupt. Unfortunately, I can't really see that this is the case. Maybe I made a mistake or maybe there is a bug somewhere in UCCNC. In this post...

http://www.forum.cncdrive.com/viewtopic.php?f=2&t=288#p1825

...it is said that:

If you probe e.g. with 20000mm/min (not likely anyone would probe that fast.) then still the travel on the worst case about 50nsec is 0.0000166666 millimeters which is 0.000000656 inches only.

In other words, if I am probing with 4000mm/min then the worst case error should be 0.00000333332mm error, the touching should be registered and saved in #5061 (for X axis probing) with maximum that error. This does not seem to be the case according to my experiments, and in fact the error is many times more, in the magnitude of 0.2mm or more and is not constant, which is strange if it is captured by interrupt. How can that be explained? I don't believe that the error is due to latency in opto coupler on the input, and it is definitely not due to my CNC. The simple probing code is written by me an looks like this:

Code: Select all

//-----------------------------------------------------------------------------------------------------------------
//
//   M20002.txt is a probe macro for X axis.
//
//   This routine probes X in negative X direction.
//   X offsets for G54 to G59 contain the new X zero after probing.
//
//   Probing done in two steps for highest possible accuracy and repeat-ability.
//
//-----------------------------------------------------------------------------------------------------------------

double XRetractDistance   = 2;   // Distance from X0 to which the probe will retract after probing.
double FastProbe    = 4000;   // Feedrate for initial probing.
double SlowProbe    = 4;   // Feedrate for fine probing.
double Xmin       = -70;   // Maximum probing distance.
double readX       = 0;   // Trip point after G31
double PlateThickness    = 0 ;   // Zero here because the gantry moves to the left and the touch plate is outside.
            // Set to actual plate thickness (1.48) if the plate is inside the probed surface.

//-----------------------------------------------------------------------------------------------------------------
//
//   UCCNC constants
//

int LED_Xhome       = 56;   // LED on Indicates X is homed
int Xdro       = 226;   // XposDRO
int Xvar       = 5061;   // X trigger position variable
//
//-----------------------------------------------------------------------------------------------------------------
//
//   Macro execution starts here
//

exec.Code ("G90");

if(!exec.GetLED(LED_Xhome))   // If X was not homed before then exit with a message.
{
  MessageBox.Show("X was not yet homed, home X before seting X-zero");
  exec.Stop();
  return;         // Exit without additional action.
}

exec.Setvar(0, Xvar);               // Zero the touch value of X
exec.mainform.sumoffsetcontrol1.G54.newCxinput(0);     // Set G54, G55, G56, G57, G58 and G59 to zero
exec.mainform.sumoffsetcontrol1.G55.newCxinput(0);     
exec.mainform.sumoffsetcontrol1.G56.newCxinput(0); 
exec.mainform.sumoffsetcontrol1.G57.newCxinput(0); 
exec.mainform.sumoffsetcontrol1.G58.newCxinput(0); 
exec.mainform.sumoffsetcontrol1.G59.newCxinput(0); 
AS3.Setfield(0, Xdro);               // Zero also X DRO
AS3.Validatefield(Xdro);

exec.Code("G31 X" + Xmin + "F" + FastProbe);      // First step is fast probing
while(exec.IsMoving())
{
   exec.Wait(100);
}
readX = exec.Getvar(Xvar);

//MessageBox.Show(this.exec.mainform, "X DRO = " + AS3.Getfield(Xdro) + Environment.NewLine +
//                "#5061 = " + readX);
/
exec.Code ("G01 X" + readX);   // Move back to the X trigger position
while(exec.IsMoving())
{
   exec.Wait(100);
}

//MessageBox.Show(this.exec.mainform, "X moved back to Xvar #5061 = " + readX + Environment.NewLine +
//                  "after fast probing to remove the overshoot.");

exec.mainform.sumoffsetcontrol1.G54.newCxinput(0);     // Set G54, G55, G56, G57, G58 and G59 to zero again 
exec.mainform.sumoffsetcontrol1.G55.newCxinput(0);    
exec.mainform.sumoffsetcontrol1.G56.newCxinput(0);
exec.mainform.sumoffsetcontrol1.G57.newCxinput(0);
exec.mainform.sumoffsetcontrol1.G58.newCxinput(0);
exec.mainform.sumoffsetcontrol1.G59.newCxinput(0);
AS3.Setfield(0, Xdro);               // Zero also X DRO
AS3.Validatefield(Xdro);

exec.Code ("G00 X0.5");             // Retract 0.5 from the touch plate
while(exec.IsMoving())
{
   exec.Wait(100);
}

exec.Code("G31 X" + Xmin + "F" + SlowProbe);      // Second step is slow probing
while(exec.IsMoving())
{
   exec.Wait(200);
}
readX = exec.Getvar(Xvar);

//MessageBox.Show(this.exec.mainform, "Xvar #5061 after slow probing move = " + readX + Environment.NewLine +
//                "Difference between fast and slow probing: " + (0.5 - readX));

exec.Code ("G01 X" + readX);            // Move back to trigger point
while(exec.IsMoving())
{
   exec.Wait(100);
}

//MessageBox.Show(this.exec.mainform, "X moved back to Xvar #5061 = " + readX + Environment.NewLine +
//                "after slow probing to remove any overshoot." + Environment.NewLine +
//                "This is the new X zero position.");

//
//   Probing is done. Set X DRO and all the offsets to the new value.
//
AS3.Setfield(PlateThickness, Xdro);
AS3.Validatefield(Xdro);
exec.mainform.sumoffsetcontrol1.G54.newCxinput(PlateThickness); 
exec.mainform.sumoffsetcontrol1.G55.newCxinput(PlateThickness);    
exec.mainform.sumoffsetcontrol1.G56.newCxinput(PlateThickness);
exec.mainform.sumoffsetcontrol1.G57.newCxinput(PlateThickness);
exec.mainform.sumoffsetcontrol1.G58.newCxinput(PlateThickness); 
exec.mainform.sumoffsetcontrol1.G59.newCxinput(PlateThickness); 

exec.Code ("G00 X" + XRetractDistance);   // Retract X axis
while(exec.IsMoving())
{
   exec.Wait(100);
}


The above code contains the message boxes seen in the video below, but are commented out above.

Probing is done in two steps, first a high speed probing at 4000mm/min, when the moving stops I move back the X to #5061 position, set that point to zero and move back 0.5mm and make a very slow probing at 4mm/min. I calculate the difference between 0.5mm and the distance traveled during the slow probing, which gives me the difference between fast and slow probing. This difference is pretty large. At slow probing the difference is zero. I also made a video about it.



Am I wrong? If yes, where? What errors am I making? I really would like to probe fast and accurate in one single high speed pass, so I'd be glad if I could get an answer to why it is not working as described, or as it should.

Vmax549 wrote:The margin of error can only be within teh value of 1 step distance and that will be machine dependant.

For instance if you had a step distance of .001 . ON a single step it did not trip but on the next step it did trip so teh error willl somewhere less than or equal to .001 at best as then UCCNC has no knowledge of any position between steps. .001 ,.002 ,.003.. IT cannot see .0005.

(;-) TP

I guess you don't understand the issue... what you are saying is true but wrong and was not the question or the issue.

If the detection is interrupt driven then it should detect as soon as the probe touches the touch plate, record THAT position in #5061 based on what the software BELIEVES to be the right position and continue with the deceleration. Otherwise it is NOT interrupt driven, or something is wrong in the interrupt handler part of the software. Balázs said that UCCNC detects a probe touching the probe input in less than 50 ns (0.00000005 seconds) through interrupt. with 4000mm/min (~157in/min) that time results in a theoretical maximum movement of 0.00000333332mm (disregarding deceleration). This is calculated.

My micro stepping is set to 8, so one step = 0.003125mm using the 1605 ball nut and a 200 steps per rev motor. So, adding one step to the maximum error means 0.00312833332mm, or 0.00012316". I am getting 0.1875mm error, which is the difference between fast and slow probing as you can see at the 34 seconds mark in my video.



This can NOT be explained with step error because that is a HUGE error and is many steps, also because this error is not constant, repeating the measurement can result in much larger error as well, though I could not get smaller than this. So something is definitely wrong, either the interrupt handler or something else, but UCCNC can not capture G31 as fast as it has been said by Balázs in this post:

http://www.forum.cncdrive.com/viewtopic.php?f=2&t=288#p1825

In fact, it is very far from that. Balázs also mentioned opto coupler latency (delay between pulse on input and reaction on output) but that is in the magnitude 3-4us, so even doubling that to 8us is not enough, that is only 0.00053333336mm movement, so we can basically ignore that, but adding all together should be no more that 0.00366166668mm error, NOT 0.1875mm (or more). The error I get is equal to 60 steps (or more), so that is quite a lot.

Hi Josef,

We can check/verify and measure out the latency again, but I think the difference in the position will be because of the optocoupler and how fast the signal transfers to the controller.
I know you said it should be 2-4usec, but I'm not sure about that. How fast the opto will switch depends on several factors, like with how much current you driving the opto LED and how much the output NPN is biased.
Also it depends on if you driving it on or off, because the rise and fall and turn on/off times can differ.
And finally mostly RC filters are installed on the output of the optocoupler to avoid glitches/spikes on the signal transition.
So, if the datasheet states e.g. 2sec for the switching time is probably the best case scenario with the input driven with extreme high current and the output pulled with extreme high current also.
In reality a standard optocoupler won't switch that fast, but only a few tens of kiloHertz frequency in best case, if there is no filter installed on the output.

Ofcourse there are fast type optos like the HCPL2631 which can switch much faster, but because these are more costy it is not often seen on BOBs, especially not on cheap ones.

But if you have a storage scope or a logic analyser then you can easily verify the switching time measuring the input to the output with edge trigger.

And we will verify the probe coordinates save time in the API.

cncdrive wrote:Hi Josef,

We can check/verify and measure out the latency again, but I think the difference in the position will be because of the optocoupler and how fast the signal transfers to the controller.
I know you said it should be 2-4usec, but I'm not sure about that. How fast the opto will switch depends on several factors, like with how much current you driving the opto LED and how much the output NPN is biased.
Also it depends on if you driving it on or off, because the rise and fall and turn on/off times can differ.
And finally mostly RC filters are installed on the output of the optocoupler to avoid glitches/spikes on the signal transition.
So, if the datasheet states e.g. 2sec for the switching time is probably the best case scenario with the input driven with extreme high current and the output pulled with extreme high current also.
In reality a standard optocoupler won't switch that fast, but only a few tens of kiloHertz frequency in best case, if there is no filter installed on the output.

Ofcourse there are fast type optos like the HCPL2631 which can switch much faster, but because these are more costy it is not often seen on BOBs, especially not on cheap ones.

But if you have a storage scope or a logic analyser then you can easily verify the switching time measuring the input to the output with edge trigger.

And we will verify the probe coordinates save time in the API.

Hi Balázs,

Yes, I know opto couplers can be tricky and introduce delay, that's why I doubled that value of 4us to 8us but sure, worst case can be even worse, as much as 18us, but even with 18us the error should be FAR less than 0.1875mm. 18us movement is only 0.00120000006mm, so I still don't know where the rest comes from, I can be wrong, but I don't think that the rest is caused by any RC filter or other hardware related things, but I will check. Yes, I have a digital oscilloscope (two actually) and also a logic analyzer, so I can measure that delay. Yes, I know how fast the opto couplers switch depends also on the current. I will rewire so that I bypass the BOB as soon as I have time, but I doubt that it solves the issue, however, if it does solve it then I am happy. I have plenty free inputs and can make my high speed probe working outside the BOB if that solves the issue.

Anyway, I'd appreciate if you could verify this at your end.

BTW, I guess you can see it directly, but I made a mistake when I commented out one of the message boxes. There is one "/" missing on line 72 (I think). I can't edit the post any more but running the macro generates an error because of that missing character.