Activity for gseidel
-
gseidel committed [r11] on Code
Release new version that is compatible with SoftMotion 4.17.0.0
-
Increased version of device descriptions and package to 0.0.0.6, updated project to use latest versions.
-
Increased version to 0.0.0.6
-
Fixed compiler errors with SoftMotion versions 4.13 and newer. Set SoftMotion version to 4.17.
-
Hi Fless, thanks for your report! We created an issue in our bug tracker (SM-5109) and will have a look at this issue. Best regards, Georg
-
Hi k2saki, 1.SMC_ReadNCFile2 2.SMC_Interpreter 3.SMC_SmoothMerge 4.SMC_SmoothPath 5.SMC_CheckVelocities I attached a simple example project. Best regards, Georg
-
Hi kumareasu, yes, correct. Best regards, Georg
-
Hi niallel, yes, you are right, Cams would be the preferred mechanism. Best regards, Georg
-
Hi peterned, the start position given in the CNC properties is only used if you use the compile mode OutQueue. With compile mode SMC_CNC_REF, you need to provide the start position in the IEC application. The function block SMC_NCInterpreter has an input piStartPosition. You can initialize it with the output of the forward kinematic transormation FB for your machine. In your case probably SMC_TRAFOF_Gantry2. Best regards, Georg
-
Hi jonasz, you already solved it, I'm answering here for the sake of others with a similar question. You can provide the slope of the A/B/C axis with the U/V/W word. See example 3 here: https://content.helpme-codesys.com/en/CODESYS%20SoftMotion/_sm_cnc_din66025_additional_axis.html If you don't want to change the G-Code, the function block SMC_RecomputeABCSlopes can compute the slopes automatically. https://content.helpme-codesys.com/en/libs/SM3_CNC/Current/SM_CNC_POUs/SoftMotion-CNC/SoftMotion-Function-Blocks/SMC_RecomputeABCSlopes.html...
-
Hi k2saki, I would recommend to have a look at SMC_SmoothMerge, followed by SMC_SmoothPath. SmoothMerge will combine the small G1 elements to longer splines, SmoothPath will avoid stops between the splines. https://content.helpme-codesys.com/en/libs/SM3_CNC/Current/SM_CNC_POUs/SoftMotion-CNC/SoftMotion-Function-Blocks/SMC_SmoothMerge.html For SmoothMerge to work, you have to configure a tolerance, i.e. by how much it may deviate from the lines. To graph the output of the interpolator, you can use...
-
https://dl.codesys.com/s/PsjWgoTyt4dHKfS
-
Hallo, ja, bitte schicken Sie das Projekt. Es kann ein paar Tage dauern bis ich dazukomme. Viele Grüße, Georg Seidel
-
Hallo, beim Wechsel von welcher CODESYS Version auf welche neue Version ist das Problem denn entstanden? Haben Sie im PLC-Log mal geschaut, ob ein Log-Eintrag geschrieben wird dass die Daten gespeichert werden, wenn Sie eine persistente Variable geändert haben? Funktioniert es, wenn sie periodisches Speichern aktivieren? Ist mit der Task-Zuordnung im Projekt alles in Ordnung? Viele Grüße, Georg Seidel
-
Hi, I think the root error is "FBError Drive=2: 116 An active mvt-FB is called after MC_MoveSuperImposed". Please double-check the order of calls in your CFC program and make sure that MC_MoveSuperImposed is called after MC_GearIn. (Use the "Display Execution order" command from the context menu to check.) Best regards, Georg
-
Hi jmarshal9120, MC_Phasing cannot be used on the same master and slave as MC_GearIn. Your idea with the virtual axis is good, however, as mentioned here [0], please use the virtual axis as the slave of MC_Phasing and the master of MC_GearIn. Two other points: you should only use one instance of MC_GearIn, and you need MC_Power for the virtual axis. [0] https://content.helpme-codesys.com/en/libs/SM3_Basic/Current/SM3_Basic/POUs/Movement/MasterSlave/MC_Phasing.html Best regards, Georg
-
Hi jmarshall9120, can you please have a look in the PLC log? There you can see all the errors that happened in their order of appearance. In your case, I'm guessing the MC_GearIn function block has an error. Best regards, Georg
-
Hi ByCNC, here is the automatic translation of your comment, as I do not understand turkish: <<< Hello Georg, You've helped me before and I'm grateful for that. I have a new problem maybe you can take it? Currently there is excessive vibration on the X-Y axes when doing radius operation with CNC Interpolation. The value of "bdAngleTol" to smooth the radius. Even if I manage to smooth the path, this path reveals excessive pulsating motion. Can you have an idea for this? Thank you. Are you using SMC_ToolRadiusCorr?...
-
Hi, no, it is not possible to change the link twist for SMC_Trafo(F)_ArticulatedRobot_6DOF. If the robotics kinematics Kin_ArticulatedRobot_6DOF uses the convention for link twist you expect, you could wrap it into two FBs with the same inputs/outputs as SMC_Trafo(F)_ArticulatedRobot_6DOF and use these FBs with your CNC application. Georg
-
Hi ByCNC, G75 synchronizes the path processing (in German "Satzvorlauf") with the interpolator. It makes sure that the next G-Code line is processed only after the interpolation has reached the line with G75. All path processing buffers are emtpied before the next line is interpreted. Hope this helps, Georg
-
I would recommend to trace the fSetPosition input of SMC_ControlAxisByPos. Most likely there is a jump in this position for some reason.
-
Hi intvenkat, the parameters of the robotics kinematics "Kin_ArticulatedRobot_6DOF" are explained here, with pictures: https://content.helpme-codesys.com/en/libs/SM3_Transformation/Current/SM3_Transformation/Function-Blocks/Standalone-Kinematics/Articulated-Robots/6AxisArticulated/Kin_ArticulatedRobot_6DOF.html Does this help, or are you looking for further information about the CNC function block "SMC_TrafoF_ArticulatedRobot_6DOF"? Best regards, Georg
-
Hi ByCNC, if you have bAvoidGaps = TRUE, then this happens if the velocity of the fSetPosition is greater than the maximum velocity configured for the axis. See the axis configuration, tab "General", group "Dynamic Limits". https://content.helpme-codesys.com/en/CODESYS%20SoftMotion/_sm_edt_drive_general.html Most likely, if you increase the velocity there, the problem disappears. Best regards, Georg
-
As I said, the queue sizes can be much smaller than the g-code file sizes. I have attached an example were we have ~ 1000 lines of g-code and 50 elements in the queue.
-
Dear ByCNC, the error probably occurs because you have more than 2^15-1 (32767) elements in your CNC queue. It is not recommended to use such a huge queue size. Even with g-code files that are in the millions of lines, you do not need to keep the entire path in memory. In your case, a queue size of 100 SMC_GeoInfo elements should be more than enough. Best regards, Georg
-
Hi Peter, I would recommend to check the PLC log and amybe the drive itself what kind of error has occurred. You could also execute MC_ReadAxisError to read the drive specific error object. (You probably need the drive documentation to interpret the value.) And then you could use PLC controlled homing (SMC_Homing) instead of drive controlled homing (MC_Home) as a workaround. Best regards, Georg
-
Hi Peter, glad it works now! Regarding homing, I cannot help you with homing using a different EtherCAT stack. Just a general remark: it is important to set the "homing method" (object 0x6098) before homing. Regarding homing using SoftMotion: the function block MC_Home performs the homing procedure, including setting the mode of operation to 6. Georg
-
Hi Peter, so the drive somehow will not switch from mode of operation 10 (cyclic sync torque mode) to 8 (cyclic sync position mode). Maybe there is a limitation in the drive? E.g. some servo drives can switch the mode of operation only if they are not enabled ... Another thing to try is to not map 6060 and 6061 by PDO. SMC_SetControllerMode will then write them by SDO. This should not make a big difference, but maybe the drive reacts differently. Georg
-
Hi Peter, probably writing 0x6060 to 8 or reading 0x6061 until it is 8 failed during execution of SMC_SetControllerMode. You could check the PLC log for any warnings and errors. Georg
-
Hi joberle, no, there is currently no kinematics for a hexapod. SMC_Trafo_ArticulatedRobot_6DOF cannot be used, as it is for a serial robot while a 6D stewart platform is fully parallel. If you contact CODESYS, they can assist you in creating such a transformation. Best regards, Georg Seidel
-
Home
-
Released version 0.0.0.5
-
Removed fiels that were stored redundantly, added a batch file to create a package, upadted license and apckage manifest and test project.
-
- Set compiler version, storage version, and compatibility version to V3.5 SP15
-
Reimported driver library
-
Reimported driver library
-
Added parts of the trunk
-
Added tags and parts of the trunk
-
Hi there, the Softmotion drive device is red because it is in wCommunication state 80 (waiting for synchronization). You are using a non-realtime capable SoftPLC (Control Win V3), so this is the root of the problem. You have two options: either use a realtime capable PLC (e.g. the RTE) or use SoftMotion Light to move your drive. Best regards, Georg
-
Hi there, you should set nSizeOutQueue to SIZEOF(aBufGeos) where aBufGeos is the array of SMC_GeoInfo objects. Best regards, Georg
-
Hi tonis2, you can check whether this is the problem by tracing the output MC_GroupReadStatus.InSync. If the robot can follow the jogging movement of the virtual axes, then this output is TRUE. If it changes to FALSE it means that the robot cannot follow. Judging from the video, probable the deceleration or the jerk of the virtual axes is too high. (Do you use ramp type "quadratic" for the virtual axes? I would recommend it, otherwise the jerk is unlimited.) You could also trace the velocity, acceleration...
-
Hi tonis2, good, I'm glad we found the problem! In your video, did you just jog downwards in z-direction? That is, the movement that goes up again should not happen? If you use SMC_GroupJog, effects like this may happen if the velocity/acceleration/jerk of the virtual axes used for jogging are too high. Then the robot cannot follow and as a result may leave the straight path. Georg
-
Hi tonis2, I investigated further, what seems to be the problem is the direction of rotation of the axes. Please change the direction in the scaling/mapping settings of the SoftMotion drives, so that moving the axes in positive direction will turn the upper arms upwards, not downwards. (This information is missing from the documentation of Kin_Tripod_Rotary.) Also, it seems that the documentation of the machine coordinate system of Kin_Tripod_Rotary is wrong: The z-axis is pointing upwards, not downwards....
-
Hi tonis2, I think I have an idea what could be the problem: the order of the drives in the axis group editor. Say your drives are named like in the photo "AxisName.jpg" I attached, could you please give the order in the axis group editor as shown in "AxisOrder_Editor.png"? Georg
-
Hi tonis2, thanks a lot for the photos. Given that the lengths are correct we need to find the reason why the tcp moved down by only 5 mm when moving the first axis by 20°. I expected almost 20 mm. Furthermore, the movement of the TCP in x-direction seems to match the expectation quite accurately. Could you please repeat the same experiment, but this time move the first axis to -20° instead of +20°? I would expect an x-movement in the opposite direction (+78 mm) and a z-movement upwards by 9.5 mm....
-
Hi tonis2. yes, could you please send me photos where I can (approximately) check the distances? In particular, I'm interested in how the motors are mounted at the top of the robot (dArm1Radius) and the direction of the first arms (are they radial around the z-axis?). Thanks, Georg
-
Only number (1) is off from the expected values. It should have moved by 19.7 mm. What exactly does "-5 mm" mean? In which direction did it move?
-
OK, to narrow the problem down, could you please start all axes at 0° and then move the first axis to +20°. Is it possible for you to measure the following distances between the initial position and the end position? 1) Distance in Z-direction: the TCP should move downwards by ca. 19.6 mm 2) Distance in X-direction: the TCP should move in negative X direction by ca. 67.7 mm 3) Distance in Y-direction: no change expected 4) Movement of the joint between arm1 and arm2: it should move down by ca. 44.5...
-
OK, to narrow the problem down, could you please start all axes at 0° and then move the first axis to +20°. Is it possible for you to measure the following distances between the initial position and the end position? 1) Distance in Z-direction: the TCP should move downwards by ca. 19.6 mm 2) Distance in Y-direction: the TCP should move in negative Y direction by ca. 67.7 mm 3) Distance in Y-direction: no change expected 4) Movement of the joint between arm1 and arm2: it should move down by ca. 44.5...
-
Hi tonis2, OK. Anything else going on in your application, apart from the jogging function block? Did you rotate the MCS relative to the WCS? Are you jogging in MCS or WCS? I know you already did this, but let's once more check the parameter values of the transformation. In the attached screen shots from your videos and photos, I drew some lines to indicate how I think the values should be measured. dArm1Radius: measured from the center point of the three motors (axis of rotation of the C-axis motor...
-
Hi tonis2, SMC_InvCoordinateTransformation3D is a function block of our CNC solution. GroupJog and MoveDirectAbsolute, on the other hand are part of our Robotics solution. If you use Robotics, you can use MC_SetCoordinateTransform to define an offset and relative rotation between the world coordinate system (WCS) and the machine coordinate system of the robot (MCS). If all checks I proposed succeed, and all parameter values of the transformation are correct, then I cannot explain why the robot does...
-
Hi tonis2, did all checks I suggested succeed? (Jogging of single axes, direction of axes, ...) One more thing to check would be the scaling/mapping of all drives: are they configured so that one user unit in SoftMotion corresponds to exactly 1 angular degree?
-
A picture of the robot might be helpful.
-
Hi tonis2, if the axes are turning in the right direction and the zero position of the axes is correct, then I think you need to double check the parameter values of the transformation. You said you double checked the values, but maybe the values you have are measured differently (from different positions) then the value the transformation expects? You could also check what happens if you move all axes to zero and then jog each axis independently. I would expect the following from the output of MC_GroupReadActualPosition:...
-
Dear tonis2, the first thing I would check is this: do you home your axes in such a way that their zero-position corresponds to all arms being horizontal? Second, did you first test without the coordinate transform? The zero point of the MCS (machine coordinate system) for Kin_Tripod_Rotary is not in the plane of the motors but on the tool plate when all arms are at zero (horizontal). If all parameters are correct and the zero position is correct, then the only thing I can imagine is that maybe the...