c1a02b39f720a12f4d3b37c2c95bd2af.mp4
compiled from https://github.com/JoergS5/RepRapFirmware_robot, based on RRF 3.5.1
thanks for @JoergS5's efforts
Best posts made by OttoJiang
-
voron5x with RTCP
-
RE: voron5x with RTCP
@JoergS5 I was wondering if we could collaborate to maintain the five-axis kinematics code for RepRapFirmware and submit pull requests on GitHub. I am a master’s student in the School of Mechanical Engineering at Zhejiang University, currently researching five-axis printing. I believe contributing such code to RRF would be both interesting and meaningful.
-
RE: 5 axis CoreXYAC Voron ( Robot kinematics) not homing Y axis
@Mafco77 Same problem. It seems that the firmware does not seem to support G1 Hxxx, maybe... I'm not quite sure...
I have a trick which is to use M669 K1 first, then home all axes and use M669 K13 B "CoreXY5AC".
Not perfect but workable. -
RE: voron5x with RTCP
b860ca50-40b5-49c6-a01a-6eee3e6353da-373f17267ac28bce0491e00515ed19fd.mp4
Fixed a bug where, after giving a G1 command that includes only BC values without XYZ, that is, when the nozzle's XYZ coordinates in the workpiece coordinate system remain unchanged and only the BC axis angles are changed, the nozzle moves in a straight line in the machine coordinate system. It should actually move in a curve to keep the nozzle's XYZ coordinates in the workpiece coordinate system constant during the movement.
-
RE: voron5x with RTCP
@droftarts Segmenting the moves does help. There are some small errors in @JoergS5's firmware, and I plan to discuss them with him in the coming days. However, the main issue lies in the GCodes.cpp file in the RepRapFirmware source code. I don't mean that it's a bug in RepRapFirmware itself, but rather that certain parts of the source code need to be modified to adapt to this special kinematics. The code in the DoStraightMove function in GCodes.cpp needs to be changed.
// Apply segmentation if necessary // As soon as we set segmentsLeft nonzero, the Move process will assume that the move is ready to take, so this must be the last thing we do. #if SUPPORT_LASER if (machineType == MachineType::laser && isCoordinated && ms.laserPixelData.numPixels > 1) { ms.totalSegments = ms.laserPixelData.numPixels; // we must use one segment per pixel } else #endif { const Kinematics& kin = reprap.GetMove().GetKinematics(); const SegmentationType st = kin.GetSegmentationType(); // To speed up simulation on SCARA printers, we don't apply kinematics segmentation when simulating. if (st.useSegmentation && simulationMode != SimulationMode::normal && (ms.hasPositiveExtrusion || ms.isCoordinated || st.useG0Segmentation)) { // This kinematics approximates linear motion by means of segmentation float moveLengthSquared = fsquare(ms.currentUserPosition[X_AXIS] - initialUserPosition[X_AXIS]) + fsquare(ms.currentUserPosition[Y_AXIS] - initialUserPosition[Y_AXIS]); if (st.useZSegmentation) { moveLengthSquared += fsquare(ms.currentUserPosition[Z_AXIS] - initialUserPosition[Z_AXIS]); } const float moveLength = fastSqrtf(moveLengthSquared); const float moveTime = moveLength/(ms.feedRate * StepClockRate); // this is a best-case time, often the move will take longer ms.totalSegments = (unsigned int)max<long>(1, lrintf(min<float>(moveLength * kin.GetReciprocalMinSegmentLength(), moveTime * kin.GetSegmentsPerSecond()))); } else { ms.totalSegments = 1; } ... }
Obviously, when the XYZ coordinates don't change, moveLength=0, and at the same time, totalSegments=1, which causes the segments to have no effect at all. As a result, the nozzle can only move along a straight line.
Although my current code runs fine, the motion accuracy doesn't seem to be very precise, and my code is also too dirty, so it requires further modifications.