After upgrading 2 machines from 3.5.12 to 3.5.16.20 linux SL on DEBIAN BUSTER RT-PREEMT with CPU pinning, CNC has some problem managing MCodes.
If last code of a partprog is "M40 K250 L250" and first is "M06 K9", randomly repeating many times the part prog with SMC_GetMParameters i receive K250 on SMC_INterpolator.wM = 6!
It appen randomly repeating 15-20 times the partprog. This cause big problems, because on our lathe machine M06 is for changing tool in turrets and M40 is to move to a fixed quote tailstock body.
With old runtime our consumer can make with the same partprog up to 4000 pieces by day with no problems.
Code used for interpolator is the same on all our machines and unchanged in many months.

The problem never happen in MCodes after the first.
First MCode is never first row, before we have some editor hidden line to set some default parameter, like GCode to set (X,Z) plane in place of (X,Y)

This is a Lathe Blending machine configured with 2 SMC_INterpolator for 2 separated axis group.

Hi,
I think more important to know is on which SoftMotion version you are after and before the update.
BR
Edwin

I just attached library screen shoots, coming from a working machine 3.5.14.20 and a problematic machine 3.5.16.20
We changed Runtime because we'd see a big improvement in reading encoders and write analog values stability via ethercat, and our Hydraulic PID built to drive Hydraulic axes is working in a very better way then in 3.5.14.20.
3.5.16.20 solved as a big problem in following error of hydraulic axes, and we can use grater gains and FF keeping axes very stable. This is strange because we not see a big improvement in max jitter (~100us), but stability of PID is consistently changed.

Hi,
I would recommend to check with current SoftMotion Version.
BR
Edwin

Sorry! I just checked!
SoftMotion Version is 4.5.0.0 also with 3.5.16.20

Monday we'll test 4.8.0.0 on customer test machine.

Kind regards
Mondin Marco
ADV Integration Srl

Hi.
Yesterday we try in to replicate problem in a second machine.
The only difference is in our FB MachineConfigurator, we made made to differentiate machines keeping only one source for all machines.
Testing machine has only one SMC_Interpolator (and all other FBs needed) working, problematic machine two. In all configurations we have 5 axis group instantiated, but only one or two or three working.
We cannot replicate bug in 4.5 with testing machine.
Next week we'll test adding 2 axes and configuring it like problematic machine.
We can't stop production to our consumer and at the moment we made a temporary workaround (Using timers is awful):

workers.tmMCodeTest(IN := interpolator.wM <> workers.oldMCode, PT := T#50MS); 
IF workers.tmMCodeTest.Q (*interpolator.wM <> workers.oldMCode*) THEN
   workers.mPars(bEnable := FALSE, interpolator := interpolator); 
   workers.mPars(bEnable := TRUE, interpolator := interpolator);
   m_ToGateway.mParamK := workers.mPars.dK;             
   m_ToGateway.mParamL := workers.mPars.dL;
   workers.oldMCode := interpolator.wM;   
   m_ToGateway.mCodeRequest := workers.oldMCode;      
END_IF