In a simple SoftMotion programme with two stepperless modular axes from CMZ, one is simply controlled in speed, but a spot must perform a positioning.
I use the function MC_SetPosition() both to reference the axis at power-up and also to correct the actual position to a fixed machine reference detected with proximity.
The function has only one instance and I actually use a booelan variable to control the ‘Execute’ input.
Well, I cannot correctly change the axis position on the fly if it is running at high speed. The servomotor works in a speed range between 0°/s and 720°/s, (gearbox output with a 1:6 ratio). As long as the servomotor is operating at speeds below about 400 °/s, the function is able to correct the position correctly even when forcing values far apart, but at high speeds, from 400 °/s upwards, the correction no longer takes place. For example, trying to correct the position of 280° into 300° with absolute mode, the axis that is moving at speed actually shifts the position by a few degrees, not the expected 20.
I don't understand why with the servo drive running slowly the position shift occurs correctly, while increasing in speed it no longer works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just a stab in the dark, but you might want to check the Dynamic Limits (accel, decel, velocity, jerk) in the Codesys SoftMotion device configuration, as well as checking similar limits on your servo drive?
Are you seeing any errors, or does the MC_SetPosition FB get marked as complete?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No errors in any condition. The function terminate correctly with the 'done' bit.
Now I leave the machine and I don't know when I will be there again. The assumption you made I had considered. The operational limits of the axis are all fit for purpose, and this function should operate virtually without even noticing the motion limits.
In fact in practice with the axis at low speed the function corrects any numerical value of the position in the range 0 ... 360° without any problem whatsoever in a single PLC scan cycle.
Last edit: Gustavo Antonio Banchetti Brucatori 2025-01-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How are the servo drives controlled? EtherCAT, step/dir pulses, other?
Another thought is that - if it's step/dir pulse based control - the pulses from the PLC to the drive are getting missed/lost at high frequencies? If that's the case then there would be multiple troubleshooting steps/corrections that could be investigated.
You could try to create a simplified program, with all the same parameters, that only has an MC_SetPosition FB you manually trigger and see if you are still getting the same results?
When you manually control the motor directly from the servo drive software at the speeds you are calling for, does it move precisely to the target position?
Last edit: trusty-squire 2025-01-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How are the servo drives controlled? EtherCAT, step/dir pulses, other?
CANOpen, 1 Mb/s, bus load 35%, cycle time 2ms.
Another thought is that - if it's step/dir pulse based control - the pulses from the PLC to the drive are getting missed/lost at high frequencies? If that's the case then there would be multiple troubleshooting steps/corrections that could be investigated.
Here, it seems to me that we are getting completely off track with the observed problem.
You could try to create a simplified program
I had already written this elsewhere. The program before being brought into machines was exhaustively tested in SW emulation and the problem did not occur. However, in emulation I was interested in checking other aspects of the process, not this specific one which is for real a correction made necessary after the fact. The part of the program that does this correction with the function mentioned in the topic, came up from its origins, but I didn't know or didn't think it was really useful. A scruple that later turned out to be necessary. However, for now I do not think I will spend any more time on this verification, already lacking any to do my normal.
I remain amazed, however, that a function intended to correct the axis position with the motor in motion and that it should not interfere with this, in fact instead changes behavior as the motor speed changes. Mah!
When you manually control the motor directly from the servo drive software at the speeds you are calling for, does it move precisely to the target position?
The drive and motor have been working fine for about 10 years. In replacing the machine control system, I opted for CoDeSys where before there was something else. But this is not the subject of the problem. What I need to resolve is the fact that a clutch specially placed at a certain point can slip and, therefore, I have the undeniable need to phase the 'prime mover' to the mechanical position of the machine, detected by a cam for each turn, in order to properly stop at its optimum point. Which for now I have ruled out doing.
In fact, if I really have to say, since we have now gone brutally OT, I originally thought that this clutch should only come into action in cases of extreme necessity, as happens in most trials. But this one, the way it is made, slips more easily than I could estimate and the servo-controlled 'prime mover,' and the machine, get out of phase, maybe by a little, but frequently, and when the machine work at it's high speed, (in fact all of the time), I can't adjust properly the 'prime mover' position at fly.
Last edit: Gustavo Antonio Banchetti Brucatori 2025-01-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here, it seems to me that we are getting completely off track with the observed problem.
If questions clarifying the details of the installation are problematic, it's best to include those details in the original question then...
I had already written this elsewhere. The program before being brought into machines was exhaustively tested in SW emulation and the problem did not occur.
Testing the full program in emulation is entirely different from creating a simplified program to isolate the function causing problems in the real world. I would recommend trying it to isolate the issue.
The drive and motor have been working fine for about 10 years. In replacing the machine control system, I opted for CoDeSys where before there was something else. But this is not the subject of the problem
A simple "yes" is the correct answer to my question here...
Anyways, you seem to be a very knowledgeable expert, good luck on your problem!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
can you reduce the problem to a project that reproduces the issue without the real servo drives? (You could set the servo drives to virtual and strip away as much as possible from the application.)
If you can attach a project, we will have a look.
Best regards,
Georg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi gseidel,
before moving to HW implementation, I had created the same program in simulation mode with virtual drives and, as far as I remember, everything worked fine simulating process and the few useful inputs. So it does not seem to be a SoftMotion library problem, but rather a problem with dynamics or physical axis adjustments. What escapes me, however, is the fact that this function is supposed to perform a position shift virtually, in fact without interfering with the axis itself, thus independent of its adjustments. MC_SetPosition() is not a homing function, in fact it is clearly intended to be executed on the fly with the axis moving.
Now I'll see if I can reduce the program, although I don't like it very much. In my life I have learned that problem searches should be done on the part, and not in a more or less similar way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
CoDeSys 3.5.19.7
Target Berghof MX6
In a simple SoftMotion programme with two stepperless modular axes from CMZ, one is simply controlled in speed, but a spot must perform a positioning.
I use the function MC_SetPosition() both to reference the axis at power-up and also to correct the actual position to a fixed machine reference detected with proximity.
The function has only one instance and I actually use a booelan variable to control the ‘Execute’ input.
Well, I cannot correctly change the axis position on the fly if it is running at high speed. The servomotor works in a speed range between 0°/s and 720°/s, (gearbox output with a 1:6 ratio). As long as the servomotor is operating at speeds below about 400 °/s, the function is able to correct the position correctly even when forcing values far apart, but at high speeds, from 400 °/s upwards, the correction no longer takes place. For example, trying to correct the position of 280° into 300° with absolute mode, the axis that is moving at speed actually shifts the position by a few degrees, not the expected 20.
I don't understand why with the servo drive running slowly the position shift occurs correctly, while increasing in speed it no longer works.
Just a stab in the dark, but you might want to check the Dynamic Limits (accel, decel, velocity, jerk) in the Codesys SoftMotion device configuration, as well as checking similar limits on your servo drive?
Are you seeing any errors, or does the MC_SetPosition FB get marked as complete?
No errors in any condition. The function terminate correctly with the 'done' bit.
Now I leave the machine and I don't know when I will be there again. The assumption you made I had considered. The operational limits of the axis are all fit for purpose, and this function should operate virtually without even noticing the motion limits.
In fact in practice with the axis at low speed the function corrects any numerical value of the position in the range 0 ... 360° without any problem whatsoever in a single PLC scan cycle.
Last edit: Gustavo Antonio Banchetti Brucatori 2025-01-10
How are the servo drives controlled? EtherCAT, step/dir pulses, other?
Another thought is that - if it's step/dir pulse based control - the pulses from the PLC to the drive are getting missed/lost at high frequencies? If that's the case then there would be multiple troubleshooting steps/corrections that could be investigated.
You could try to create a simplified program, with all the same parameters, that only has an MC_SetPosition FB you manually trigger and see if you are still getting the same results?
When you manually control the motor directly from the servo drive software at the speeds you are calling for, does it move precisely to the target position?
Last edit: trusty-squire 2025-01-18
CANOpen, 1 Mb/s, bus load 35%, cycle time 2ms.
Here, it seems to me that we are getting completely off track with the observed problem.
I had already written this elsewhere. The program before being brought into machines was exhaustively tested in SW emulation and the problem did not occur. However, in emulation I was interested in checking other aspects of the process, not this specific one which is for real a correction made necessary after the fact. The part of the program that does this correction with the function mentioned in the topic, came up from its origins, but I didn't know or didn't think it was really useful. A scruple that later turned out to be necessary. However, for now I do not think I will spend any more time on this verification, already lacking any to do my normal.
I remain amazed, however, that a function intended to correct the axis position with the motor in motion and that it should not interfere with this, in fact instead changes behavior as the motor speed changes. Mah!
The drive and motor have been working fine for about 10 years. In replacing the machine control system, I opted for CoDeSys where before there was something else. But this is not the subject of the problem. What I need to resolve is the fact that a clutch specially placed at a certain point can slip and, therefore, I have the undeniable need to phase the 'prime mover' to the mechanical position of the machine, detected by a cam for each turn, in order to properly stop at its optimum point. Which for now I have ruled out doing.
In fact, if I really have to say, since we have now gone brutally OT, I originally thought that this clutch should only come into action in cases of extreme necessity, as happens in most trials. But this one, the way it is made, slips more easily than I could estimate and the servo-controlled 'prime mover,' and the machine, get out of phase, maybe by a little, but frequently, and when the machine work at it's high speed, (in fact all of the time), I can't adjust properly the 'prime mover' position at fly.
Last edit: Gustavo Antonio Banchetti Brucatori 2025-01-18
If questions clarifying the details of the installation are problematic, it's best to include those details in the original question then...
Testing the full program in emulation is entirely different from creating a simplified program to isolate the function causing problems in the real world. I would recommend trying it to isolate the issue.
A simple "yes" is the correct answer to my question here...
Anyways, you seem to be a very knowledgeable expert, good luck on your problem!
Hi Gustavo,
can you reduce the problem to a project that reproduces the issue without the real servo drives? (You could set the servo drives to virtual and strip away as much as possible from the application.)
If you can attach a project, we will have a look.
Best regards,
Georg
Hi gseidel,
before moving to HW implementation, I had created the same program in simulation mode with virtual drives and, as far as I remember, everything worked fine simulating process and the few useful inputs. So it does not seem to be a SoftMotion library problem, but rather a problem with dynamics or physical axis adjustments. What escapes me, however, is the fact that this function is supposed to perform a position shift virtually, in fact without interfering with the axis itself, thus independent of its adjustments. MC_SetPosition() is not a homing function, in fact it is clearly intended to be executed on the fly with the axis moving.
Now I'll see if I can reduce the program, although I don't like it very much. In my life I have learned that problem searches should be done on the part, and not in a more or less similar way.
Here is the archive of the simulation project: https://drive.google.com/file/d/1n74Qy-1yLPpI2OK4FaZO5q50y2uTa0Wr/view?usp=drive_link