Hello Guest it is May 09, 2021, 09:39:07 PM

Author Topic: MACH4 #5071-5073 variables values 2000x smaller than DRO  (Read 1658 times)

0 Members and 1 Guest are viewing this topic.

MACH4 #5071-5073 variables values 2000x smaller than DRO
« on: May 23, 2018, 04:11:23 PM »
Hi guys,

I have a strange problem with Mach4 variables #5071-#5073 (machine coordinates when probing). I monitor them real time in mach4 and those values are 2000x smaller than mm readout on DRO. It seems to me that it's not using COUNTS PER UNIT which is 2000 on my motor config page for all motors (this is only number 2000 in any of my setup). I'm using CSMIO-IPS. Does anyone experience this?


Re: MACH4 #5071-5073 variables values 2000x smaller than DRO
« Reply #1 on: May 24, 2018, 03:04:08 PM »

PROBE POS X 5061 // G31 Skip signal
PROBE MACH POS X 5071 // G31 Skip signal machine position
Not sure what the difference is between the two sets of registers, easy enough to have a look.

My wife left with my best friend...
     and I miss him!
Re: MACH4 #5071-5073 variables values 2000x smaller than DRO
« Reply #2 on: May 24, 2018, 03:28:51 PM »

Sorry to take a while but I had a job to finish this afternoon.

I don't ordinarily directly display the values you mention, so rigged up a test screen to probe Z and stop when the probe was hit. I displayed the following results:

  #5063   mc.SV_PROBE_POS_Z
  #5073   mc.SV_PROBE_MACH_POS_Z

These agreed  (within my display resolution of 0.01mm) with Mach4's normal user and machine coordinate DROs. In other words, the two register values differed by the Z axis fixture offset, as one might expect. I saw no strange scaling factors at work. I have imperial screws but work in metric with a counts per unit of 3937.

My system uses the IP/A  rather than the IP/S with plugin 3.014 and Mach4 3804.

The problem that I have is that probing randomly hangs Waiting on Set Still ... That can be very frustrating when it happens but apart from that probing works very well


The regs with Mach in the name are machine coordinates, the others are user (work) coordinates.

« Last Edit: May 24, 2018, 03:33:23 PM by Fledermaus »
Re: MACH4 #5071-5073 variables values 2000x smaller than DRO
« Reply #3 on: May 24, 2018, 04:00:31 PM »
joeaverage, I watch both 5063 and 5073 when probing Z. Problem is that 5063 is calculated from 5073. So in my case, if my 5073 is -0,025, and my Z offset is 0, 5063 is also -0,025. But when I zero Z when I'm lets say at Z=-50, my 5073 is of course still -0,025 (machine z coordinate) but my var 5063 is 49,975! (50-0,025). So when machine coordinates var 5071-5073 are not correct, coordinate var 5061-5063 are also wrong.

Allan, thanks for your time. I will have to try the latest update of Mach4 + run csmio updater (I know there is one newer update).
Re: MACH4 #5071-5073 variables values 2000x smaller than DRO
« Reply #4 on: May 24, 2018, 04:41:02 PM »

I was a bit confused by your last post. To be clear, I would have assumed that #5063 and #5073 are updated following a probe strike and I would not have expected them to change at other times. But that is just my assumption. Are you saying that if your fixture offset is changed, these registers are altered to match? I suppose that could make sense too.

« Last Edit: May 24, 2018, 04:47:14 PM by Fledermaus »
Re: MACH4 #5071-5073 variables values 2000x smaller than DRO
« Reply #5 on: May 24, 2018, 06:31:58 PM »
#5063 and #5073 are updated following a probe strike. They don't change except G31 is commanded and the probe is pressed. What I want to say is that I'm not able to use #5063, because is also incorrect number as it is calculated in mach internally from #5073.

If I zero machine, and machine coordinates are work coordinates (zero offsets), #5063 = #5073, but is 2000x smaller value than on DRO. So let's say DRO shows Z=-50mm when the probe is touched then my #5073=-0,025 (2000x smaller value). It should be -50mm

If I zero machine, move it to Z=-50mm and I zero Z, so my work offset is Z=50mm, and I then I move it to Z=0 (machine coordinate) and I probe again to same distance of -50mm, #5063 =50+ (-0,025)=49.975mm and my #5073=-0,025 (2000x smaller value). In this case, #5063 should be 0mm and #5073 should be -50mm.
Re: MACH4 #5071-5073 variables values 2000x smaller than DRO
« Reply #6 on: May 25, 2018, 06:44:44 AM »

To answer my own question, I placed the following code into the PLC script to give a continuously updated view of the probing registers for the Z axis:

