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...
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...
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...
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 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? Also, I just google...
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 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?
How are the servo drives controlled? EtherCAT, step/dir pulses, other? Another thought it - if it's step/dir pulses - the pulses 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?
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?
@imdatatas, thanks for the info, I increased DSP402.uiHomingMinCycles to 10 and have a good feeling that will solve the issue of "false" homings. It's an intermittent issue so I'll report back once it's confirmed. @bruno-roth, also good info. According to my documentation, bit 14 is used to indicate the homed status. I did a test and the bit always stays true after it's been homed once (eg. even if I initiate a new homing procedure then hit the the e-stop mid homing), so I need to take that into...
@imdatatas, thanks for the info, I increased DSP402.uiHomingMinCycles to 10 and have a good feeling that will solve the issue of "false" homings. It's an intermittent issue so I'll report back once it's confirmed. @bruno-roth, also good info. According to my documentation, bit 14 is used to indicate the homed status. I did a test and the bit stays true even if I initiate a new homing procedure then hit the the e-stop mid homing, so I need to take that into consideration, but I can work with that....
@imdatas, thanks for the info, I increased DSP402.uiHomingMinCycles to 10 and have a good feeling that will solve the issue of "false" homings. It's an intermittent issue so I'll report back once it's confirmed. @bruno-roth, also good info. According to my documentation, bit 14 is used to indicate the homed status. I did a test and the bit stays true even if I initiate a new homing procedure then hit the the e-stop mid homing, so I need to take that into consideration, but I can work with that. ...
Hi, Is there a way to read the homed status from the EtherCAT drive directly? I am currently flagging the homed status on the succesful completion of the MC_Home function block, but I have had false triggers where the drive didn't actually execute the homing procedure but the MC_Home FB is marked as complete without error. I looked at other MC/SMC function blocks but the closest I can find is the "Homing" bit from MC_ReadStatus FB, but this doesn't show if the drive is succesfully homed, only that...
Hi, Is it possible to display the units along the X,Y axis of the Path3D element? It correctly shows the CNC path to be followed, but there's no indication of scale or size of what's being displayed. I looked at the documentation and my first inclination is that this is not possible, and the option option would be to somehow recreate the Path3D functionality into the XY Chart visu element - which is not ideal. Any suggestions or pointers would be appreciated!
What do you mean by continuous movement? You want to continuously follow a dynamic target position? SMC_ControlAxisByPos, which is typically used with CNC Interpolators, could work for that. Instead of feeding the target position in from the Interpolator, feed in the target position from your server instead. Once you enable the FB, it will continuously move the axis to track the fSetPosition input. https://content.helpme-codesys.com/en/libs/SM3_CNC/Current/SM_CNC_POUs/SoftMotion-CNC/Direct-Axis-...
Turns out the issue was user error, no need to revert libraries.
Hi, I'm experiencing a bug with the latest version of SoftMotion CNC library (4.17), where the 3DPath object in Visu is missing all the important properties. I've verified that a previous app I was working on with library version 4.16 did not have this issue and the issue is duplicated in that project when I update it to 4.17. I've already submitted a bug report, but for the time being I need to revert the project I'm currently working on back a revision. I've tried right clicking on the library...
For general usage, these links might help you out. If you are looking at using I2C interfaces, examples from the Raspberry Pi will probably be useful, even if your board isn't a Raspberry Pi. https://content.helpme-codesys.com/en/CODESYS%20Examples/_ex_rts_serial_com.html https://content.helpme-codesys.com/en/CODESYS%20Examples/_ex_raspberry.html If you're developing your own drivers, I can't help you there, although the link you provided will help. If you drill in deeper, the I2C page for example...
Glad to hear it π
@gepert, When you say "I do not turn off power", are you saying you don't power off the drive, or you don't turn of the MC_POWER function block? I read your statement as you don't kill actual electrical power. MC_POWER should stay enabled. @Gustavo, not related to problem at all, but when you say 1.6 Nm is only enough torque to unscrew a loose bottle cap, I think that's a bit low. A quick mental math I use is 1 Nm is almost the same force as 1kG applied to a 10cm wrench. So 1.6kG applied to a 10cm...
@gepert, When you say "I do not turn off power", are you saying you don't power off the drive, or you don't turn of the MC_POWER function block? I read your statement as you don't kill actual electrical power. MC_POWER should stay enabled. @Gustavo, not related to problem at all, but when you say 1.6 nM is only enough torque to unscrew a loose bottle cap, I think that's a bit low. A quick mental math I use is 1 nM is almost the same force as 1kG applied to a 10cm wrench. So 1.6kG applied to a 10cm...
Sometimes you just need to pose a question on a forum and re-read it to get clarity. pGeoInfo := SMC_GetObj(poq:=ADR(fbCncInterpreter.poqDataOut), n:=1); This won't work, I'm providing a pointer to a pointer, as poqDataOut is already a pointer! I just need to remove the ADR() and it works. pGeoInfo := SMC_GetObj(poq:=fbCncInterpreter.poqDataOut, n:=1);
I have an application using CNC GCode interpolation, but I need to modify the GCode provided to the PLC based on certain parameters. I am currently attempting to modify the SMC_GeoInfo objects in the SMC_OutQueue using the code below. Note that all the other code is pretty standard and works fine, but when I add the below it errors. PROGRAM TEST VAR fbReadCncFile : SMC_ReadNCFile2; fbCncInterpreter : SMC_NCInterpreter; arrCncInterpreter : ARRAY[1..99] OF SMC_GeoInfo; pGeoInfo: POINTER TO SMC_GeoInfo;...
OK, that makes sense. Because the FB is provided a specific interval period, it would change the target position accordingly based on the time it "thought" elapsed. If it has the wrong interval provided, it updates the target positions every cycle incorrectly so the axes will end up moving faster or slower. Thanks!
Hi, Learning Codesys CNC, and I am confused by the dwIpoTime parameter. I have a basic demo application, using SMC_Interpolator feeding into SMC_TRAFO_Gantry2Tool2, which then sets the position of the x/y SM_Drive_Virtual axis. I also have a C axis which revolves the tool, which is controlled using a simple tangential angle calculation SMC_CalcDirectionFromVector. The GCode I'm using has feed/accel set at 500. The axis configuration limits are well above that (2000). What's strange is that, when...