I found another strange problem on my "delta+" printer. The A-axis endstop occasionally gets stuck pressed, seemingly in firmware only. I'm using a normally open switch, and the LED indicator on the Duex5 shows that the connection is working normally. When the switch is pressed the light is off. However, sometimes M119 indicates that the endstop is pressed even when the light correctly indicates that the switch is not pressed. U, V, A motors are plugged into the Duex5, but the U axis doesn't use an endstop and the V endstop is on the main board, so the only affected endstop is on the Duex5.

The fact that the LED indicates the correct switch position while the firmware reports the wrong position makes me think this may be a bug rather than a hardware problem. I've replaced the switch as well and the same behavior occurs.

I can't replicate this behavior every time, but it persists until I press the endstop. It affects homing, but the endstop isn't used outside of that, so it's workable for now, even if that means it takes 2 tries.

I'm using DWC 1.22.2 and 2.02rc1

Here's my homing file for A:
G91 ; relative positioning
G1 A-150 F8000 H1 ; move A to the low end stopping at the endstops (first pass)
G1 A10 F3000 H2 ; go back a few degrees
G1 A-12 F1500 H1 ; move once more but slowly (second pass)
G90
G1 A0 F5000 H2 ; move to center position
G90 ; absolute positioning

And my config file:

; Configuration file for Duet Ethernet (firmware version 1.20 or newer)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool on Mon Feb 26 2018 12:03:14 GMT-0600 (Central Standard Time)

; General preferences

G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves
M555 P1 ; Set firmware compatibility to look like RepRapFirmare
;M665 R105.6 L215 B85 H250 ; Set delta radius, diagonal rod length, printable radius and homed height backup
;M665 R115 L291.2 B85 H170.8
M669 K11 ; Kinematics type 0 = cartesian, 3=linearDelta,
M665 R115 L291.2 B85 H172.0 K ; Set delta radius, diagonal rod length, printable radius and homed height backup
M668 A-42; ; Set offsets for rotational axes

; Network
M550 PJohn's Duet ; Set machine name
M540 Pbe:63:40:4c:53:52 ; Set MAC address
M552 P0.0.0.0 S1 ; Enable network and acquire dynamic address via DHCP
M586 P0 S1 ; Enable HTTP
M586 P1 S0 ; Disable FTP
M586 P2 S0 ; Disable Telnet

; Drives
M569 P0 S0 ; Drive 0 goes backwards X
M569 P1 S1 ; Drive 1 goes forwards Y
M569 P2 S0 ; Drive 2 goes backwards Z
M569 P3 S0 ; Drive 3 goes backwards E
M569 P4 S1 ; Drive 4 goes forward Nothing
M569 P5 S1 ; Drive 5 goes backwards U
M569 P6 S0 ; Drive 6 goes forwards V
M569 P7 S1 ; Drive 7 goes forwards Nothing
M569 P8 S1 ; Drive 8 goes forwards A
M569 P9 S1 ; Drive 8 goes forwards A
M269 P10 S1 ; Drive 10 goes forwards W

M584 X0 Y1 Z2 E3 U5 V6 W10 A8 ; set up extra axes? U5 V6 A7

M350 X16 Y16 Z16 U16 V8 W1 A8 E16:16 I1 ; Configure microstepping with interpolation
M92 X80 Y80 Z80 U44.4444 V226.24 W2 A24.2963 E92.5 ;E663 ; Set steps per mm (or degree) V226.24
M566 X1200 Y1200 Z1200 U1200 V1200 W1200 A1200 E1200 ; Set maximum instantaneous speed changes (mm/min)
M203 X18000 Y18000 Z18000 U4000 V5000 W4000 A8000 E1000 ; Set maximum speeds (mm/min)
M201 X1000 Y1000 Z1000 U1000 V400 W1000 A1000 E500 ; Set accelerations (mm/s^2)
M906 X1000 Y1000 Z1000 U1200 V1000 W75 A800 E1000 I65 ; Set motor currents (mA) and motor idle factor in per cent
M564 S0 H0; Allow moves S0 outside of build area, H0 while not homed.
;M84 S30 ; Set idle timeout

; Servos
M307 H3 A-1 C-1 D-1 ; Disable heater 3-7. Set parameters to -1. Servos 3-7 are controlled with heaters 3-7 (There are no servos 1-2).
M307 H4 A-1 C-1 D-1
M307 H5 A-1 C-1 D-1
M307 H6 A-1 C-1 D-1
M307 H7 A-1 C-1 D-1

