Messages

211

General Mach Discussion / Re: Screw mapping curve0.dat file format

« on: July 20, 2022, 06:18:38 AM »

Hmmm, I see what you mean Bill!  .dat is a catch-all format that's can be defined for any specific program, but they are often readable by a text editor or opened as a csv.  But not in this case clearly!!  Have you done a search on screw mapping here?  I'm sure that I've seen something somewhere on using in-built features to move the axis and capture the DRO value.

212

General Mach Discussion / Re: (Mach3) Can't figure out issue with G31 Command (Probing)

« on: July 19, 2022, 05:39:35 PM »

But that's why the delay is precisely controlled.  If you know the overtravel since you know the feed rate and delay you can simply correct the value.  These probes are used in machines with tool changers and have to be wireless.  Also in certain operations the probe is rotated, which is slightly difficult with a wire connected!  You would have no problem using this probe for autolevelling, you just need to add or subtract the 40um from the measured values in the probe macro.  The radio link is much faster but in a noisy environment with several machines and Wi-Fi etc you have to have a robust protocol with retransmission and padding to give a known total delay. 

When it comes to machine probes I think I'll accept Renishaw's point of view as they have just a little experience in the topic.

213

General Mach Discussion / Re: Screw mapping curve0.dat file format

« on: July 19, 2022, 03:51:00 PM »

Post the CSV or dat files.  Just change the file extension to txt on the latter

214

General Mach Discussion / Re: Screw mapping curve0.dat file format

« on: July 19, 2022, 02:30:19 PM »

Can you post the files?

215

General Mach Discussion / Re: (Mach3) Can't figure out issue with G31 Command (Probing)

« on: July 19, 2022, 01:37:17 PM »

I'm sure you're correct Craig about how Mach works, and of course since there's a plugin for each controller presumably NFS can define how probing should work.  But the way UCCNC works with its native controllers still seems much more satisfactory to me as it registers the ACTUAL point at which the probe triggers. 

I've enquired on the UCCNC forum and it does not have a probe delay parameter so one still has to use slow probing to minimise the error. 

I attach the Renishaw slide I referred to.

216

General Mach Discussion / Re: Screw mapping curve0.dat file format

« on: July 19, 2022, 05:43:19 AM »

You could try manually inputting some correction values through the config\screwmapping menu and inspecting the file so generated?  I would guess that the format should be obvious from that.  Actually generating the file from your CSV might involve some creative Excel work; or you could open the csv in a text editor and use that to insert necessary formatting characters.  This sounds harder than it usually turns out to be as you can use the "replace all" command creatively.

217

General Mach Discussion / Re: (Mach3) Can't figure out issue with G31 Command (Probing)

« on: July 18, 2022, 05:25:07 AM »

Well, you might like to read this thread:

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

...which includes this reply from CNCDrive:

"cncdrive wrote:
I can't say anything about if it matters in Mach3 or not, I did not use it for a too long time now and I can't remember how this is handled in Mach3.

In the UCCNC as I wrote the probing input is not polled, but a software interrupt is generated on the 2 probe pins on the edge which is set to the active one.

The sofware interrupt means that the code exacution inside the microcontroller jumps to the interrupt service routine as soon as the microcontroller detects the set edge on the probe pin.

This is a hardware microcontroller feature and happens immediately without any delays, the only delay, the max. 50nsec is because the return address to return back after the interrupt has to be saved to the stack prior to doing anything else and then the coordinates are read, these takes upto 50nanoseconds with the 200MHz CPU frequency microcontroller in the UC300ETH, because one micro CPU cycle is 5nanosec and it can take upto 10 CPU cycles to do the mentioned things.

After these are saved the saved coordinates are sent back to the computer via the ethernet, so the user can access them.

It is another thing when and how the probe stops, that can be a problem if the probing is too fast, it does not influance the programmatic measurement accuracy though, however of course too fast probing could cause the switch to jump/prell and could cause the machine to shake and also the axis stops a bit further since it has to stop, but again the probe coordinates are already saved when the axis stops, so these things are no more UC300ETH, but machine and sensor dependents."

So at least one motion controller works this way even if Mach doesn't.