Code: [Select]
  -- AW Temporary test display of machine and user probe position
  local zAbs = mc.mcCntlGetPoundVar(inst, mc.SV_PROBE_POS_Z)
  local zMach = mc.mcCntlGetPoundVar(inst,mc.SV_PROBE_MACH_POS_Z)
  scr.SetProperty("droTestAbs", "Value", tostring(zAbs))
  scr.SetProperty("droTestMach", "Value", tostring(zMach))

The registers were updated following a probing cycle, whether or not the probe struck, and their values agreed with those of the normal screen DROs at the same instant.

Register values remained constant until the next probing cycle: they were not affected by writing to the Z screen DRO to change the fixture offset. In this regard, the IP/A behaves as I would expect and its behaviour is the same as that of the SIM.


I cannot reproduce what you experience, which strikes me as incorrect. What version of Mach4 and the CSMIO plugin are you using? I would be inclined to back up your Mach4 folder and then to try an update.


Offline smurph

  • *
  •  1,396 1,396
  • "That there... that's an RV."
    • View Profile
Re: MACH4 #5071-5073 variables values 2000x smaller than DRO
« Reply #7 on: May 25, 2018, 01:34:18 PM »
Allan is 100% correct on this.  And he also tested empirically.  Good job!  

A G31 move will either skip, or not.  Meaning probe strike, or not.  If the probe strikes a surface, the G code variables are filled with the strike position.  If the probe does NOT touch a surface, the G code variables will contain the end point of the move.  Normally, this is the ONLY way to know if the probe has touched a surface in G code is by comparing the G code variable positions to the end point of the move.  If different, the probe struck a surface.  

Since Mach is not running on a real time OS, it can't possibly capture the strike position accurately.  So this job is delegated to the motion controller, which is a real-time device.  So if the values in those G code variables are not correct, then I would suspect an issue with the motion controller or its' plugin.  

If there is a hang waiting on a set still, then the motion control plugin is not working correctly.  Again, since Mach is not running on a real-time OS, and Mach doesn't know the outcome of the G31 move, it will ask the motion controller/plugin to tell it when the move is complete.  It could have reached the endpoint of the move or stopped somewhere in between.  Mach just doesn't know.  So Mach will wait indefinitely for a response back from the motion controller. If no response is given, hang.  

Fanuc only specifies the variables #5061-#5066, which should be the position with all current offsets applied.  Mach also gives you #5071-#5076, which should be the machine position.  All of these positions are in native machine units.  Meaning if you setup the machine for inch, then inches is what you will see in those variables, even if you are probing in G21.  

On an inch machine:
G90 G21
G00 X0
G31 X10 F1000 (probe does not strike)

At the end of the move #5071 == .393701 (inch value for 10mm)

Re: MACH4 #5071-5073 variables values 2000x smaller than DRO
« Reply #8 on: May 25, 2018, 05:39:01 PM »

I have contacted CS Labs numerous times advising them of the Waiting on Set Still ... issue. But to date and despite several updates of their plugin, the problem remains. Mach4 logs indicate absolutely normal behaviour upto the wait but motion simply does not begin, so clearly this one is a controller issue.. When it works, it works admirably, but when it stalls in this way ...

I will continue to provide them with feedback on each new release, but their development  seems rather sluggish. This is a shame as in essence they have a very good and well priced range of products.

Re: MACH4 #5071-5073 variables values 2000x smaller than DRO
« Reply #9 on: May 26, 2018, 05:00:06 PM »
the Mach4 pound variables are populated by the motion controller after a G31 cycle.

When the motion controller reports its position does it report its raw position, ie integer or does it do the calculation to report a DRO ready decimal?
I rather suspect its integer, the controller FPGA has entirely enough to do without concerning itself with floating point calcs. IF that is the case then
the calculation could be done by the motion controller plugin, it after all has the use of the PCs CPU. Alternately it could report the raw integer value
and Machs core could do the calculation and update the registers.

Carbonmikes description sounds rather like the steps per unit  is being applied to the raw data but either incorrectly OR twice?

To my way of thinking there are several questions that need to be resolved to understand whats going on:
1) what numeric data is being reported by the motion controller board?
2) where is the calculation to convert the raw data to a DRO ready decimal?

If you open the diagnostic panel for your motion controller what or how does it display motor position? I use an ESS and it displays a decimal integer and guess that is
what it reports to the plugin. This is my best attempt to answer question 1.

To answer question 2 may I suggest an experiment. Try changing the steps per unit value in the motor tuning page of one axis, X say. You say that your current value
is 2000 steps/per, try an unusal or numerically distinctive value like 1955 and try again. If the calculation is being performed twice the percentage change or error should be the square
of (2000/1955)x 100

With my ESS the motor tuning page is in the Mach4 plugin, not the ESS plugin. That would tend to suggest that any calculation is likely to be done by Machs core. However does the ESS plugin
copy this data to generate a pulse stream...if it does then the calculation could be done within the ESS plugin. I've a feeling this is a smurph question?

My wife left with my best friend...
     and I miss him!