; Axis Limits
M208 X-100 Y-100 Z0 U-100000 V-94.50 W-1000 A-58 S1 ; Set minimum (for low endstops this sets the endstop location)
M208 X100 Y100 Z300 U100000 V93.34 W1000 A58 S0 ; Set maximum (for high endstops this sets the endstop location, but not XYZ)

; Endstops
M574 X2 Y2 Z2 U0 V1 W0 A1 S1 ; Set active high endstops
M666 X0 Y0 Z0 U0 V0 W0 A0 ; Put your endstop adjustments here, or let auto calibration find them

; Z-Probe
M558 P0 H5 F120 T6000 ; Disable Z probe but set dive height, probe speed and travel speed
M557 R85 S20 ; Define mesh grid

; Heaters
M140 H0 S0 ; Disable heated bed with M140 H-1
M305 P0 T100000 B4725 C7.060000e-8 R4700; Set thermistor + ADC parameters for heater 0 Bed Heater
M305 P1 T100000 B4725 C7.060000e-8 R4700; Set thermistor + ADC parameters for heater 1 Extruder
M143 H1 S280 ; Set temperature limit for heater 1 to 280C
M143 H0 S120 ; Set temperature limit for heater 0 to 120C

; Fans
M106 P0 S0.80 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
M106 P1 S0.0 I0 F250 H-1 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned off
;M106 P2 S1 I0 F500 H T45 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on

; Tools
M563 P0 S"Extruder" D0 H1 ; Define tool 0
G10 P0 X0 Y0 Z0 U0 V0 W0 A0 ; Set tool 0 axis offsets
G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C

; Automatic saving after power loss is not enabled

; Custom settings are not configured

; Miscellaneous
T0 ; Select first tool
M302 P0 ; Allow cold extrudes for testing

That fixed it as far as I can tell! I'll continue doing testing and let you know. What was the bug? This is the best support I've gotten for a product in my life.

I followed your advice from my previous thread and replaced the ground wire. I no longer get any I2C errors, but this homing problem still occurs maybe 5% of the time.