As for the probe delay, I need to get a copy of the Renishaw presentation I referred to but meantime you might refer to the RMP60 installation guide.  This product has a programmable filter delay to help reject false triggers which can be set to 0, 10, or 20ms.  Clearly this has to be taken into account in the probing routine.  I'm not sure if that is in addition to the 5ms.  The presentation dealt with a trial comparing delays between their stand alone wireless system and one using a 5G private local network.  There's a lot of interest in using private 5G in factories to connect automation systems and if you have machine tools with probes it's an obvious question whether you could fit a 5G modem in the probe and use the local infrastructure.  The 5G network was tested against the 5ms criterion of the stand-alone system - not surprisingly it failed.  Also worth looking at their application note TE412 comparing 1-touch with 2-touch probing, which points out that some controllers poll hardware inputs perhaps every 4ms which introduces an inherent uncertainty averaging 2ms into the probe response in addition to the sensing delay.

As to why there is a delay, as I mentioned the RMP60 uses a frequency-hopping system for robustness in an electrically noisy environment, and to distinguish between different probes in the vicinity (say a tool setter and a probe on the same machine).  Inherently in such a system it would take at least one complete FH sequence to decode a trigger signal, so there's bound to be a delay.

I was impressed by the fact that the probe can operate whilst rotating at up to 1000rpm!

218

General Mach Discussion / Re: (Mach3) Can't figure out issue with G31 Command (Probing)

« on: July 18, 2022, 02:17:26 AM »

Thanks Craig, I stand corrected.  But it seems a crazy way to do it when it would be simple to just copy the value of the DRO, or something corresponding to it, when the probe triggers.  Yes, you still have to decelerate but the overtravel is irrelevant to the measurement.

My point about delay stands.  In your case, if you were using a Renishaw probe with a delay of 5ms, the overtravel would increase to 24 microns.  If the controller knew the delay it would be trivial to compute the overtravel due to this and deceleration and correct the probed value, but certainly in Mach3 and possibly in M4 there isn't a probe delay parameter as far as I know.

Edit a few minutes later:  UCCNC operates in just the way I described - the probe trigger interrupts the processor, stores the value at the interrupt point, then decelerates.  Not clear if they have a delay parameter.

219

General Mach Discussion / Re: (Mach3) Can't figure out issue with G31 Command (Probing)

« on: July 17, 2022, 04:58:36 AM »

I think the way that G31 must work internally (depending on the controller) is as follows.
- The axis is moved at the commanded speed by issuing a pulse train, and at each pulse a register R is incremented which indicates the amount of movement;

- At the same time the axis DRO is incremented and shows the actual current tool position;

- When the probe triggers the value of R is read and the deceleration started at the programmed rate;

- The value of R and the start position are used to derive the axis point at which the probe triggered - note that this is NOT the same as the final position the axis stopped at because of the inevitable over-travel.

Obviously this has to happen in a "real-time" environment, i.e. in the motion controller.  I wonder if the problem with your controller is that it erroneously reads the final axis DRO position and doesn't have the "R" function?

Since there will always be some overtravel as the deceleration has to be controlled to avoid losing steps, ideally the probe needs to have some over-travel capability.  This is built into all "professional" probes such as Renishaws (who effectively invented the CNC probe).  To set tool height I have a setter with a spring-loaded contact button allowing at least 0.5mm of over travel.  I use a simple contact for X and Y as it's harder to arrange for the over-travel, but I can see that some error is likely - but I use a very low probing speed.

Another odd point is that the latest Renishaw wireless probes have an inevitable delay between contact and asserting a logic level.  They work in a very noisy environment EMC-wise and use standard ISM bands (2.4 GHz?) that also carries Wi-Fi and Bluetooth and industrial heating and microwave ovens etc.  So they need to use a special protocol to ensure error-free transmission which inserts a delay, and this is engineered to make the delay a very precise 5ms (according to a presentation I recently heard from a Renishaw engineer).  Clearly the machine controller needs to know what the delay is to back-compute the actual probe trigger point once it gets the signal.  Neither Mach 3 nor as far as I know Mach 4 have a parameter to set the delay.  The delay also adds to the required over-travel.

NB: I posted this before seeing Craig's post, I hope what I said broadly corresponds though I can't say I understand the document at all!

220

General Mach Discussion / Re: Precise jogging and speed help

« on: July 11, 2022, 03:55:11 AM »

Try typing G1 X10 F10