M125 Px PREVIOUS Px value applied not latest Px value

[dammogreen]

The pulley ratios changes don't take effect right away they lag behind "one M215 CALL".
It will apply the Previous selected Pulley ratio even from the previous G code run and the program restarted from the top.

So the work-around kludge for this issue is to call M215 twice in a row:

M215 P2
M215 P2 (THEN IT "~WORKS")


Encoder pulses AND index are on spindle Version 1.2047

Because of this lag I also tried putting a "dummy instruction" (G55 when already in G55) after the M215 Px...to see if that got through the instruction delay, no difference.

reference:
P1 ratio is 1:1 so expected pitch movement is 0.051"
P2 ratio is 1:1.35 so expected pitch movement is 0.0389"
P3 ratio is 1:1 so expected pitch movement is 0.0255"

Confirmed by running this test code, and turn spindle by hand 1 revolution and measure pitch movement with indicator;

---------- G COde -----------------------
G80 (the G80's are not necessary It made no difference with or without)
M1
M215 P1
G33 X-.06 K.051 <--------moves X 0.0389"" ****What happens is it applies the LAST/Previous Px (P2) value that was last run...even after a Reset

G80
M1
M215 P2
G33 X-.12 K.051 <--------moves X .051" (its applying previous P1 ratio) , for Pulley 2 it SHOULD be 0.0389" movement

G80
M1
M215 P3
G33 X-.18 K.051 <--------moves X 0.0389" (so it's on P2 NOT P#3 ) it's one step behind

G80
M1
M215 P2
G33 X-.24 K.051 <--------moves X 0.025" (so it's on P3 NOT P#2` ) it's one step behind

G80
M1
M215 P2
G33 X-.30 K.051 <--------moves X 0.0389" SEEMS "correct" because the one BEFORE was also P2 !!! it's actually 1 behind
NOTE: if the program is run again it will apply THIS P2 value not the one first specified!!!!

[dammogreen]

Edit : typo in the title should read M215...

Also wanted to say that the Pulley # selected value in the spindle configuration page does not update until the second M215 Px instruction is "processed".

[cncdrive]

Hi,

I could only partially test this now, because I'm at home and unfortunately I don't have an encoder at home, so I could not get through the G33 tapping part, but what I could test is the following:

1.) I've tested with both versions 1.2047 and 1.2102, because I was not sure which version you used. I mean you mentioned 1.2047 but I'm not sure if you used that or if it was just a question about that version.
I've tested with the UC300ETH-5LPT and UC100, because I don't know which controller you using.

2.) I ran your code, but because I do not have an encoder at home I could only get to the first G33 line where the controller starts waiting for the index signal from the encoder.

3.) I could also test through the whole code with changing out the G33 codes to G1 codes, which I did and ran through the code.

4.) I moved the selected spinlde pulley number DRO from the spindle setup page to the run page, so I could easily see what it shows while the code was running. You wrote that it does not update for you in time, so I thought it will be a good indicator, because as I said I can't test the tap pitch now, because I have no encoder at home.

5) And finally I even tested it with the G41 enabled.

The result, what I see is that with all of the tests I've made the pulley number DRO updates in the proper timing. When I ran with G33 I first set the pulley number from MDI to a different number. Then the code went down to the M215 ..., stopped because of the M1 and then I cycle started again and so the code stopped on the G33 and the pulley number was already updated when it was waiting there.
When tested with G1 codes instead of G33 then again the pulley number updated in the proper time, when the axis was moving then the pulley number DRO had the correct numbers which we programmed right before the movement code.
I also put some breakpoints in the source code to see the order of execution and it is correct, the M215 executes in the proper timing, before the G33 codes.

So, I was unable to reproduce the issue so far.

I have some questions:

1.) Please upload your profile file to let me test with your settings.
2.) Please tell me which software versions are you using?
3.) If you have some time can you please test if replacing the G33 with G1 then you can still reproduce the issue (I mean the pulley# DRO is still lagging then?)? Just to let me see, because then I can more easily test if I can without running G33 codes.
4.) And please re-check if the spindle pulley DRO is really not updating? Or if it was a wrong information and if that updates just the pitch is wrong? I need to know to know what and where to exactly look for.

[cncdrive]

Meanwhile I've noticed that the pulley values don't update on the screen at all when the M215 P.. is issued.
I mean not the pulley number DRO, but the pulley min. and max. value, but that is only a screen DRO update problem, I will fix that now, but it is not something which causes the lagged pitch problem which you reported now. That has to be something else, because inside the software the plulley min. and max. values are updating in time, I've checked it. The M215 just not writting the plulley min. and max. DROs., so that is not the cause for the problem.

[dammogreen]

Version 1.2047 (in my first post)

Thanks for the reply, I will get to the shop later today and test what you suggested.

[dammogreen]

One of my original observations WAS INCORRECT ;

The spindle pulley selected #DRO on the spindle config page DOES update immediately after an M215 command.

I'll try to look at some other things soon.

Profile attached

[dammogreen]

I just found an easier way to test, this should help a lot:
So not specific to G33 at all, just that pulley ratios are not applied the first time in general.

Even if I just do an M215 P2 in the MDI I have to do it twice before the pulley ratio is actually applied to the spindle speed.

i.e

S300
P1 ratio is active 1:1 pulley ratio in mechanical reality and in pulley table

Upon M3 an actual RPM of 300 ...ok

MDI: M215 P3 [1st time commanded] (1:2 ratio in table)
MDI : M3 Rpm stays the same as before when P1 was selected [fail]
MDI: M5
MDI: M215 P3 [2nd time commanded]
MDI : M3 Now RPM changes accordingly because P3 pulley ratio was finally applied.[pass]

[Dan911]

Hi dammogreen,

I see from your post and profile your using ModbusEZ plugin. Just a heads up on how it works and could be the cause of your problems.

I see you have max rpm setup in configure with 4000 and max HZ at 139. What the plugin does is divides 139/4000, so when you set your spindle/motor RPM to 4000 it sends 139hz to your VFD. ModbusEZ V15 doesn't have the pulley system implemented, so if your max rpm changes in UCCNC the plugin is still going to use the settings in configure. For example... if pulley changes the max rpm to 2000 the plugin will be sending 69.5 hz to VFD.

Dan

[dammogreen]

Thanks for the tips, and I had realized that, but I don't think it effects this problem.

[cncdrive]

I've just found out what the problem is.
It was a bit hard to figure it out without having an encoder at me now,
but the issue is that the API releases the handle back to the UCCNC too early, before the new pulley ratio gone into effect.
So, the UCCNC continue to execute the next line which is the G33 and so when the G33 is loaded into the motion buffer then still the old pulley ratio value is in effect, so it will use that ratio for that G33 pitch.

And the code with duplicate M215 Px works only, because executing the code two times take some time, so while the 2nd M215 is processed and executed meanwhile the first M215 value gets applied by the API,
so when the code execution reaches the G33 then the value of the first M215 Px is already in effect.
It would not matter if that second M215 Px was something else, like a short motion code or a G4 Px wait. If it takes a few milliseconds then the M215 applies before the G33 code line is reached.

I will ask my collegue to fix the issue in the API code with not releasing the handle until the new ratio value takes effect.