Here is the M122 output a few seconds after the homing fails.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02RC1(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6J9F2-3S46R-K2XBW
Used output buffers: 3 of 20 (17 max)
=== RTOS ===
Static ram: 28460
Dynamic ram: 98040 of which 0 recycled
Exception stack ram used: 356
Never used ram: 4216
Tasks: NETWORK(ready,400) HEAT(blocked,1232) MAIN(running,3484)
Owned mutexes:
=== Platform ===
Last reset 00:48:40 ago, cause: power up
Last software reset at 2018-10-29 13:38, reason: User, spinning module GCodes, available RAM 4200 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 31.3, current 31.4, max 31.6
Supply voltage: min 11.9, current 12.1, max 12.2, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-11-01 09:58:54
Slowest loop: 0.30ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 82, completed moves: 82
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 4.07ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
=== Expansion ===
DueX I2C errors 0

I have implemented a kinematics type based on the LinearDeltaKinematics, but I am running into a bit of a roadblock. It looks like currently LinearDeltaKinematics::GetMotionType may not be implemented. I believe this function is supposed to allow for additional linear axes on a delta, is that correct?

A secondary problem is that the firmware only allows segmentFreeDelta movements if the current kinematics class is specifically class LinearDelta (Mine is based on this, but has a different name) using function Move::IsDeltaMode. If I want to move an extra linear axis at the same time as the delta carriage makes a segmentFreeDelta movement, how would I do that? It works right now, but the delta motion traces a curve as the towers move linearly. In fact, the delta axes always make linear moves rather than segmentFreeDelta moves in this kinematics mode.

As of now it looks like GetKinematicsType is used to determine if a printer uses segmentFreeDelta movements based on if it is using class LinearDelta or not, while it should be determined per axis, (or per set of 3 axes) in whatever the current kinematics mode is. It looks like a per-axis approach is partially implemented through LinearDeltaKinematics::GetMotionType, but not fully.

My request is that the motion type be determined per axis regardless of kinematics mode.

@dc42 Interesting. I'll have to try that. That would get around the problem I think. I thought the axes have to be created in order, but that might be old info.

This problem occurs typically during homing, where I have the axis double tap the end stop. The first press typically works, but then DWC and M119 report that the switch is still pressed, so the second tap never happens. Rarely this problem has happened on startup as well though, so even the first press would not function correctly. For a few days I thought I had my axis backwards because the switch was constantly pressed when I powered on, which made the motor move the axis away from the endstop immediately during homing.

I have never seen the M119 status fluctuate randomly though. It is either incorrect at boot, or gets stuck in the incorrect state after the endstop is released. Pressing and releasing the endstop will typically fix it.

@dc42 Thanks for looking into it! I'm happy to help test.

Wow! Very cool. Where can we find out more about this build?

Wow! Very cool. Where can we find out more about this build?

Thanks for the tips! I was thinking I might do something like that. For the cylinder it would make sense to unwrap it and design a rectangular STL part and wrap it back onto the cylinder. Getting rid of the seam seems difficult though.

I'm building a new Duet powered machine and I'm attempting to 3D print on a rotating mandrel, kind of like a rotational axis engraver in reverse. I believe I can modify the firmware to do this by taking pieces of code from the polar printer kinematic profile, but slicing is going to be the hold up. For simple test cases I probably won't even have to modify the firmware.

I did a quick search online and I haven't seen anybody solve this, but I bet people have tried this before and I just haven't found it.

I see two paths forward.

1. Start from CAM and trick the software into thinking I have an engraver, then post process the G-code to add extrusions or whatever I need. CAM will probably handle the motion more easily, but not the extrusion.

2. Start with slicing to handle the extrusions and other printing parameters, but post process the G-code to account for the new kinematics.

Either seems possible, but I'm not familiar with much CAM, so I'm hoping for some input.

Edit:
This is a similar question to this thread, but slightly different I think. Looks like there is some interest.
https://forum.duet3d.com/topic/13964/using-a-4th-rotary-axis/

or should I being doing something similar to rotary delta with segmented motion? Is that a valid work around? I could change all axes to be linear axes, but use segmented motion instead in the constructor. Would I need to change anything else if I tried that?

I just tried this to see what might happen. I changed my kinematics class to:
MyKinematics::MyKinematics() : Kinematics(KinematicsType::myKinematics, DefaultSegmentsPerSecond, DefaultMinSegmentSize, false), numTowers(UsualNumTowers)
{
Init();
}

I took the definitions of the defaults from rotary delta kinematics, 100, and 0.2 respectively

I also changed GetMotionType to:
MotionType LinearDelta7DKinematics::GetMotionType(size_t axis) const
{
return MotionType::linear;
}

Things mostly work now, but the motion is not entirely smooth. It is definitely trying to approximate a straight line, but not quite right. As far as I can tell all of the moves do at least arrive in the correct spot.

@dc42 said in Update on delta motion in custom kinematics class:

I think you may have been right anout those lines in DDA.cpp that you highlighted, specifically this one:

params.dparams = static_cast<const LinearDeltaKinematics*>(&(reprap.GetMove().GetKinematics()));

The static_cast is wrong in your case, because the kinematics is your own class, not the LinearDeltaKinematics class.

One possible solution may be to derive your own kinematics class from LinearDeltaKinematics.

Ooh boy. I'm really getting into it now aren't I? Derived classes sound familiar, but I should've taken more than 1 class of C++ in school. I'll look into that. Do you have any pointers on how to start? Are there any derived kinematics classes already in this project I can work from to understand? Thanks again.

I updated to version 2.03RC1, and the same thing happens. The only thing I really changed was added an override function of GetLinearAxes(), which doesn't seem to do anything yet. I copied the one from LinearDeltaKinematics. Looks like that is in the pipeline though, so I'll pay attention to that going forward.

Is my constructor correct to be:

MyKinematics::MyKinematics() : Kinematics(KinematicsType::myKinematics, -1.0, 0.0, true), numTowers(UsualNumTowers)
{
Init();
}

or should I being doing something similar to rotary delta with segmented motion? Is that a valid work around? I could change all axes to be linear axes, but use segmented motion instead in the constructor. Would I need to change anything else if I tried that?

@danal Agreed, it's always good to check the basics. I am sure that I'm adjusting the machine position, not the motor position. I'm not confident that my kinematics class is 100% configured right, but all of the motion I need works. The "implied" moves of the delta all happen properly, except that the special case delta straight line motion doesn't work; the print head travels in an arc.

Here is a list of my modifications so far to the firmware, which work.

I had to modify the GCodes2.cpp file for M665 first. It kept forcing my printer into KinematicsType::linearDelta when it saw an M665 command, so I added another case for my kinematics class number. This work fine and M122 reports back that I am in the right mode, plus my transformations happen correctly, so I know the right mode is being used.

I copied LinearDeltaKinematics.h/cpp and created my own versions, modifying Recalc(), the various forward/inverse transform functions, CartesianToMotorSteps() and MotorStepsToCartesian(), removed basically any function relating to auto calibration (for now until I figure out a way to add them back if I get to it).

I've created homing files for everything, and configured the extra axes in config.g

I also use:
MotionType LinearDelta7DKinematics::GetMotionType(size_t axis) const
{
return (axis < numTowers) ? MotionType::segmentFreeDelta : MotionType::linear;
}

At this point the motion all works for small movements. If I could force my slicer to only make <2mm moves I would be set. Up to this point it makes sense that the print head travels in an arc because I haven't told Move to treat it as a delta.

In an attempt to fix the segmentFreeDelta motion I made these additional changes that have not worked:

In Move.h:
bool IsDeltaMode() const { return (kinematics->GetKinematicsType() == KinematicsType::linearDelta) || (kinematics->GetKinematicsType() == KinematicsType::myKinematics); }

This causes all of the motion involving the 3 delta axes to be jumpy and inaccurate for all moves that aren't purely Z. The extra linear axes all work fine still, but the delta no longer tracks the V axis motion like before. I'm sure something in my kinematics class could be causing this, but it seems odd that the motion works fine when I treat all axes as linear and breaks when I try to incorporate the delta motion type.

I know this is very weird case. Thanks for all the help, I really appreciate it.

I'm actually using 2.03beta2 so not crazy old, but behind the current version. I'll update today.

I think you mean that when you include V20 in a move, you want to implicitly add Y-20 so that the belt motion won't affect the print. That does indeed mean that you need new kinematics, unless you preprocess the GCode to add or adjust the Y coordinates when V movement is present.

That's a good way of putting it. That's pretty much exactly what I've done. By performing a series of coordinate transformations within the kinematics class I have made my G code processing much easier. Basically I can print standard G code and the transformations keep track of the proper coordinate system.

My GetMotionType function is

MotionType LinearDelta7DKinematics::GetMotionType(size_t axis) const
{
return (axis < numTowers) ? MotionType::segmentFreeDelta : MotionType::linear;
}

I am only using 3 delta axes and configuring them with M665 R110.6 L340.5 B90 H120.35, which should set numTowers to 3.

Thanks for the reply. I'm sure I am wrong about the problematic lines. I just tried following isDeltaMode until I stopped seeing things that made sense to me.

Unfortunately I don't think I can use the standards Delta kinematics because when I make a movement using one of the extra axes often the Delta axes must move too. For instance, a movement of G1 V20 moves the print bed 20mm in the +Y direction. My kinematics class allows the Delta printer to track that movement without needing a G1 Y20 movement as well. This way I can use regular G Code to print on a moving surface.

I will double check today if I implemented the motion type correctly for my axes today, but I think I have.

Everything works great, but the Delta moves in arcs. I've been trying to make sure I only do small movements, but lately I've had trouble getting prints started if they have straight edges because the G Code points are far apart and in between points the nozzle jams into the print surface.

I will try adding additional axes using the M command. I saw that in the last update but since my class was working (minus this problem) I didn't try that.

Re: Segment free delta motion in custom kinematics class

Version 2.03beta2

I've finally had some time to look into this behavior a bit more. I think I've identified some of the lines that might be causing trouble. I'm using this in a way that I'm sure isn't intended, but essentially I have a 7 axis system, where 3 of the axes consist of a delta printer. The rest of the axes move the printer itself, so I have a custom kinematics class to account for that.

Essentially how it would work best in my case is if the segment free delta movement of the delta axes worked even while other axes were moving. I've complicated it a whole lot by making the delta axes dependent on other linear axes. Think delta printer over a conveyor belt. As axis V moves (linear motion of the print bed relative to the print volume) I make the delta track its position above the build surface so it can continue printing using normally sliced G-code, with a few modifications to add V-moves. In this way, motion of the delta tower axes can be caused by movement of a different axis. The kinematics works, but the delta doesn't move in a straight path.

The problem I'm running into is that I can no longer make the delta printer use segment free delta movement, so all large movements are arcs.

I changed the line in DDA.cpp where it calls IsDeltaMode() so that it is true for my class as well, but that creates a new problem. Whenever the printer moves it jerks around towards where it is supposed to go, but never smoothly, and not always to the correct final position.

I'm sure that the delta movement portion of the code assumes only 3 axes, which is a natural assumption to make.
Possibly lines 1118-1132 in DDA.cpp might be causing trouble? I'm not entirely sure where to go from here.